On Sunday, June 16, 2024 12:46:41 PM EDT Russ Allbery wrote: > 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 can see that, but that leads to what I view as a problem. The thing in the archive is signed by a machine, not the human who decided it should be uploaded. > > 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. It's signed by tag2upload, not the human that decided to upload it. Personally, I think that's significant. > >> 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. No, I understood that. I guess I view this somewhat differently. In my mind the signature on a source package is a developer saying that they believe it should be in the Debian archive and the archive tools verify that the human making that assertion has the authority to do so. In my view, the tag2upload signature is something fundamentally different. > > 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. I think it's just that I view a signature by a mechanized service as something different that a signature made by an actual person. Technically you are correct, but I think it's fundamentally different. I don't think the computer is responsible for anything. I think it has to trace to a person if you want to talk about responsibility. Scott K
signature.asc
Description: This is a digitally signed message part.
