Re: tag2upload (git-debpush) service architecture - draft
There are at least 2 questions being debated here, and at least 5
proposed solutions, and they are frequently being confused.
The questions:
(1-trust) Is it acceptable in principle for the archive to trust a
tag2upload service? (i.e. have tag2upload rather than dak be
responsible for checking the tag signature)
(2-hash) If yes, is it acceptable for tag2upload to rely on SHA-1?
The solutions ('git debpush' is the part running on the uploader's
system, 'tag2upload' is the part running on a server):
(a-sha1resign) git debpush pushes a special signed tag "please upload
this commit" (i.e. identified by sha1). tag2upload creates a source
package from this, signs it with its own key, and dputs it. (Ian's
original, [A])
(b-sha256resign) As (a) except the tag also includes a sha256. [B+D]
(c-scriptedstatusquo) git debpush becomes an automated way to do what is
currently recommended, i.e. it creates and pushes a signed git tag (to
salsa and to dgit), creates tarballs, creates and signs .dsc+.changes,
dputs .dsc+.changes+tarball(s). (This might be as simple as "dgit
push-source && git push --all --follow-tags" [C], but I haven't tested
that.) tag2upload doesn't need to exist.
(d-tarballrecreator) git debpush creates and pushes a signed git tag,
creates and signs .dsc+.changes, and sends them (but _not_ the tarballs
they refer to) to tag2upload. tag2upload creates the tarball(s) from
the git repo, and dputs the .dsc+.changes+tarball(s). [B+D]
(e-modifydak) Add at least some git-upload-related functionality to dak
itself, instead of a separate tag2upload service. (This is more of a
family of solutions than a single option: the specific variant [E]
proposed by Bastian is close to (d), but the equivalent of (b) could
also be done this way.)
Table of advantages and disadvantages (+=better, -=worse, .=slightly
worse, compared to doing nothing):
abcde
Uploader's convenience:
+++++ Only need to know/type 'git debpush'
++ ++ Doesn't waste bandwidth on tarballs
Security:
-- - (1-trust) Requires trusting the new code
- (2-hash) Relies on SHA-1
Implementation difficulty:
-.-- Code doesn't already exist
. -. Needs reproducible tarballs (d) or equivalent (b+e)
-- - Requires (somewhere to run a) new service
- Requires changes to dak
-- ? Breaks "get sponsor name from .dsc" tools
abcde
On 30/07/2019 16:54, Bastian Blank wrote:
On Sun, Jul 28, 2019 at 07:05:49PM +0100, Rebecca N. Palmer wrote:
That suggests that working towards requiring the SHA-256 mode of git (which
at least sort of exists since 2.21 [2], but I don't know if it's usable yet)
might be a better use of effort.
Please keep in mind that the archive needs to verify this. How do you
intend to provide the required information within the existing source
package structure?
We don't: this is only trying to fix (2-hash), while you evidently
object to (1-trust).
Also, as hinted at by Marco, the SHA-256 mode of git doesn't work yet:
(with git 1:2.23.0~rc0-1; the config lines are from [0])
$ cat .git/config
[core]
repositoryFormatVersion = 1
[extensions]
objectFormat = sha256
compatObjectFormat = sha1
[core]
filemode = true
bare = false
logallrefupdates = true
$ git log
fatal: unknown repository extensions found:
objectformat
compatobjectformat
Another idea, [...] I would say
this is a new source format.
I agree that implementing the whole of your proposal would require
modifying dak. (I see it as "implement (some of) tag2upload inside
dak".) This potentially has similar security implications to having dak
trust tag2upload: lower risk as it would be under the established
package/maintainers/sysadmins for such sensitive code, but higher impact
if gaining control of dak is worse/easier to hide than just being able
to upload.
However, it has two elements that could be useful for a
(d-tarballrecreator) scheme with current dak. (They would then need to
be .dsc+.changes not just .dsc, as .dsc and .changes must be signed by
the same key [1].)
a complete .dsc file with the names and
checksums of the uncompressed files.
Not compressing the tarballs may make reproducibility easier.
The user signed .dsc is put into
the tag.
This would allow the git repo to be the only communication channel from
git debpush to tag2upload. (As in (a/b-sha*resign), but I don't know if
this matters.)
[A] https://lists.debian.org/debian-devel/2019/07/msg00501.html
[B+D] https://lists.debian.org/debian-devel/2019/07/msg00596.html
[C] https://lists.debian.org/debian-devel/2019/07/msg00601.html
[E] https://lists.debian.org/debian-devel/2019/07/msg00641.html
[0]
https://sources.debian.org/src/git/1:2.22.0-1/Documentation/technical/hash-function-transition.txt/#L125
[1] https://salsa.debian.org/ftp-team/dak/blob/master/daklib/checks.py#L157
Reply to: