>
> [Splitting into more than one sub-thread; this sub-thread is about the
> architecture]
>
> On Wed, Sep 11, 2024 at 04:38:27PM +0200, Luca Boccassi wrote:
> > Regarding the alternative proposal, unfortunately there are several
> > show-stoppers: it essentially boils down to downloading stuff from the
> > internet at build time, which is exactly what we want to avoid. This
> > is how the Arch keyring used to work - you needed to build and ship
> > custom software, and run it at build time, and it would fetch and
> > prepare keys on the fly. It was an absolute nightmare, it constantly
> > broke, and made it impossible to support stable updates, and I am very
> > glad that was changed and now it's just a set of keys like everything
> > else. Breaking reproducible builds, making it impossible to have
> > offline builds, making it impossible to take advantage of well known
> > and well implemented package caching and mirroring, it requires having
> > to trust the internet CAs, and these are all deal breakers I'm afraid.
>
> I don't think any of these things are showstoppers. You describe above
> a set of properties that you claim wouldn't be able to be maintained in
> the alternate architecture I outlined. I disagree. I think my outline
> architecture can incorporate those things without difficulty with minor
> changes that are straightforward, without compromising the idea as a
> whole.
They are showstoppers. As far as I understand you do not use any of
this, and never have, correct me if I am wrong - if the actual users
tell you this doesn't work, it seems very weird to keep insisting that
it does, especially with no experience with any of these tools.
> > If it was acceptable to just download the latest things from the
> > internet, we'd already do it, but it's exactly what we want to avoid,
> > and use packaged content instead, so it would be a net downgrade.
>
> As I explained, using a cross-distro trust root in practice requires you
> to download the other distribution you're trying to bootstrap.
> Downloading the necessary keys to validate that bootstrap at the same
> time does not add any additional difficulty, since by definition you're
> online.
As already mentioned, that is incorrect, as we already know how to
mirror package repositories for offline builds, this is a solved
problem and has been for a long time already. Your proposal would
break reproducible builds, offline builds and require downloading
random stuff off the internet, in a curl | sudo bash fashion. That is
simply not acceptable, sorry.
> I think I've already argued my point sufficiently so I won't argue it
> further.
>
> Nick Rosbrook and Shengjing Zhu also commented in the thread, but their
> positions seem to be based on the assumption that what you say about my
> proposed architecture is accurate. I claim that it is not.
>
> IMHO, this is an unnecessary additional burden on Ubuntu maintainers.
> But even if we were to set this aside, I think that having an agreed
> process to validate keyring changes in SRUs is of paramount importance
> to this effort. Otherwise there would be no basis for users to trust the
> keyring, and that would defeat the entire point of placing it in a
> trusted archive and you might as well use a PPA or something. But that
> discussion can continue in the other subthread.
There is no additional burden for Ubuntu maintainers, in fact it's
much easier than the vast majority of other packages.
Also there are no other packages, with binary or source content, that
are being subject to such punitive restrictions. As already mentioned,
you do not do any of what you propose for Ubuntu's own keyring, which
I think is enough to put any counter-argument to bed.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
