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

2020-10-12 Thread Alec Warner
On Sun, Oct 11, 2020 at 7:35 AM Joonas Niilola  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
>
>


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

2020-10-11 Thread Joonas Niilola


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



OpenPGP_signature
Description: OpenPGP digital signature


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

2020-10-11 Thread Thomas Deutschmann

On 2020-10-10 22:36, Michał Górny wrote:

On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote:

Another example for something that was not thought to the end and
which was rushed and pushed to our users.


You start this mail with an insult to me.  Why do you keep doing
this? Do you feel that there is some special need for you to try to
diminish me in order to reach your goal?


You seem to be obsessed with the idea that I am your perfect enemy... I 
cannot help you with that.




The whole idea started with assumption that not every developer
will verify the distfile (an assumption I share). But why should we
trust these developers that they will keep an eye on upstream’s
used certificate instead? That does not make any sense for me.


This sounds like 'perfect is the enemy of good'.  If we can't get
this done perfectly good, we should just lie down and do not put any
effort into making things better.


Sort of.


Another point I just want to mention was patch 5 of 6 for 
net-libs/miniupnpc. Did you notice that the ebuild will fetch

public key via HTTP instead of HTTPS?


Is this question to me or to the public?  Because if it's to me,
then yes, I've noticed I couldn't use HTTPS there.  I'm sorry, I'm
not as incompetent as you'd repeatedly trying to prove, you won't win
your argument this way.


See the first paragraph. I really don't understand why you believe I 
want to show world how incompetent anyone is. I am very sure that people 
active in Gentoo know very well that you are *not* incompetent.


I am just showing a design flaw without any judgement. This is a 
technical mailing list. It should be possible to focus on technical 
aspects. One way to respond to that would maybe a discussion how we can 
do that better (see robbat2 mail for example).


I am fully aware that this is still a draft, which is also part of my 
problem but I will address that later.




This will create a chicken-egg problem here: We will record key
information metadata the same way we store information about
distfiles which is temper proofed. But because this is happening in
an automatic way there is not just a theoretical chance that we
will store an attacker’s key in our metadata because who is going
to verify they key? The same developer we distrust (or where we 
just want to avoid to trust) that he/she verified the distfile?


What's the alternative?  Ignoring upstream signatures entirely unless
we can securely fetch the key?  Shoving the problem under the carpet 
and assuming that the developer will have safely set up the key on

his devbox while being totally incompetent at putting it in an
ebuild?


My point here is:

You had the idea to improve something. Which is good. Improvement is 
always appreciated.


But it must be an improvement. I expect that during the process, "Hey, I 
think we can do X better... what do you think about doing it that way... 
which will address problem Z..." we are all open minded. That means that 
if we come to the conclusion that something isn't really an improvement 
or so minor that the complexity and everything belongs to that isn't 
worth it, that we all realize, "OK, didn't work as expected. Withdraw 
the idea (maybe just until we find a better way) and move on".




Theories are all nice but do you have any proof of that?  Preferably
one that involves developers who *actually carefully* checked
distfiles. Because my theory says developers don't have infinite time
to audit everything.


I don't think I need a proof for that. I am just picking up your initial 
argument for this new eclass saying "I don't want to need to trust 
developer that distfile was checked carefully, if we would add 
automatism we wouldn't need to trust..." (something I share).


I hoped I would have shown everyone that in the end we are only *moving* 
that trust we don't want to give developers that they carefully checked 
distfiles to keys. In other words: We haven't changed anything -- we 
gained nothing. We still have to trust developers that they carefully 
check something, now just keys instead of distfiles. The previous 
'problem' this eclass wanted to improve (solve?) is still there.


...and from my POV we got an additional problem because we now have a 
system which will tell user, "No... distfile looks good, signature is 
fine" which weighs the user in a false sense of security (even Google 
had to learn that when they replaced padlock with "Secure" in browsers 
-- suddenly users stopped using their own brain because they trusted 
system too much which was telling them that the site which looks like 
their bank but wasn't their bank's site was secure).


Not to mention when this system will force users to connect to arbitrary 
key servers...



Are you arguing that we should remove commit signatures as well?  Or 
does it happen that with roughly the same technology and the same 
people, one layer is secure and another similar layer is totally 
bonkers?


No. First you need to understand Gento

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

2020-10-10 Thread Michał Górny
On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote:
> Another example for something that was not thought to the end and which 
> was rushed and pushed to our users.

You start this mail with an insult to me.  Why do you keep doing this?
 Do you feel that there is some special need for you to try to diminish
me in order to reach your goal?

>  Sorry for being late to this but any 
> addition should really add a benefit. What is the benefit verify-sig is 
> adding?
> 
> When mgorny started to propose this in #-qa, he used the argument to 
> improve security of Gentoo because we cannot know if every Gentoo 
> developer is really verifying distfiles or just copying ebuild to new 
> version and let `repoman commit` fetch the distfile and be done with the 
> bump. While I agree with the idea in general, i.e. when you would be 
> able to provide an automatism for that, that would be a great addition.
> 
> But there is a problem.
> 
> You cannot automate trust.
> 
> And anyone who is trying to do that shows that he/she does not 
> understand how signing works and because of the fact he/she will claim 
> security was improved, security was actually lowered due to that.

It would be nice if you could lead your argument in another way than
'see, public, he must be wrong, he does not understand what he is
doing!'

> How is that?
> 
> Because the statement you can get from a signature depends on the trust 
> in the used key. I.e. you assume that the key used to create that 
> signature is only accessible by the designated owner and that nobody 
> else have access to it. In the moment you learn that somebody else 
> gained access to that key, i.e. can create signatures using the same 
> key, you can no longer trust that key. More important, you should start 
> questioning previously seen signatures (if you take it serious you will 
> distrust any files signed by that key and demand on a new signature with 
> a new key where you managed to establish a new trust).
> 
> Short excerpt:
> Code signing is nothing new. It is an important layer in Microsoft’s 
> security defense. Even Apple is relying on signatures for their sandbox 
> they introduced some years ago. But does a signature prevent anything? 
> Of course not. StuxNet was signed with a valid signature from Realtek 
> Semiconductor Corp. and switched later to a signature which belongs to 
> JMicron Technology Corp when Realtek’s signature got revoked. A 
> post-mortem analysis suggested that cybercriminals compromised both 
> organizations and have stolen their development certificates, including 
> the private keys used to sign the executables. In 2014, when Sony 
> Pictures got hacked, attackers had signed the malware with valid 
> certificates from *Sony*. But that is only the tip of the iceberg, see 
> https://attack.mitre.org/techniques/T1553/002/ for more examples. My 
> point here is, and I believe we all agree on this, that signatures alone 
> are meaningless.
> 
> To add a meaning to signatures you must trust the signer that he/she 
> will immediately revoke the certificate once he/she gets aware that an 
> unauthorized third party gained access to the certificate. If we, for an 
> unknown reason, assume that this will happen, we will face another 
> problem: We must receive this information. If we do not know that 
> something has happened to the key, we will not take any actions.
> I guess you all still remember how you created your GPG key for Gentoo, 
> don’t you? Do you still have access to the revocation certificate you 
> created during that process? I am sure you do. But do you know how this 
> process works? Right, you need to upload that certificate to a key 
> server. But then 2019 happened. Key servers are dead now. You can no 
> longer rely on key servers, especially not that once you have uploaded 
> your revocation certificate that it will spread and reach users. Just do 
> an easy exercise: Check who committed to Gentoo repository in past 6 
> months. Now try to fetch the GPG key of all committers without using 
> *.gentoo.org. Good luck! And no, WKD cannot help you with that (revocation).
> 
> Coming back to my initial statement that it is all about automatization.

Thank you for coming back to the point.  I understand that an important
point in every argument is to include a lot of text but our (readers!)
time is limited.

> 
> The whole idea started with assumption that not every developer will 
> verify the distfile (an assumption I share). But why should we trust 
> these developers that they will keep an eye on upstream’s used 
> certificate instead? That does not make any sense for me.

This sounds like 'perfect is the enemy of good'.  If we can't get this
done perfectly good, we should just lie down and do not put any effort
into making things better.

> Another point I just want to mention was patch 5 of 6 for 
> net-libs/miniupnpc. Did you notice that the ebuild will fetch public key 
> via HTTP instead of HTTPS?

Is this 

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

2020-10-10 Thread Thomas Deutschmann

Hi,

I am really unhappy with this addition.

Another example for something that was not thought to the end and which 
was rushed and pushed to our users. Sorry for being late to this but any 
addition should really add a benefit. What is the benefit verify-sig is 
adding?


When mgorny started to propose this in #-qa, he used the argument to 
improve security of Gentoo because we cannot know if every Gentoo 
developer is really verifying distfiles or just copying ebuild to new 
version and let `repoman commit` fetch the distfile and be done with the 
bump. While I agree with the idea in general, i.e. when you would be 
able to provide an automatism for that, that would be a great addition.


But there is a problem.

You cannot automate trust.

And anyone who is trying to do that shows that he/she does not 
understand how signing works and because of the fact he/she will claim 
security was improved, security was actually lowered due to that.


How is that?

Because the statement you can get from a signature depends on the trust 
in the used key. I.e. you assume that the key used to create that 
signature is only accessible by the designated owner and that nobody 
else have access to it. In the moment you learn that somebody else 
gained access to that key, i.e. can create signatures using the same 
key, you can no longer trust that key. More important, you should start 
questioning previously seen signatures (if you take it serious you will 
distrust any files signed by that key and demand on a new signature with 
a new key where you managed to establish a new trust).


Short excerpt:
Code signing is nothing new. It is an important layer in Microsoft’s 
security defense. Even Apple is relying on signatures for their sandbox 
they introduced some years ago. But does a signature prevent anything? 
Of course not. StuxNet was signed with a valid signature from Realtek 
Semiconductor Corp. and switched later to a signature which belongs to 
JMicron Technology Corp when Realtek’s signature got revoked. A 
post-mortem analysis suggested that cybercriminals compromised both 
organizations and have stolen their development certificates, including 
the private keys used to sign the executables. In 2014, when Sony 
Pictures got hacked, attackers had signed the malware with valid 
certificates from *Sony*. But that is only the tip of the iceberg, see 
https://attack.mitre.org/techniques/T1553/002/ for more examples. My 
point here is, and I believe we all agree on this, that signatures alone 
are meaningless.


To add a meaning to signatures you must trust the signer that he/she 
will immediately revoke the certificate once he/she gets aware that an 
unauthorized third party gained access to the certificate. If we, for an 
unknown reason, assume that this will happen, we will face another 
problem: We must receive this information. If we do not know that 
something has happened to the key, we will not take any actions.
I guess you all still remember how you created your GPG key for Gentoo, 
don’t you? Do you still have access to the revocation certificate you 
created during that process? I am sure you do. But do you know how this 
process works? Right, you need to upload that certificate to a key 
server. But then 2019 happened. Key servers are dead now. You can no 
longer rely on key servers, especially not that once you have uploaded 
your revocation certificate that it will spread and reach users. Just do 
an easy exercise: Check who committed to Gentoo repository in past 6 
months. Now try to fetch the GPG key of all committers without using 
*.gentoo.org. Good luck! And no, WKD cannot help you with that (revocation).


Coming back to my initial statement that it is all about automatization.

The whole idea started with assumption that not every developer will 
verify the distfile (an assumption I share). But why should we trust 
these developers that they will keep an eye on upstream’s used 
certificate instead? That does not make any sense for me.


Another point I just want to mention was patch 5 of 6 for 
net-libs/miniupnpc. Did you notice that the ebuild will fetch public key 
via HTTP instead of HTTPS? This will create a chicken-egg problem here: 
We will record key information metadata the same way we store 
information about distfiles which is temper proofed. But because this is 
happening in an automatic way there is not just a theoretical chance 
that we will store an attacker’s key in our metadata because who is 
going to verify they key? The same developer we distrust (or where we 
just want to avoid to trust) that he/she verified the distfile?


Do you see the contradiction?

Please do not get me wrong. I like the idea. But I also understand that 
you cannot implement it in a secure and really working way -- you will 
always require a human paying attention. But now that we pretend, we 
managed to implement that and even show a fancy green message that we 
verified (any) signature, we actually lowe

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

2020-10-06 Thread Michał Górny
On Tue, 2020-10-06 at 14:06 +0200, Ulrich Mueller wrote:
> > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
> > On Tue, 2020-10-06 at 13:34 +0200, Ulrich Mueller wrote:
> > > > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
> > > > On Tue, 2020-10-06 at 13:18 +0200, Ulrich Mueller wrote:
> > > > > > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
> > > > > > +IUSE="+verify-sig"
> > > > > 
> > > > > At least don't enable this by default. The feature increases
> > > > > build time and has little (if any) benefits.
> > > > Do you have any numbers to back this claim?
> > > 
> > > That's a strange question. Obviously build time can only increase if
> > > you install an additional dependency and download an additional
> > > distfile.
> > But how significant is the increase? Can you actually measure it
> > without trying hard to make things slow?
> 
> IMHO it has no benefit at all for users, because distfile integrity is
> already guaranteed by digests. So this is a second and redundant method.
> On the other hand, it causes download of additional distfiles which may
> not be wanted by most users.
> 
> > If you are going to claim that it outweighs the 'little' benefit, you
> > need to try harder than that.
> 
> No. You are the one who wants to introduce a new feature, so it's up to
> you to motivate why (and how) adding a redundant method of distfile
> verification would make things more secure on the users' side.
> 

The eclassdoc answers this question already.  Anyway, v2 disables it
by default, so your concern should be resolved.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Michał Górny wrote:

> On Tue, 2020-10-06 at 13:34 +0200, Ulrich Mueller wrote:
>> > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
>> > On Tue, 2020-10-06 at 13:18 +0200, Ulrich Mueller wrote:
>> > > > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
>> > > > +IUSE="+verify-sig"
>> > > 
>> > > At least don't enable this by default. The feature increases
>> > > build time and has little (if any) benefits.
>> > Do you have any numbers to back this claim?
>> 
>> That's a strange question. Obviously build time can only increase if
>> you install an additional dependency and download an additional
>> distfile.

> But how significant is the increase? Can you actually measure it
> without trying hard to make things slow?

IMHO it has no benefit at all for users, because distfile integrity is
already guaranteed by digests. So this is a second and redundant method.
On the other hand, it causes download of additional distfiles which may
not be wanted by most users.

> If you are going to claim that it outweighs the 'little' benefit, you
> need to try harder than that.

No. You are the one who wants to introduce a new feature, so it's up to
you to motivate why (and how) adding a redundant method of distfile
verification would make things more secure on the users' side.

It is one thing to have this as a convenience eclass for developers
(though I still think it's over-engineered), but another thing to make
it the default for all users.

Ulrich



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

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Frédéric Pierret wrote:

>> We've already discussed it in #-qa, and I still think that this is
>> over-engineered. Users can validate the distfile by the Manifest and
>> its signature, so exposing the feature to users is redundant.

> IMHO, manifest verification and distfile verification are two separate
> things. Before you validate and sign the Manifest, you need to fetch
> (new) source and to verify it. This is not redundant at all.

The eclass adds a second method of distfile verification on the user's
side. So unless the feature is intended to replace digest verification
on the long term (which I hope it isn't), it is redundant for users.

It may be fine as an opt-in feature for developers, but I believe that
enabling it by default for all users is wrong.

Ulrich


signature.asc
Description: PGP signature


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

2020-10-06 Thread Frédéric Pierret
Hi,

Le 2020-10-06 à 13:17, Ulrich Mueller a écrit :
>> On Tue, 06 Oct 2020, Michał Górny wrote:
> 
>> verify-sig eclass provides a streamlined approach to verifying upstream
>> signatures on distfiles.  Its primary purpose is to permit developers
>> to easily verify signatures while bumping packages.  The eclass removes
>> the risk of developer forgetting to perform the verification,
>> or performing it incorrectly, e.g. due to additional keys in the local
>> keyring.  It also permits users to verify the developer's work.
> 
> We've already discussed it in #-qa, and I still think that this is
> over-engineered. Users can validate the distfile by the Manifest and its
> signature, so exposing the feature to users is redundant.

IMHO, manifest verification and distfile verification are two separate things. 
Before you validate and sign the Manifest, you need to fetch (new) source and 
to verify it. This is not redundant at all.

Best,
Frédéric Pierret



signature.asc
Description: OpenPGP digital signature


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

2020-10-06 Thread Michał Górny
On Tue, 2020-10-06 at 13:34 +0200, Ulrich Mueller wrote:
> > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
> > On Tue, 2020-10-06 at 13:18 +0200, Ulrich Mueller wrote:
> > > > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
> > > > +IUSE="+verify-sig"
> > > 
> > > At least don't enable this by default. The feature increases build time
> > > and has little (if any) benefits.
> > Do you have any numbers to back this claim?
> 
> That's a strange question. Obviously build time can only increase if you
> install an additional dependency and download an additional distfile.
> 

But how significant is the increase?  Can you actually measure it
without trying hard to make things slow?  If you are going to claim that
it outweighs the 'little' benefit, you need to try harder than that.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Michał Górny wrote:

> On Tue, 2020-10-06 at 13:18 +0200, Ulrich Mueller wrote:
>> > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
>> > +IUSE="+verify-sig"
>> 
>> At least don't enable this by default. The feature increases build time
>> and has little (if any) benefits.

> Do you have any numbers to back this claim?

That's a strange question. Obviously build time can only increase if you
install an additional dependency and download an additional distfile.

Ulrich


signature.asc
Description: PGP signature


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

2020-10-06 Thread Michał Górny
On Tue, 2020-10-06 at 13:18 +0200, Ulrich Mueller wrote:
> > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
> > +IUSE="+verify-sig"
> 
> At least don't enable this by default. The feature increases build time
> and has little (if any) benefits.
> 

Do you have any numbers to back this claim?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Michał Górny wrote:

> +IUSE="+verify-sig"

At least don't enable this by default. The feature increases build time
and has little (if any) benefits.

Ulrich


signature.asc
Description: PGP signature


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

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Michał Górny wrote:

> verify-sig eclass provides a streamlined approach to verifying upstream
> signatures on distfiles.  Its primary purpose is to permit developers
> to easily verify signatures while bumping packages.  The eclass removes
> the risk of developer forgetting to perform the verification,
> or performing it incorrectly, e.g. due to additional keys in the local
> keyring.  It also permits users to verify the developer's work.

We've already discussed it in #-qa, and I still think that this is
over-engineered. Users can validate the distfile by the Manifest and its
signature, so exposing the feature to users is redundant.

Ulrich


signature.asc
Description: PGP signature


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

2020-10-06 Thread Michał Górny
verify-sig eclass provides a streamlined approach to verifying upstream
signatures on distfiles.  Its primary purpose is to permit developers
to easily verify signatures while bumping packages.  The eclass removes
the risk of developer forgetting to perform the verification,
or performing it incorrectly, e.g. due to additional keys in the local
keyring.  It also permits users to verify the developer's work.
---
 eclass/verify-sig.eclass | 177 +++
 1 file changed, 177 insertions(+)
 create mode 100644 eclass/verify-sig.eclass

diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
new file mode 100644
index ..8bf48446f427
--- /dev/null
+++ b/eclass/verify-sig.eclass
@@ -0,0 +1,177 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: verify-sig.eclass
+# @MAINTAINER:
+# Michał Górny 
+# @SUPPORTED_EAPIS: 7
+# @AUTHOR:
+# Michał Górny 
+# @BLURB: Eclass to verify upstream signatures on distfiles
+# @DESCRIPTION:
+# verify-sig eclass provides a streamlined approach to verifying
+# upstream signatures on distfiles.  Its primary purpose is to permit
+# developers to easily verify signatures while bumping packages.
+# The eclass removes the risk of developer forgetting to perform
+# the verification, or performing it incorrectly, e.g. due to additional
+# keys in the local keyring.  It also permits users to verify
+# the developer's work.
+#
+# To use the eclass, start by packaging the upstream's key
+# as app-crypt/openpgp-keys-*.  Then inherit the eclass, add detached
+# signatures to SRC_URI and set VERIFY_SIG_OPENPGP_KEY_PATH.  The eclass
+# provides verify-sig USE flag to toggle the verification.
+#
+# Example use:
+# @CODE
+# inherit verify-sig
+#
+# SRC_URI="https://example.org/${P}.tar.gz
+#   verify-sig? ( https://example.org/${P}.tar.gz.sig )"
+# BDEPEND="
+#   verify-sig? ( app-crypt/openpgp-keys-example )"
+#
+# VERIFY_SIG_OPENPGP_KEY_PATH=/usr/share/openpgp-keys/example.asc
+# @CODE
+
+case "${EAPI:-0}" in
+   0|1|2|3|4|5|6)
+   die "Unsupported EAPI=${EAPI} (obsolete) for ${ECLASS}"
+   ;;
+   7)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
+
+EXPORT_FUNCTIONS src_unpack
+
+if [[ ! ${_VERIFY_SIG_ECLASS} ]]; then
+
+IUSE="+verify-sig"
+
+BDEPEND="
+   verify-sig? (
+   app-crypt/gnupg
+   >=app-portage/gemato-16
+   )"
+
+# @ECLASS-VARIABLE: VERIFY_SIG_OPENPGP_KEY_PATH
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Path to key bundle used to perform the verification.  This is required
+# when using default src_unpack.  Alternatively, the key path can be
+# passed directly to the verification functions.
+
+# @ECLASS-VARIABLE: VERIFY_SIG_OPENPGP_KEYSERVER
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Keyserver used to refresh keys.  If not specified, the keyserver
+# preference from the key will be respected.  If no preference
+# is specified by the key, the GnuPG default will be used.
+
+# @ECLASS-VARIABLE: VERIFY_SIG_OPENPGP_KEY_REFRESH
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Attempt to refresh keys via WKD/keyserver.  Set it to "yes"
+# in make.conf to enable.  Note that this requires working Internet
+# connection.
+: ${VERIFY_SIG_OPENPGP_KEY_REFRESH:=no}
+
+# @FUNCTION: verify-sig_verify_detached
+# @USAGE:   []
+# @DESCRIPTION:
+# Read the detached signature from  and verify  against
+# it.   can either be passed directly, or it defaults
+# to VERIFY_SIG_OPENPGP_KEY_PATH.  The function dies if verification
+# fails.
+verify-sig_verify_detached() {
+   local file=${1}
+   local sig=${2}
+   local key=${3:-${VERIFY_SIG_OPENPGP_KEY_PATH}}
+
+   [[ -n ${key} ]] ||
+   die "${FUNCNAME}: no key passed and VERIFY_SIG_OPENPGP_KEY_PATH 
unset"
+
+   local extra_args=()
+   [[ ${VERIFY_SIG_OPENPGP_KEY_REFRESH} == yes ]] || extra_args+=( -R )
+   [[ -n ${VERIFY_SIG_OPENPGP_KEYSERVER+1} ]] && extra_args+=(
+   --keyserver "${VERIFY_SIG_OPENPGP_KEYSERVER}"
+   )
+
+   einfo "Verifying ${file##*/} ..."
+   gemato gpg-wrap -K "${key}" "${extra_args[@]}" -- \
+   gpg --verify "${sig}" "${file}" ||
+   die "PGP signature verification failed"
+}
+
+# @FUNCTION: verify-sig_src_unpack
+# @DESCRIPTION:
+# Default src_unpack override that verifies signatures for all
+# distfiles if 'verify-sig' flag is enabled.  The function dies if any
+# of the signatures fails to verify or if any distfiles are not signed.
+# Please write src_unpack() yourself if you need to perform partial
+# verification.
+verify-sig_src_unpack() {
+   if use verify-sig; then
+   local f suffix found
+   local distfiles=() signatures=() nosigfound=() straysigs=()
+
+   # find all distfiles and signatures, and combine them
+   for f in ${A}; do
+