Validation of keyring changes [was: Enhancing cross-distro collaboration via foreign archive keyring] availability

[Robie Basak]

[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'm sure we can set up
> some autopkgtest for it, which means it would all be automated, and
> require no manual work.

I don't think this would solve the matter of validation of the actual
key material, which I think is the core issue here. I have no reason to
be concerned about validation of the packaging itself, since as you say
it's a simple text file. We might want some tooling to ensure that
there's no misformatting and that keys aren't being removed (except for
deliberate revocation) but I don't think that's in contention. While
it'd be a nice improvement, I don't think this should be a blocking
requirement either.

[...]

>                                   ...the only thing that really
> matters is that the source is trusted - and it comes from git, so if
> the content matches the upstream tag, which is set by a trusted
> source, then that should be all that is necessary?

Yes, but we need to agree on what exactly constitutes a trusted source,
and the process for how Ubuntu reviewers are supposed to validate that.

Signed git tags aren't great because I don't think the SHA256 transition
is complete yet? But in principle I think that method of validation is
fine, provided that the other matters relating to trust I mention above
are addressed.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20240913/2278d34b/attachment.sig>