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

On Wed, Oct 16, 2024 at 9:13 AM Robie Basak <robie.basak@ubuntu.com> wrote:
>
> On Wed, Oct 16, 2024 at 08:48:25AM -0400, Neal Gompa wrote:
> > Question then: what makes archlinux-keyring or debian-*-keyring
> > packages different from distribution-gpg-keys? Shouldn't both of them
> > get kicked out of the Ubuntu archive for the same reason?
>
> This is not a valid comparison. I already covered this in a previous
> reply[1]. Note though that I made no suggestion that any package should
> get "kicked out". I was only referring to SRUs.
>

I know you didn't, but if they can't be updated ever, then they
shouldn't be in the archive in the first place. Strictly speaking,
keyring packages that cannot be updated are much worse than having
them at all. It lures people into a false sense of security,
especially around verifying the integrity of content using those keys.
If we apply the same standard to all keyring packages used to manage
and verify software, then keyring packages that cannot be updated need
to be kicked out, because it's extremely important that they can be
updated.

Incidentally, as a member of distribution-gpg-keys upstream, my only
real ask for any distribution shipping is to not fork the sources as
part of packaging it. In Debian terms, that means don't use the
typical git-buildpackage workflow that creates an exploded git source
tree and merges a debian folder into that source tree. That makes it
really hard to determine whether someone has mucked around with the
sources as part of packaging it.

If Ubuntu (or any distribution) decides to make it hard to update
keyring packages, I would rather you didn't package it at all and
remove them from the archive. It does a disservice to users of that
distribution if they can't be updated post-GA.

--
Neal Gompa (FAS: ngompa)

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [was: Enhancing cross-distro collaboration via foreign archive keyring availability]

On Wed, 16 Oct 2024 at 13:10, Robie Basak <robie.basak@ubuntu.com> wrote:
>
> [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

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

On Wed, Oct 16, 2024 at 08:48:25AM -0400, Neal Gompa wrote:
> Question then: what makes archlinux-keyring or debian-*-keyring
> packages different from distribution-gpg-keys? Shouldn't both of them
> get kicked out of the Ubuntu archive for the same reason?

This is not a valid comparison. I already covered this in a previous
reply[1]. Note though that I made no suggestion that any package should
get "kicked out". I was only referring to SRUs.

On Wed, Oct 16, 2024 at 01:59:18PM +0100, Luca Boccassi wrote:

[reordered to keep the same threads together]

> Also I'll note that _no other package_ (including other keyrings) are
> subject to these same restrictions, so it seems very, very strange
> that somehow only my use case should be subject to this treatment.

This is not a valid comparison. I already covered this in a previous
reply[1].

On Wed, Oct 16, 2024 at 01:59:18PM +0100, Luca Boccassi wrote:
> Thanks for sharing your opinion. I'll note that there were several
> others who also shared theirs, and they agreed with my proposal, there
> were no other objections so far.

Ubuntu does not make decisions by popular vote, and generally Ubuntu
developers with concurring opinions do not vote. The lack of supporting
voices therefore does not imply that there aren't any. I do not speak
for Ubuntu alone of course. See the Ubuntu Code of Conduct[2] (perhaps a
misnomer here since I'm not referring to "conduct") for details of how
decisions are made in Ubuntu.

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2024-September/043129.html
[2] https://ubuntu.com/community/ethos/code-of-conduct

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

On Wed, 16 Oct 2024 at 12:56, Robie Basak <robie.basak@ubuntu.com> wrote:
>
> I don't have anything further to add to this sub-thread. I think I've
> made valid points about what our requirements should be to ensure that
> changes to key material are done in a way that our users can trust, why
> not doing so would reduce user security compared to what happens in
> Debian, and justified my position. I've also made some suggestions on
> how I think this can be implemented without too much pain.

I have already demonstrated how there would be no security/trust
downgrade, and in fact my simple proposal would already provide a
safer workflow than is already used to update Ubuntu's own keyring,
which is orders of magnitude more important than any of this, given
it's used to update the host system itself. I also have demonstrated
that the changes you propose are unnecessary, incredibly onerous, and
almost seem designed to punish this one specific case and make it
de-facto impossible, forcing users to download random stuff from the
internet on-the-fly which breaks offline builds, reproducible builds
and _is_ a security downgrade.

> If you don't want to do those things, then my opinion is that these
> changes are not suitable for SRU in Ubuntu.

Thanks for sharing your opinion. I'll note that there were several
others who also shared theirs, and they agreed with my proposal, there
were no other objections so far.
Also I'll note that _no other package_ (including other keyrings) are
subject to these same restrictions, so it seems very, very strange
that somehow only my use case should be subject to this treatment.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

On Wed, Oct 16, 2024 at 7:56 AM Robie Basak <robie.basak@ubuntu.com> wrote:
>
> I don't have anything further to add to this sub-thread. I think I've
> made valid points about what our requirements should be to ensure that
> changes to key material are done in a way that our users can trust, why
> not doing so would reduce user security compared to what happens in
> Debian, and justified my position. I've also made some suggestions on
> how I think this can be implemented without too much pain.
>
> If you don't want to do those things, then my opinion is that these
> changes are not suitable for SRU in Ubuntu.

Question then: what makes archlinux-keyring or debian-*-keyring
packages different from distribution-gpg-keys? Shouldn't both of them
get kicked out of the Ubuntu archive for the same reason?

--
Neal Gompa (FAS: ngompa)

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[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.

> 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.

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.

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

I don't have anything further to add to this sub-thread. I think I've
made valid points about what our requirements should be to ensure that
changes to key material are done in a way that our users can trust, why
not doing so would reduce user security compared to what happens in
Debian, and justified my position. I've also made some suggestions on
how I think this can be implemented without too much pain.

If you don't want to do those things, then my opinion is that these
changes are not suitable for SRU in Ubuntu.