Scott Kitterman <deb...@kitterman.com> writes: > I agree that there's a risk that what the uploader thought they were > uploading and what they actually uploaded are different, but that's > independent of tag2upload or not.
But it's not independent; tag2upload makes this story somewhat better. tag2upload is based on a signed Git tag and moves the source package construction off of the uploader's system onto more-secure project infrastructure. It therefore moves the uploader's signature closer to their intent: it's a signature over the thing that they are more likely to have directly reviewed, not over a build artifact derived from their Git tree. > I also agree there are tradeoffs on all this. In the particular case of > source package construction, there's a tradeoff between doing it on a > centralized, managed service with a known configuration that is internet > exposed versus the variety of unknowns associated with individual > developer machines. Right, for some value of Internet-exposed that can be fairly restrictive. > There are different risks for the end user. Currently dget uses > dscverify by default before unpacking a source package. I'm not an > expert at all, so I don't have any appreciate for the perceived risks > that led to that being the default (IIRC, it wasn't always). I am > assuming that wasn't random. I'm not sure how that would work in this > new paradigm. Well, it obviously still works (once it's aware of the tag2upload key) but the signature is by the entity that constructed the source package, so dscverify will trace the signature back to the tag2upload server and not to the uploader's system. >> I think it would be hugely valuable to have something like a "dgit >> verification mode" where you can ask dgit, which already has all the >> source package construction logic, to take a tag2uplod-generated source >> package, start from the tag object and signature, and reproduce that >> source package and verify it. Except for the retrieval of the signed >> Git tag, in theory all of that could be done locally. I'm not sure how >> hard that would be (this comes back to the question of how difficult it >> is to ensure that the tag2upload source construction algorithm is >> easily reproducible), but I think something like that would go a long >> way towards providing some really interesting security properties. > I think this is much more manageable if you assume the whole world uses > git all the time for everything and git is the interface, but that's not > reality. I'm extremely confused. Of course you can assume that for any package signed with tag2upload. tag2upload will only act on Git repositories and therefore anything that it has worked on necessarily had to use Git as the interface. Maybe you thought I was implying that this dgit verification mode would work with general source packages and not just tag2upload packages? No, it cannot, because in the general case we have absolutely no idea how to map a source package in the archive back to a Git tree. That's exactly the problem that tag2upload is trying to solve. For non-tag2upload packages, we still have to rely on the source package as the farthest back that we can trace the code without diverging into package-specific analysis and diverging maintainer workflows. > Personally, I think the ability to interact with the archive to do the > verification and not relying on things that are not the archive for the > code to verify is an important property of the existing system and I > don't think it's feasible to maintain it in a tag2upload world. Here too, I don't understand exactly what you are saying. All of the source packages uploaded to the archive via tag2upload will verify. They have valid OpenPGP signatures. That OpenPGP signature traces the provenance of the source package back to the entity that constructed the source package just as the source package signatures in the archive do today. The entity that does the source package construction has changed from the uploader's system to the tag2upload server, so tracing the package to a specific maintainer (absent a dgit verifiation mode) requires relying on that server, *but* you also now have the option of doing additional work to trace the provenance back further to a signed Git tree, something that's not possible in the general case with source packages today. This has various security trade offs as discussed above. But I do not agree that it breaks the property that you claim it breaks; in both cases, you can trace the source package back to the entity responsible for its construction. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
