On Fri, Sep 13, 2024 at 05:20:34PM +0200, Luca Boccassi wrote: > I think we need to be careful to avoid making our lives unnecessarily > hard without good reasons.
I agree with this principle. However, I think that given that you're asking to make changes to a trust root for the purposes of maintaining that trust root in the archive itself, it's reasonable to spend, at a minimum, the effort needed to arrive at a documented scheme that describes how that trust is established. So I hope that you don't consider this converation here to be unnecessary. > If certain workflows are good enough for > example to import new kernel or compiler sources, or for > ubuntu-keyring updates, then they also must be good enough for this, > which has a much narrower and less impactful use case. That said, an > agreed and documented robust-enough workflow is a good idea. I think these are false equivalences. ubuntu-keyring updates are almost never done, and validating them against the actual keys used by Ubuntu infrastructure is trivial for Ubuntu developers to do. Further, for trust purposes, the updates were provided by an employee of the same entity that provides Ubuntu's infrastructure (Canonical), so there can be some level of inherent trust that any replacement keys provided did indeed belong to the same entity. Validation of the individual employees' identities can be done trivially on our own infrastructure that we must fully trust already for our archive publication (Launchpad). But in the general case that you're requesting here, that trust connection isn't present. This isn't a showstopper, but it does mean that we need to establish an alternate means of validating the trust chain. Further, I don't know what specific validation was actually done in the rare cases that ubuntu-keyring was changed in a stable release in the past, but any shortcomings there are something we should fix in the wake of supply chain attacks such as what happened in xz-utils. You're proposing to do something new in ways that haven't been done before, so now is the time to decide what level of validation is appropriate for the security landscape today. What happened with ubuntu-keyring for a couple of one-off events in the past cannot be considered to be a precedent for the rather different thing you are proposing to do now. In the common case for stable updates in Ubuntu, we review the actual code changes themselves, so authenticating their origin isn't critical for supply chain security. In contrast, for keyring changes, validating the upstream origin is absolutely critical since key changes cannot be checked by mere inspection. One of the (many) aspects that saved us is the delay between Debian sid being updated and Ubuntu stable releases getting it. But here, you're proposing to take that delay away, updating Ubuntu stable releases as soon as the change is signed and pushed to Debian Salsa. So this situation is different and standards applied elsewhere do not transfer because the security implications are different. > So, a good enough workflow that should suffice for all intent and > purposes in my view would be: instruct to never upload from a random > tarball attached to a launchpad bug or an email. Always and only > upload from a tag laid on the ubuntu/<release> branch on Salsa, after > checking that the tag is signed. I don't think we can expect sponsors to follow this kind of rule. Since we usually expect them to use careful code inspection only, it's difficult to create a place that they would automatically for special rules such that we'd be confident that they'd follow them. That's not to say that we shouldn't define and document this somewhere, but rather that our process shouldn't depend on it. Instead, I think we should use the SRU review process to ensure this kind of checking is done. I'm less keen on using autopkgtests (again, to rely upon; having them is fine) because in our pipeline packages would still be published to -proposed and therefore available "officially" before that validation has happened. This would need the tooling to be able to be run outside the autopkgtest environment. I think we need more specifics though. We would check that the tag is signed, but by whom? Who decides the set of signers that is acceptable? How do we manage changes to that set? If that's all managed at the Salsa end, then that's worse security than what Debian have today, because that's not necessarily even restricted to those who can upload to the Debian archive! I can sense potential frustration in anyone reading this. But unfortunately this sort of validation provides no security value unless these things are specified. # How to automatically perform the validation Could we place the set of acceptable signers for the git tag signature in the source package itself? Then have a script in the source tree that the sponsor and SRU reviewer can both run that validates against Salsa as you suggest? The special case documention would then specify that expectation and the SRU reviewer would merely have to run the script. They already expect an explanation for any other changes, so that would maintain the integrity of this check. This is necessary because in our workflow we upload before the autopkgtests run. This way, when reviewing we would normally expect that script and the acceptable signature list not to change, and it would be very clearly evident if the proposed update requires them to change. > The current trustworthiness of git > tags is good enough for everything else including the kernel, so it's > good enough for this too, and there are no real attacks that can be > done against git tags that need to worry anyone at this stage. Only > members of the Salsa RPM Packaging Team have permission to push tags > there. I am not the only person in the team, there are a couple of > other people, so also the single-person-bottleneck issue is solved. There's still the question of the entire trust chain failing if a single person's personal keys are compromised. We generally accept this in development release, but normally all changes to stable releases in SRUs are reviewed by at least two people. Is it possible to require the tag to have been signed by two appropriate people who have independently checked that keys are correct? How is that checking to be done and what commitment is the team signing tags on Salsa making to do such checking? Robie
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
