Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
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
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
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
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
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
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
> 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
> 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
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
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
> 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
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
> 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
> 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
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
+
