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