>
> 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.
I do not think it is unnecessary, on the contrary I think it is very
useful. What I am cautioning against is veering too far off into the
woods and conjuring problems out of nothingness, as context is
important, especially as the alternative is "just fetch it from the
internet yourself". There's no need to make things extra complicated
for this use case, as it's not critical for any meaning of the term,
compared to other things that are routinely updated. Simple is better.
> > 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.
The trust connection is from the repository on Salsa, which can only
be changed by a select group of trusted users, the same that upload to
Debian, including stable updates. If Launchpad is good enough for this
purpose, then Salsa is too, especially as this is way way way less
important than ubuntu-keyring or other packages that are routinely
updated.
> 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.
I disagree, I think it is a very important data point. Sauce for the
goose is sauce for the gander, as they say. What level of validation
was added to gate ubuntu-keyring updates on the wake of these supply
chain attacks? If the answer is "none", then it's an acceptable answer
for this too.
> > 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.
There's no code inspection of any data payloads, as there's no code.
Also, I very much doubt that "careful code inspection" is done on
things like major kernel version updates, as that is simply not
humanly possible due to the sheer size of the changes. So yes, I am
quite sure we can expect sponsors to follow this rule, as it's really
trivial to do once documented, and we in the RPM Packaging Team will
keep an eye on uploads anyway, so any mistake will be caught trivially
and rectified before it makes it out of the 'proposed' pocket. There's
really no need for anything more complicated than this, as it's not
really that important, and it's not worth wasting any more time or
resources, and I am quite sure this email thread alone consumed more
resources than any update for the next 10 years will actually need.
Clone Salsa repo, checkout signed tag, upload. That's more than enough
for this case, anything else doesn't solve any real problem and is not
worth pursuing. In the real world, I very, very seriously doubt
anybody other than me or another RPM Team member will ever ask for an
update anyway.
> > 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.
That is the same as any other package, and there are way more
important ones than this one, so if it's not a problem there, it's not
a problem here either.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
