Re: Regarding ideas to replace gpgv with sqv
On Tue, Feb 02, 2021 at 04:12:19PM +0100, Julian Andres Klode wrote:
> On Tue, Feb 02, 2021 at 01:58:38PM +0100, Neal H. Walfield wrote:
> > Thanks for following up.
> >
> > On Tue, 02 Feb 2021 13:48:15 +0100,
> > Julian Andres Klode wrote:
> > > On Sun, Jan 31, 2021 at 02:01:02PM +0100, Neal H. Walfield wrote:
> > > > On Thu, 28 Jan 2021 11:15:18 +0100,
> > > > Julian Andres Klode wrote:
> > > I don't care about these ports as we don't need to provide security support
> > > for them, so well, so keeping frozen gpgv code paths around would work
> > > (heck, they'll still get updated anyway, but no need to rush out updates
> > > for stable releases in like 8 years or so when the existing stable
> > > releases have all EOLed).
> >
> > Ok.
> >
> > > > If apt were to use SOP, you'd only have to maintain a single code
> > > > path, but different distributions and different architectures could
> > > > still use their preferred OpenPGP backend.
> > >
> > > Different backends have different bugs, so we do want to use the same
> > > backends across major distros to ensure that we all see the same bugs.
> >
> > I agree with this concern.
> >
> >
> > It sounds like you are suggesting that adding Sequoia directly to apt
> > would be the best way forward given the trade offs. But, you didn't
> > say that explicitly. Did I understand correctly?
>
> I cannot say that. Work me says this needs extensive internal discussions
> at Canonical to figure out what we can support on the Ubuntu side - Sequioa
> is not an easy pill to swallow with its over 100 dependencies[1].
>
> Maybe we should instead migrate from OpenPGP to using Ed25519 keys
> directly, there is not a lot of value in OpenPGP after all, and a lot of
> issues like the inability to deprecate MD5 or SHA1 for ages. OpenBSD
> did that with its signify tool, and it seems to work well for them.
We have a rough draft / brain dump of the Ed25519 signing @
https://wiki.debian.org/Teams/Apt/Spec/AptSign
and a proof of concept at
https://gist.github.com/julian-klode/4514ce39d3dc62647b502e5a8cf6a3ef
This one is fairly trivial, and if you have some extra data (mapping
of public keys <-> key ids really) you should eventuall be able to cross-verify
it against minisign and signify, though I've not tested that yet.
Note that the key is probably not a valid Ed25519 key, but it works well
enough. Key generation is hard, better leave it to others :D
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: