On June 16, 2024 6:44:35 AM UTC, Russ Allbery <r...@debian.org> wrote:
>Scott Kitterman <deb...@kitterman.com> writes:
>
>> I appreciate the thought and effort that went into this review.
>
>> If I'm following your description correctly, the tag2upload "package" flow
>> is:
>
>> developer --> salsa --> tag2upload --> ftp.upload.debian.org
>> machine --> dgit-repos
>
>> Is that right?
>
>Yes, I think so.
>
>> While it may not matter from a post attack detection security trace
>> perspective, I think there are more routine trace activities that this
>> complicates. A couple of examples are the signed by listing in the
>> tracker.d.o news section for packages and who-uploads from devscripts.
>
>> While making package signing information less visible isn't directly a
>> security issue, it does seem like a complication that makes it harder to
>> keep up with what's going on.
>
>> Would you consider these kind of indirect effects relevant from a
>> security analysis perspective or are they just non-security concerns
>> from your POV?
>
>I made the assumption that, if tag2upload were deployed, those tools would
>be modified to pick up the signer information from the *.changes fields
>where tag2upload puts it. That metadata is put into both the *.dsc and
>the *.changes files.
>
>As with the other parts of this proposed design, that does require
>trusting tag2upload to do the authentication check properly, so a
>compromised tag2upload server could write erroneous trace information and
>therefore would not be detected by either of those tools.
>
>A tag2upload server compromise is fairly serious. A compromise of any of
>tag2upload, dak, or the buildds have roughly equally serious potential
>impact on the archive as far as I can tell, although the details differ.
>In all three cases, you need reproducible builds to reliably detect the
>compromise, although in the tag2upload case you only need reproducible
>source builds for the specific set of source transformations that
>tag2upload is willing to perform, which I believe is a much easier problem
>than the reproducible binary builds required to detect buildd or dak
>compromises. dak, uniquely, can meddle with either source *or* binary
>packages, but dak meddling with source packages will break the signatures
>on those packages, so is somewhat easier to detect than dak meddling with
>binary packages.
>
>(This is assuming I'm not missing some security control in dak, which is
>entirely possible because I've not done a comprehensive security review of
>dak and am not certain of all the details of the architecture. If I'm
>missing something, please do correct me!)
Yes and no. The difference is that currently, I can download the source
package and verify it myself. Not just who signed it and with what key, but
that the signature verifies. I don't need to trust assurances from any service.
From the perspective of Debian, the project, that's presumably not significant
and can be accounted for by updating our tools. From the perspective of some
Debian users, I'm less certain of the significance.
Scott K
