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!) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
