On Fri, 13 Sept 2024 at 16:29, Robie Basak <[email protected]> wrote: > > [Splitting into more than one sub-thread so that I can reply to some of > this without holding up my entire reply; this sub-thread is about > validation] > > On Wed, Sep 11, 2024 at 04:38:27PM +0200, Luca Boccassi wrote: > > Regarding the request for validation, could you please clarify exactly > > what kind of validation you would like to see? > > The scenario I want to ensure we prevent is: > > 1) Somebody asks for sponsorship of a keyring change. > > 2) A sponsor uploads it because it appears correct. > > 3) The SRU team (or backporters team) accept it because it appears > correct. > > 4) It turns out later that an attacker had asked for the sponsorship, > having injected their own key. > > 5) Users are shocked because they thought that because it came from the > official Ubuntu archive, Ubuntu developers would have properly checked > the keyring change to prevent such an attack. Ubuntu suffers > reputational damage as a consequence. > > To ensure that this doesn't happen, we must agree on how Ubuntu is to > ensure that the keys provided in a proposed update really do belong to > the entities they are purported to represent, and then implement that. > > This shouldn't be "because someone claiming to be Luca says so". It > probably also shouldn't be "because someone validated to be Luca says > so" either, because you might be unavailable and then we'd be stuck and > also because, despite having no reason to distrust you, we probably > shouldn't base a root of trust that relies on the integrity of just one > person and their personal infrastructure. For example, the integrity of > this entire trust chain probably shouldn't depend on your personal keys > not having been compromised. > > See also my concern about using "because Debian sid says so" in my > initial reply.
I think we need to be careful to avoid making our lives unnecessarily hard without good reasons. 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. 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. 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. External contributors can send merge requests too, and again team members have to review before they can be merged. As an extra safety net, I could add an autopkgtest that, given a version being tested, clones and checks out the corresponding tag from Salsa, and verifies that the content matches the upstream tag too. That will make sure everything matches. If this solves the concerns, then I can document it and add the autopkgtest. If it doesn't solve the concerns, please first explain how the ubuntu-keyring SRUs were validated in the past against the same concerns, and we can try to find out a way to match the same level of trustworthiness - but I do not know how that was done, so I am unable to say whether something else is missing or not without more details. Thanks! -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
