>
> [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
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
