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
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
