Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

[Alec Warner]

On Sun, Oct 11, 2020 at 7:35 AM Joonas Niilola <juippis@g.o> wrote:

>
>
> On 10/11/20 4:40 PM, Thomas Deutschmann wrote:
> >
> >
> > First of all, calm down. You are reading too much into this. Just
> > revert your own logic: You obviously like your idea, worked on this
> > and pushed it to repository. Don't you see that anyone could ask the
> > same? Who are you? Why do believe that you can force something like
> > that down to everyone's system? That feature got enabled in developers
> > profiles by default, it will blow up distfiles with useless data (a
> > view you can have when you share my concerns and don't see any
> > problems with current Manifest system; For example we banned stuff in
> > $FILESDIR before and asked developers to move them to d.g.o when >25kb
> > in total arguing that large distfile is affecting *any* user... I am
> > not comparing this 1:1 but to repeat your question: Who are you that
> > you can decide to force something similar down to everyone).
> >
> >
> > Sure, if I am the only having that opinion and most people see a value
> > in this and disagree with me...
>

I split this into three parts:

(1) Is there a problem? I like to think there is general agreement that
developers do not cryptographically verify distfiles for most upstreams
when bumping, and thus we could all agree there is room for improvement
here. In an ideal world we are relying on existing systems (https, CAs,
etc) to prevent MITM attacks on source downloads, but not much is used
beyond that.
(2) Does the proposed solution help? This is not a yes or no question; its
nuanced. Having a keyring makes verifying easier. As Whissi notes, we don't
discuss much the managing of said keyrings (or revocation) and so I think
the proposed solution does have similar problems to the existing solution.
Instead of managing and verifying upstream tarballs, we have to verify
keys. There is no automation for this either...and so we end up with a
similar attack surface. There is *improvement* (if someone MITMs your
download, the verification will notice.) Is that the most likely attack, or
is it stolen upstream signing keys? Who can really say?
(3) The implementation. This is honestly the part that I dislike the most,
particularly in the original draft, some of the problems have been fixed
already. I'm not excited about thousands of new packages, nor am I excited
about the key management in the proposal. The biggest problem (that it was
on by default) were already fixed which is good; I don't even see this as a
feature for end users at all; instead its a feature for developers and
maybe a QA bot (that verifies the distfiles.)

Leading out of 3, maybe that is a decent solution also. Can we build a QA
bot that detects bad bumps but also has not terrible key management? Is
there an automated protocol for fetching *and* verifying upstream files
like this? Could we annotate SRC_URI somehow with verification metadata?

-A



> >
> >
> I vote for disabling that USE flag in developer profile. There are more
> than 1 person using it not yet buying or understanding this "draft". I
> also believe such a profile flag change should be discussed first.
>
> -- juippis
>
>