Thank you for writing this up. This is extremely helpful to make clear what the actual point of contention is.
Joerg Jaspert <[email protected]> writes: > FTPMaster *is* in support of t2u, if it ends up in a way that allows dak > doing the final verification/authorization of the upload, NOT needing to > trust some other instance. Why is this your red line? Is it only that you don't want to add another system to the trusted set, or is there something more specific that you're concerned about? > As generating changes and dsc on the maintainer side is out (we want a > git $something workflow now), that verification ought to be over the > content. So whatever tool the maintainer ends up calling ought to > generate a signature over the content of the package and put that into > git (a tag, or whatever t2u uses). I want to talk about designs from the perspective of threat models and constraints, so I'm going to try to reverse engineer those from your proposed solution so that we can have a more structured discussion of the security properties. Please check this and make sure that I've correctly captured your thought process here: The threat that you are trying to protect against is a compromise of the tag2upload server. I think you're trying to find a design that meets the following constraints: 1. You want there to be some external check on the tag2upload server to ensure that it correctly constructed a source package from the uploader-signed artifact. 2. You (correctly, in my opinion) do not want dak to perform the construction of the source package from a Git tag, so you are looking for some other agent in the system to serve as the check on the tag2upload server. Is that correct? If that's right, it sounds like your solution is to push that verification work to the uploader. I know you're trying to avoid specifics, but let me make this slightly more specific so that I have something concrete to talk about. If I understand correctly, a design that you would approve would look something like this: 1. The uploader performs the work to transform a Git tree into an unpacked source package and calculates a Merkle tree hash of that unpacked source package or something equivalent. 2. The uploader creates a signed Git tag over the corresponding Git tree in the same way as in the tag2upload design but additionally includes the Merkle tree hash in the signed data. 3. tag2upload functions in the same way as designed, starting from the Git tag, constructing the source package, and passing it to dak. It additionally conveys the signed Git tag object to dak in some form, such as a separate file. 4. dak verifies the Git tag signature, performs normal authorization checks against it, unpacks the source package, calculates the same Merkle tree hash, and ensures that the hash matches the one in the Git tag. Am I correct that this is the type of design that you are asking for and that you would approve this design, modulo the normal sort of details that would need to be hashed out? If this is the case, then I think it's incorrect to say that the tag2upload maintainers have ignored this feedback. I can't speak for them, obviously, but I believe I've seen them answer essentially this feedback multiple times. My understanding is that the problem with this design from their perspective is that it requires a fat client on the uploader's system, and whole point of tag2upload is to stop requiring a fat client on the uploader's system. In particular, it requires all the code to reconstruct the source package from a Git tree be installed locally, which is basically a full dgit implementation. This is a real trade off about which we can disagree! This is a useful thing for us to argue about and vote about. I agree that the design that you propose is somewhat more secure in that it adds a check on the security of the tag2upload server that would catch some classes of compromise, although I believe I have a substantial caveat to your analysis that I'll talk about more below. But it's a trade off, like most things in security: the cost is that it's still not possible to upload a Debian package via a signed Git tag with some metadata that one can manually construct if one wishes. A Debian uploader still has to have a Debian-specific program installed locally that does a bunch of complex transformations of a Git tree before they can trigger an upload. If the disagreement is over whether that user interface property is worth the security trade off, then that's a concrete thing that we can argue about, but I want to make sure that this fully captures your objection. > That then allows dak to do what it does now and trust the thing > originates from the maintainer. I think this is probably my strongest point of disagreement with your analysis. I think you're putting more weight on this idea of maintainer intent than it can actually support, and I think your analysis of maintainer intent is somewhat incorrect. It sounds like you are assuming that the maintainer has vetted the thing that they sign. I am extremely dubious that this is the case. I believe that the typical maintainer workflow today is that the maintainer works on the package in a working directory (usually but not always in Git) until they are happy with the results. Then they run a build tool that generates a source package, and they blindly sign and upload that source package. They do not verify that the resulting source package matches their intent in their working tree apart from building binary packages based on it and running them. In other words, the intent that the maintainer who uses Git is trying to express is "upload something corresponding to this Git tree and this upstream orig tarball to the archive." By asking for the signature to be over the source package instead of over the Git tree, we are already diluting maintainer intent. The thing the maintainer signs is not the source code of the package; that's the Git tree. It's a build product of the source code. In that sense, the signature verification that the tag2upload server does is *closer* to actual maintainer intent than a signature verification on the *.dsc file. We're diluting maintainer intent by moving to the source package. That's one of my objections. My other objection is that I think that the uploader's system is already the weakest link in our current security model. Relying on it for additional security properties is something that we're currently doing, and having the uploader's system redundantly check the tag2upload server does have some security benefit, but I think that security benefit is substantially less than the benefit of, say, a reproducible source package build server in a separate security domain but with a similar secured architecture rather than whatever state the uploader's system is in. In other words, if the goal is to create a redudant check on the tag2upload server, doing that via something the uploader signs is not clearly better (and I think arguably worse) than having two tag2upload servers in separate security domains that perform the same operations. In both cases you're still trusting the same code to perform the source package transformation, but the tag2upload server has a better security model than the uploader's local system. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
