On Tue, Sep 10, 2024 at 06:12:15PM GMT, Robie Basak wrote:
> Hi,
>
> On Wed, Sep 04, 2024 at 10:51:30AM +0100, Luca Boccassi wrote:
> > For developers like myself who work across distributions, it is very
> > valuable to have a secure, simple and transparent way to bootstrap one
> > distro from another without relying on external trust anchors that
> > have to be verified manually.
>
> I agree that it makes sense to place a trust anchor in the Ubuntu
> archive, assuming that there's someone who commits to maintaining it (as
> you've said you will).
>
> What I don't understand is why all of this seems far more complicated
> than would seem necessary to me. I think this burdens patch pilots and
> the SRU team with unnecessary work for little benefit. Why isn't the
> architecture simpler? I go into that into detail below. Sorry the text
> is long, but there's no way to present a counterargument for something
> that seems unnecessarily complicated without diving into the apparent
> unnecessary complications :-/
>
>
>
> It seems burdensome to me to include a large set of keys and update them
> (presumably) more frequently, when (IMHO) only a single anchor is needed
> which would presumably need updating less frequently. It's not just the
> person maintaining the package, but also somebody else from a privileged
> team is going to have to review changes, whether we conclude that such
> changes should go into -updates or -backports.
>
> Further, how is such a reviewer going to validate the changes? Doing so
> is is crucially important. If this isn't done, then there's a path to
> invalidating all of the trust that is supposed to be achieved by
> including these keys in the first place.
>
> If consensus is to include any form of these packages, I think it's
> essential to also have consensus on what level of validation is
> acceptable, and then have that well documented and tooling provided that
> implements it. This is so important for keyring-type packages,
> especially where validation isn't obvious because they are coming from
> outside the distribution, that I think it's unreasonable to expect the
> SRU team to review these uploads without this having been thought about
> first. If there's one thing that needs to come out of me asking for
> consensus over the general approach first, over piecemeal updates, it's
> this.
>
> But if all we're doing is taking the keys from other places and updating
> them in Ubuntu, validated by some process that ultimately relies on some
> set of people to assert that the keys are correct, then what are we
> achieving anyway? Can this not just be automated then, and tooling be
> provided in the archive instead, so users can just do that directly when
> they need? Then there would be much reduced burden on maintainence,
> including for the relevant privileged review teams.
>
> We do gain from there being a root of trust in the archive, but that
> only need be a single root of trust to bootstrap trust in live, external
> sources. This is what I mean above when I say that IMHO only a single
> anchor is needed.
>
> Otherwise we're going to get a proliferation of external keyrings that
> need to be maintained, seemingly unbounded. I don't think this
> architecture scales.
>
> Here's an alternative, much simpler architecture. Someone could start an
> "upstream" project that exists for the purpose of maintaining these
> keyrings cross-distro. Let's call that a "cross-distro keyring". The
> most trivial way to implement this would be to use HTTPS, with trust
> rooted via ca-certificates. When a user needs the latest key for
> something external, the tooling would simply fetch the latest keys,
> validating it on the fly. Obvious improvements would be certificate
> pinning, signing of data at rest, etc, but these are implementation
> details that are orthogonal to my point. It would still all work with
> only a single root of trust needed in Ubuntu's archive, and just one
> upstream maintainer rather than a bunch of maintainers across a bunch of
> distributions.
This is discussed of sorts in https://github.com/uapi-group/specifications/issues/115
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
