* [gentoo-dev] [PATCH 2/5] use.desc: Add verify-sig flag
2020-10-06 9:58 [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Michał Górny
@ 2020-10-06 9:58 ` Michał Górny
2020-10-06 9:58 ` [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst Michał Górny
` (5 subsequent siblings)
6 siblings, 0 replies; 23+ messages in thread
From: Michał Górny @ 2020-10-06 9:58 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
profiles/use.desc | 1 +
1 file changed, 1 insertion(+)
diff --git a/profiles/use.desc b/profiles/use.desc
index a0104c8a2f76..ef9f4da57215 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -334,6 +334,7 @@ vala - Enable bindings for dev-lang/vala
vanilla - Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically
vcd - Video CD support
vdpau - Enable the Video Decode and Presentation API for Unix acceleration interface
+verify-sig - Verify upstream signatures on distfiles
vhosts - Add support for installing web-based applications into a virtual-hosting environment
videos - Install optional video files (used in some games)
vim-syntax - Pulls in related vim syntax scripts
--
2.28.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst
2020-10-06 9:58 [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Michał Górny
2020-10-06 9:58 ` [gentoo-dev] [PATCH 2/5] use.desc: Add verify-sig flag Michał Górny
@ 2020-10-06 9:58 ` Michał Górny
2020-10-06 11:26 ` Ulrich Mueller
2020-10-06 9:58 ` [gentoo-dev] [PATCH 4/5] net-libs/miniupnpc: Use verify-sig.eclass Michał Górny
` (4 subsequent siblings)
6 siblings, 1 reply; 23+ messages in thread
From: Michał Górny @ 2020-10-06 9:58 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
app-crypt/openpgp-keys-miniupnp/Manifest | 2 ++
app-crypt/openpgp-keys-miniupnp/metadata.xml | 9 ++++++++
.../openpgp-keys-miniupnp-20201006.ebuild | 23 +++++++++++++++++++
3 files changed, 34 insertions(+)
create mode 100644 app-crypt/openpgp-keys-miniupnp/Manifest
create mode 100644 app-crypt/openpgp-keys-miniupnp/metadata.xml
create mode 100644 app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
diff --git a/app-crypt/openpgp-keys-miniupnp/Manifest b/app-crypt/openpgp-keys-miniupnp/Manifest
new file mode 100644
index 000000000000..c8f82da42fa6
--- /dev/null
+++ b/app-crypt/openpgp-keys-miniupnp/Manifest
@@ -0,0 +1,2 @@
+DIST A31ACAAF.asc 3139 BLAKE2B 4574c3f37965fafa4e2d703276a585d1f17b0da862042620681bac591062b3b70c52cbe5481da543d3c3193a640c06e9d86c3cef1568ae3a3f62901a6ad200ab SHA512 ecad52850fdcc7c21bab81917b3cea85c48b751534427d3db5750c43cbce73916ec4879e4f5535d4b87b7eca927ad249e384c5597702a0052afa89c23c5719b9
+DIST A5C0863C.asc 3098 BLAKE2B fdbc8629fd462b9cc72c568b0af5607951055abc03a1e344e4c1b411fb87bfa285c2e29d2781f9e9b02ec0bc63eacf55e5dc19198056a417ba3358dba445cc0c SHA512 adebff655374dbc8a045f9ab148f9fc343b043e80cb7e4e14c66aa56bfb2f0f5521e294c7600ca708893efc84679f788116d82ef5818370f1425f03dea0a77b9
diff --git a/app-crypt/openpgp-keys-miniupnp/metadata.xml b/app-crypt/openpgp-keys-miniupnp/metadata.xml
new file mode 100644
index 000000000000..5a5a3aaf4299
--- /dev/null
+++ b/app-crypt/openpgp-keys-miniupnp/metadata.xml
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+<pkgmetadata>
+ <maintainer type="person">
+ <email>mgorny@gentoo.org</email>
+ <name>Michał Górny</name>
+ </maintainer>
+ <stabilize-allarches/>
+</pkgmetadata>
diff --git a/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild b/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
new file mode 100644
index 000000000000..4b07eeca6024
--- /dev/null
+++ b/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
@@ -0,0 +1,23 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+DESCRIPTION="OpenPGP keys used to sign miniupnp* packages"
+HOMEPAGE="http://miniupnp.free.fr/files/"
+SRC_URI="
+ http://miniupnp.free.fr/A31ACAAF.asc
+ http://miniupnp.free.fr/A5C0863C.asc
+"
+
+LICENSE="public-domain"
+SLOT="0"
+KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv s390 sparc x86"
+
+S=${WORKDIR}
+
+src_install() {
+ local files=( ${A} )
+ insinto /usr/share/openpgp-keys
+ newins - miniupnp.asc < <(cat "${files[@]/#/${DISTDIR}/}")
+}
--
2.28.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst
2020-10-06 9:58 ` [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst Michał Górny
@ 2020-10-06 11:26 ` Ulrich Mueller
2020-10-06 11:44 ` Michał Górny
0 siblings, 1 reply; 23+ messages in thread
From: Ulrich Mueller @ 2020-10-06 11:26 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 3225 bytes --]
>>>>> On Tue, 06 Oct 2020, Michał Górny wrote:
> Signed-off-by: Michał Górny <mgorny@gentoo.org>
> ---
> app-crypt/openpgp-keys-miniupnp/Manifest | 2 ++
> app-crypt/openpgp-keys-miniupnp/metadata.xml | 9 ++++++++
> .../openpgp-keys-miniupnp-20201006.ebuild | 23 +++++++++++++++++++
> 3 files changed, 34 insertions(+)
> create mode 100644 app-crypt/openpgp-keys-miniupnp/Manifest
> create mode 100644 app-crypt/openpgp-keys-miniupnp/metadata.xml
> create mode 100644 app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
> diff --git a/app-crypt/openpgp-keys-miniupnp/Manifest b/app-crypt/openpgp-keys-miniupnp/Manifest
> new file mode 100644
> index 000000000000..c8f82da42fa6
> --- /dev/null
> +++ b/app-crypt/openpgp-keys-miniupnp/Manifest
> @@ -0,0 +1,2 @@
> +DIST A31ACAAF.asc 3139 BLAKE2B 4574c3f37965fafa4e2d703276a585d1f17b0da862042620681bac591062b3b70c52cbe5481da543d3c3193a640c06e9d86c3cef1568ae3a3f62901a6ad200ab SHA512 ecad52850fdcc7c21bab81917b3cea85c48b751534427d3db5750c43cbce73916ec4879e4f5535d4b87b7eca927ad249e384c5597702a0052afa89c23c5719b9
> +DIST A5C0863C.asc 3098 BLAKE2B fdbc8629fd462b9cc72c568b0af5607951055abc03a1e344e4c1b411fb87bfa285c2e29d2781f9e9b02ec0bc63eacf55e5dc19198056a417ba3358dba445cc0c SHA512 adebff655374dbc8a045f9ab148f9fc343b043e80cb7e4e14c66aa56bfb2f0f5521e294c7600ca708893efc84679f788116d82ef5818370f1425f03dea0a77b9
> diff --git a/app-crypt/openpgp-keys-miniupnp/metadata.xml b/app-crypt/openpgp-keys-miniupnp/metadata.xml
> new file mode 100644
> index 000000000000..5a5a3aaf4299
> --- /dev/null
> +++ b/app-crypt/openpgp-keys-miniupnp/metadata.xml
> @@ -0,0 +1,9 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
> +<pkgmetadata>
> + <maintainer type="person">
> + <email>mgorny@gentoo.org</email>
> + <name>Michał Górny</name>
> + </maintainer>
> + <stabilize-allarches/>
> +</pkgmetadata>
> diff --git a/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild b/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
> new file mode 100644
> index 000000000000..4b07eeca6024
> --- /dev/null
> +++ b/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
> @@ -0,0 +1,23 @@
> +# Copyright 1999-2020 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +DESCRIPTION="OpenPGP keys used to sign miniupnp* packages"
> +HOMEPAGE="http://miniupnp.free.fr/files/"
> +SRC_URI="
> + http://miniupnp.free.fr/A31ACAAF.asc
> + http://miniupnp.free.fr/A5C0863C.asc
> +"
> +
> +LICENSE="public-domain"
> +SLOT="0"
> +KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv s390 sparc x86"
> +
> +S=${WORKDIR}
> +
> +src_install() {
> + local files=( ${A} )
> + insinto /usr/share/openpgp-keys
> + newins - miniupnp.asc < <(cat "${files[@]/#/${DISTDIR}/}")
> +}
> --
> 2.28.0
This relies again on Manifest digests for the integrity of the key
distfiles themselves. What do we gain by this indirection, as compared
to validating the distfiles of the target package by their Manifest?
Ulrich
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst
2020-10-06 11:26 ` Ulrich Mueller
@ 2020-10-06 11:44 ` Michał Górny
0 siblings, 0 replies; 23+ messages in thread
From: Michał Górny @ 2020-10-06 11:44 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 3520 bytes --]
On Tue, 2020-10-06 at 13:26 +0200, Ulrich Mueller wrote:
> > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
> > Signed-off-by: Michał Górny <mgorny@gentoo.org>
> > ---
> > app-crypt/openpgp-keys-miniupnp/Manifest | 2 ++
> > app-crypt/openpgp-keys-miniupnp/metadata.xml | 9 ++++++++
> > .../openpgp-keys-miniupnp-20201006.ebuild | 23 +++++++++++++++++++
> > 3 files changed, 34 insertions(+)
> > create mode 100644 app-crypt/openpgp-keys-miniupnp/Manifest
> > create mode 100644 app-crypt/openpgp-keys-miniupnp/metadata.xml
> > create mode 100644 app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
> > diff --git a/app-crypt/openpgp-keys-miniupnp/Manifest b/app-crypt/openpgp-keys-miniupnp/Manifest
> > new file mode 100644
> > index 000000000000..c8f82da42fa6
> > --- /dev/null
> > +++ b/app-crypt/openpgp-keys-miniupnp/Manifest
> > @@ -0,0 +1,2 @@
> > +DIST A31ACAAF.asc 3139 BLAKE2B 4574c3f37965fafa4e2d703276a585d1f17b0da862042620681bac591062b3b70c52cbe5481da543d3c3193a640c06e9d86c3cef1568ae3a3f62901a6ad200ab SHA512 ecad52850fdcc7c21bab81917b3cea85c48b751534427d3db5750c43cbce73916ec4879e4f5535d4b87b7eca927ad249e384c5597702a0052afa89c23c5719b9
> > +DIST A5C0863C.asc 3098 BLAKE2B fdbc8629fd462b9cc72c568b0af5607951055abc03a1e344e4c1b411fb87bfa285c2e29d2781f9e9b02ec0bc63eacf55e5dc19198056a417ba3358dba445cc0c SHA512 adebff655374dbc8a045f9ab148f9fc343b043e80cb7e4e14c66aa56bfb2f0f5521e294c7600ca708893efc84679f788116d82ef5818370f1425f03dea0a77b9
> > diff --git a/app-crypt/openpgp-keys-miniupnp/metadata.xml b/app-crypt/openpgp-keys-miniupnp/metadata.xml
> > new file mode 100644
> > index 000000000000..5a5a3aaf4299
> > --- /dev/null
> > +++ b/app-crypt/openpgp-keys-miniupnp/metadata.xml
> > @@ -0,0 +1,9 @@
> > +<?xml version="1.0" encoding="UTF-8"?>
> > +<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
> > +<pkgmetadata>
> > + <maintainer type="person">
> > + <email>mgorny@gentoo.org</email>
> > + <name>Michał Górny</name>
> > + </maintainer>
> > + <stabilize-allarches/>
> > +</pkgmetadata>
> > diff --git a/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild b/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
> > new file mode 100644
> > index 000000000000..4b07eeca6024
> > --- /dev/null
> > +++ b/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
> > @@ -0,0 +1,23 @@
> > +# Copyright 1999-2020 Gentoo Authors
> > +# Distributed under the terms of the GNU General Public License v2
> > +
> > +EAPI=7
> > +
> > +DESCRIPTION="OpenPGP keys used to sign miniupnp* packages"
> > +HOMEPAGE="http://miniupnp.free.fr/files/"
> > +SRC_URI="
> > + http://miniupnp.free.fr/A31ACAAF.asc
> > + http://miniupnp.free.fr/A5C0863C.asc
> > +"
> > +
> > +LICENSE="public-domain"
> > +SLOT="0"
> > +KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv s390 sparc x86"
> > +
> > +S=${WORKDIR}
> > +
> > +src_install() {
> > + local files=( ${A} )
> > + insinto /usr/share/openpgp-keys
> > + newins - miniupnp.asc < <(cat "${files[@]/#/${DISTDIR}/}")
> > +}
> > --
> > 2.28.0
>
> This relies again on Manifest digests for the integrity of the key
> distfiles themselves. What do we gain by this indirection, as compared
> to validating the distfiles of the target package by their Manifest?
>
We gain the ability of verifying it *before* generating Manifest.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* [gentoo-dev] [PATCH 4/5] net-libs/miniupnpc: Use verify-sig.eclass
2020-10-06 9:58 [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Michał Górny
2020-10-06 9:58 ` [gentoo-dev] [PATCH 2/5] use.desc: Add verify-sig flag Michał Górny
2020-10-06 9:58 ` [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst Michał Górny
@ 2020-10-06 9:58 ` Michał Górny
2020-10-06 9:58 ` [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: " Michał Górny
` (3 subsequent siblings)
6 siblings, 0 replies; 23+ messages in thread
From: Michał Górny @ 2020-10-06 9:58 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
net-libs/miniupnpc/Manifest | 1 +
net-libs/miniupnpc/miniupnpc-2.1.20191224.ebuild | 11 ++++++++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net-libs/miniupnpc/Manifest b/net-libs/miniupnpc/Manifest
index 955881a8af5a..5341c95b6ff0 100644
--- a/net-libs/miniupnpc/Manifest
+++ b/net-libs/miniupnpc/Manifest
@@ -1 +1,2 @@
DIST miniupnpc-2.1.20191224.tar.gz 94740 BLAKE2B 85c0b3eb678685bc7192dbee9440ec5f5be80cbac4d6a4e0a6473662c66f05ef512322cd535a142ffe16d3099a86f78ea70645a7eb2979c373e7a486aeab0cd5 SHA512 d362f914ce9177c1bc46f1f3ae59069c61c0c9c1b6ea7e78003d6b46445d3550835ffc541c2649b5fbc997d035357b461148edb3648135f33d0ce98b54961917
+DIST miniupnpc-2.1.20191224.tar.gz.sig 543 BLAKE2B ddbde04faa7bce62fdbb5b555bda9dc9ff69f09cc97442049adc787a03ec91824f14cdddaef6e577cf8d08fa96202fc792333b8dab7e6e8c30847fa9302a35d0 SHA512 b8885d2002259c95ede7ab57aaf82db83c2bd7ace3d0986179efac4245ffd42161049e0167a9ac1ff18de6c8df4d39356f0fb6aa6dada7523a238b4db4838887
diff --git a/net-libs/miniupnpc/miniupnpc-2.1.20191224.ebuild b/net-libs/miniupnpc/miniupnpc-2.1.20191224.ebuild
index 7c74096859fc..25320f4f3dce 100644
--- a/net-libs/miniupnpc/miniupnpc-2.1.20191224.ebuild
+++ b/net-libs/miniupnpc/miniupnpc-2.1.20191224.ebuild
@@ -3,11 +3,12 @@
EAPI=7
-inherit toolchain-funcs
+inherit toolchain-funcs verify-sig
DESCRIPTION="UPnP client library and a simple UPnP client"
HOMEPAGE="http://miniupnp.free.fr/"
-SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz"
+SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz
+ verify-sig? ( http://miniupnp.free.fr/files/${P}.tar.gz.sig )"
LICENSE="BSD"
SLOT="0/17"
@@ -15,7 +16,11 @@ KEYWORDS="amd64 arm arm64 hppa ~mips ppc ppc64 s390 sparc x86"
IUSE="ipv6 kernel_linux static-libs"
RDEPEND=""
-DEPEND="kernel_linux? ( sys-apps/lsb-release sys-apps/which )"
+BDEPEND="
+ kernel_linux? ( sys-apps/lsb-release sys-apps/which )
+ verify-sig? ( app-crypt/openpgp-keys-miniupnp )"
+
+VERIFY_SIG_OPENPGP_KEY_PATH=/usr/share/openpgp-keys/miniupnp.asc
src_prepare() {
eapply_user
--
2.28.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: Use verify-sig.eclass
2020-10-06 9:58 [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Michał Górny
` (2 preceding siblings ...)
2020-10-06 9:58 ` [gentoo-dev] [PATCH 4/5] net-libs/miniupnpc: Use verify-sig.eclass Michał Górny
@ 2020-10-06 9:58 ` Michał Górny
2020-10-06 10:24 ` Alexey Sokolov
2020-10-06 11:17 ` [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Ulrich Mueller
` (2 subsequent siblings)
6 siblings, 1 reply; 23+ messages in thread
From: Michał Górny @ 2020-10-06 9:58 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
dev-python/miniupnpc/Manifest | 1 +
dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild | 11 +++++++----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/dev-python/miniupnpc/Manifest b/dev-python/miniupnpc/Manifest
index 955881a8af5a..5341c95b6ff0 100644
--- a/dev-python/miniupnpc/Manifest
+++ b/dev-python/miniupnpc/Manifest
@@ -1 +1,2 @@
DIST miniupnpc-2.1.20191224.tar.gz 94740 BLAKE2B 85c0b3eb678685bc7192dbee9440ec5f5be80cbac4d6a4e0a6473662c66f05ef512322cd535a142ffe16d3099a86f78ea70645a7eb2979c373e7a486aeab0cd5 SHA512 d362f914ce9177c1bc46f1f3ae59069c61c0c9c1b6ea7e78003d6b46445d3550835ffc541c2649b5fbc997d035357b461148edb3648135f33d0ce98b54961917
+DIST miniupnpc-2.1.20191224.tar.gz.sig 543 BLAKE2B ddbde04faa7bce62fdbb5b555bda9dc9ff69f09cc97442049adc787a03ec91824f14cdddaef6e577cf8d08fa96202fc792333b8dab7e6e8c30847fa9302a35d0 SHA512 b8885d2002259c95ede7ab57aaf82db83c2bd7ace3d0986179efac4245ffd42161049e0167a9ac1ff18de6c8df4d39356f0fb6aa6dada7523a238b4db4838887
diff --git a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
index 5e1d489b2e1e..e42aadd90e0d 100644
--- a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
+++ b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
@@ -5,11 +5,12 @@ EAPI=7
PYTHON_COMPAT=( python3_{6,7,8} pypy3 )
-inherit distutils-r1
+inherit distutils-r1 verify-sig
DESCRIPTION="Python bindings for UPnP client library"
HOMEPAGE="http://miniupnp.free.fr/"
-SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz"
+SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz
+ verify-sig? ( http://miniupnp.free.fr/files/${P}.tar.gz.sig )"
LICENSE="BSD"
SLOT="0"
@@ -17,8 +18,10 @@ KEYWORDS="amd64 ppc ppc64 x86"
IUSE=""
RDEPEND=">=net-libs/miniupnpc-${PV}:0="
-DEPEND="${RDEPEND}
- dev-python/setuptools[${PYTHON_USEDEP}]"
+DEPEND="${RDEPEND}"
+BDEPEND="verify-sig? ( app-crypt/openpgp-keys-miniupnp )"
+
+VERIFY_SIG_OPENPGP_KEY_PATH=/usr/share/openpgp-keys/miniupnp.asc
PATCHES=(
"${FILESDIR}"/miniupnpc-2.0.20171102-shared-lib.patch
--
2.28.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: Use verify-sig.eclass
2020-10-06 9:58 ` [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: " Michał Górny
@ 2020-10-06 10:24 ` Alexey Sokolov
2020-10-06 11:47 ` Michał Górny
0 siblings, 1 reply; 23+ messages in thread
From: Alexey Sokolov @ 2020-10-06 10:24 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
вт, 6 окт. 2020 г. в 10:59, Michał Górny <mgorny@gentoo.org>:
>
> Signed-off-by: Michał Górny <mgorny@gentoo.org>
> ---
> dev-python/miniupnpc/Manifest | 1 +
> dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild | 11 +++++++----
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/dev-python/miniupnpc/Manifest b/dev-python/miniupnpc/Manifest
> index 955881a8af5a..5341c95b6ff0 100644
> --- a/dev-python/miniupnpc/Manifest
> +++ b/dev-python/miniupnpc/Manifest
> @@ -1 +1,2 @@
> DIST miniupnpc-2.1.20191224.tar.gz 94740 BLAKE2B 85c0b3eb678685bc7192dbee9440ec5f5be80cbac4d6a4e0a6473662c66f05ef512322cd535a142ffe16d3099a86f78ea70645a7eb2979c373e7a486aeab0cd5 SHA512 d362f914ce9177c1bc46f1f3ae59069c61c0c9c1b6ea7e78003d6b46445d3550835ffc541c2649b5fbc997d035357b461148edb3648135f33d0ce98b54961917
> +DIST miniupnpc-2.1.20191224.tar.gz.sig 543 BLAKE2B ddbde04faa7bce62fdbb5b555bda9dc9ff69f09cc97442049adc787a03ec91824f14cdddaef6e577cf8d08fa96202fc792333b8dab7e6e8c30847fa9302a35d0 SHA512 b8885d2002259c95ede7ab57aaf82db83c2bd7ace3d0986179efac4245ffd42161049e0167a9ac1ff18de6c8df4d39356f0fb6aa6dada7523a238b4db4838887
> diff --git a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> index 5e1d489b2e1e..e42aadd90e0d 100644
> --- a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> +++ b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> @@ -5,11 +5,12 @@ EAPI=7
>
> PYTHON_COMPAT=( python3_{6,7,8} pypy3 )
>
> -inherit distutils-r1
> +inherit distutils-r1 verify-sig
>
> DESCRIPTION="Python bindings for UPnP client library"
> HOMEPAGE="http://miniupnp.free.fr/"
> -SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz"
> +SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz
> + verify-sig? ( http://miniupnp.free.fr/files/${P}.tar.gz.sig )"
>
> LICENSE="BSD"
> SLOT="0"
> @@ -17,8 +18,10 @@ KEYWORDS="amd64 ppc ppc64 x86"
> IUSE=""
>
> RDEPEND=">=net-libs/miniupnpc-${PV}:0="
> -DEPEND="${RDEPEND}
> - dev-python/setuptools[${PYTHON_USEDEP}]"
> +DEPEND="${RDEPEND}"
> +BDEPEND="verify-sig? ( app-crypt/openpgp-keys-miniupnp )"
> +
> +VERIFY_SIG_OPENPGP_KEY_PATH=/usr/share/openpgp-keys/miniupnp.asc
Shouldn't this be prefixed with ${BROOT}? (preferably, in the eclass)
>
> PATCHES=(
> "${FILESDIR}"/miniupnpc-2.0.20171102-shared-lib.patch
> --
> 2.28.0
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: Use verify-sig.eclass
2020-10-06 10:24 ` Alexey Sokolov
@ 2020-10-06 11:47 ` Michał Górny
0 siblings, 0 replies; 23+ messages in thread
From: Michał Górny @ 2020-10-06 11:47 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2563 bytes --]
On Tue, 2020-10-06 at 11:24 +0100, Alexey Sokolov wrote:
> вт, 6 окт. 2020 г. в 10:59, Michał Górny <mgorny@gentoo.org>:
> > Signed-off-by: Michał Górny <mgorny@gentoo.org>
> > ---
> > dev-python/miniupnpc/Manifest | 1 +
> > dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild | 11 +++++++----
> > 2 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/dev-python/miniupnpc/Manifest b/dev-python/miniupnpc/Manifest
> > index 955881a8af5a..5341c95b6ff0 100644
> > --- a/dev-python/miniupnpc/Manifest
> > +++ b/dev-python/miniupnpc/Manifest
> > @@ -1 +1,2 @@
> > DIST miniupnpc-2.1.20191224.tar.gz 94740 BLAKE2B 85c0b3eb678685bc7192dbee9440ec5f5be80cbac4d6a4e0a6473662c66f05ef512322cd535a142ffe16d3099a86f78ea70645a7eb2979c373e7a486aeab0cd5 SHA512 d362f914ce9177c1bc46f1f3ae59069c61c0c9c1b6ea7e78003d6b46445d3550835ffc541c2649b5fbc997d035357b461148edb3648135f33d0ce98b54961917
> > +DIST miniupnpc-2.1.20191224.tar.gz.sig 543 BLAKE2B ddbde04faa7bce62fdbb5b555bda9dc9ff69f09cc97442049adc787a03ec91824f14cdddaef6e577cf8d08fa96202fc792333b8dab7e6e8c30847fa9302a35d0 SHA512 b8885d2002259c95ede7ab57aaf82db83c2bd7ace3d0986179efac4245ffd42161049e0167a9ac1ff18de6c8df4d39356f0fb6aa6dada7523a238b4db4838887
> > diff --git a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> > index 5e1d489b2e1e..e42aadd90e0d 100644
> > --- a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> > +++ b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> > @@ -5,11 +5,12 @@ EAPI=7
> >
> > PYTHON_COMPAT=( python3_{6,7,8} pypy3 )
> >
> > -inherit distutils-r1
> > +inherit distutils-r1 verify-sig
> >
> > DESCRIPTION="Python bindings for UPnP client library"
> > HOMEPAGE="http://miniupnp.free.fr/"
> > -SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz"
> > +SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz
> > + verify-sig? ( http://miniupnp.free.fr/files/${P}.tar.gz.sig )"
> >
> > LICENSE="BSD"
> > SLOT="0"
> > @@ -17,8 +18,10 @@ KEYWORDS="amd64 ppc ppc64 x86"
> > IUSE=""
> >
> > RDEPEND=">=net-libs/miniupnpc-${PV}:0="
> > -DEPEND="${RDEPEND}
> > - dev-python/setuptools[${PYTHON_USEDEP}]"
> > +DEPEND="${RDEPEND}"
> > +BDEPEND="verify-sig? ( app-crypt/openpgp-keys-miniupnp )"
> > +
> > +VERIFY_SIG_OPENPGP_KEY_PATH=/usr/share/openpgp-keys/miniupnp.asc
>
> Shouldn't this be prefixed with ${BROOT}? (preferably, in the eclass)
>
You are correct indeed.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 9:58 [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Michał Górny
` (3 preceding siblings ...)
2020-10-06 9:58 ` [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: " Michał Górny
@ 2020-10-06 11:17 ` Ulrich Mueller
2020-10-06 11:49 ` Frédéric Pierret
2020-10-06 11:18 ` Ulrich Mueller
2020-10-10 20:10 ` Thomas Deutschmann
6 siblings, 1 reply; 23+ messages in thread
From: Ulrich Mueller @ 2020-10-06 11:17 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
>>>>> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 11:17 ` [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Ulrich Mueller
@ 2020-10-06 11:49 ` Frédéric Pierret
2020-10-06 11:59 ` Ulrich Mueller
0 siblings, 1 reply; 23+ messages in thread
From: Frédéric Pierret @ 2020-10-06 11:49 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1.1: Type: text/plain, Size: 995 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 11:49 ` Frédéric Pierret
@ 2020-10-06 11:59 ` Ulrich Mueller
0 siblings, 0 replies; 23+ messages in thread
From: Ulrich Mueller @ 2020-10-06 11:59 UTC (permalink / raw
To: Frédéric Pierret; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
>>>>> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 9:58 [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Michał Górny
` (4 preceding siblings ...)
2020-10-06 11:17 ` [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Ulrich Mueller
@ 2020-10-06 11:18 ` Ulrich Mueller
2020-10-06 11:25 ` Michał Górny
2020-10-10 20:10 ` Thomas Deutschmann
6 siblings, 1 reply; 23+ messages in thread
From: Ulrich Mueller @ 2020-10-06 11:18 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 195 bytes --]
>>>>> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 11:18 ` Ulrich Mueller
@ 2020-10-06 11:25 ` Michał Górny
2020-10-06 11:34 ` Ulrich Mueller
0 siblings, 1 reply; 23+ messages in thread
From: Michał Górny @ 2020-10-06 11:25 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 11:25 ` Michał Górny
@ 2020-10-06 11:34 ` Ulrich Mueller
2020-10-06 11:46 ` Michał Górny
0 siblings, 1 reply; 23+ messages in thread
From: Ulrich Mueller @ 2020-10-06 11:34 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
>>>>> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 11:34 ` Ulrich Mueller
@ 2020-10-06 11:46 ` Michał Górny
2020-10-06 12:06 ` Ulrich Mueller
0 siblings, 1 reply; 23+ messages in thread
From: Michał Górny @ 2020-10-06 11:46 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 11:46 ` Michał Górny
@ 2020-10-06 12:06 ` Ulrich Mueller
2020-10-06 12:12 ` Michał Górny
0 siblings, 1 reply; 23+ messages in thread
From: Ulrich Mueller @ 2020-10-06 12:06 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
>>>>> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 12:06 ` Ulrich Mueller
@ 2020-10-06 12:12 ` Michał Górny
0 siblings, 0 replies; 23+ messages in thread
From: Michał Górny @ 2020-10-06 12:12 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-06 9:58 [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Michał Górny
` (5 preceding siblings ...)
2020-10-06 11:18 ` Ulrich Mueller
@ 2020-10-10 20:10 ` Thomas Deutschmann
2020-10-10 20:36 ` Michał Górny
6 siblings, 1 reply; 23+ messages in thread
From: Thomas Deutschmann @ 2020-10-10 20:10 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1.1: Type: text/plain, Size: 6863 bytes --]
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 lowered security because more
people will now stop paying attention:
- Previous developers who carefully checked distfiles will stop
doing that.
- Nobody will question anything because there is a new passed
check.
In worst case scenario, we are now emerging a signed malicious package
we could be aware of if some human would have checked upstream and
noticed that release key was revoked. But this will not happen anymore
because we rely that once we have recorded a key in the metadata that
some system will tell us in case there is a problem. And what do you
expect what will happen when after the download something will tell us
“Oh, this file is not signed with currently known key”? Right, that
developer who we do not want to trust that he/she verified the distfile
will just add a reference to the new matching key which will silence any
warning.
No, sorry. Security required education. You need to understand where
security is depending on so that you know when you need to take action.
Every attempt to move this away from the user will actually add needless
complexity, allow for new attack vectors and will not improve security.
The purpose of this email is to get this addition removed ASAP.
PS: I assume that the "Arch Linux is using something similar" argument
will appear. I am not going to make an in depth statement about what
Arch Linux is doing here. But they have a total different security model
which you have to take into account. And please don't forget that we
already have that working Manifest mechanism which isn't promising
anything it cannot do.
--
Regards,
Thomas Deutschmann / Gentoo Security Team
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-10 20:10 ` Thomas Deutschmann
@ 2020-10-10 20:36 ` Michał Górny
2020-10-11 13:40 ` Thomas Deutschmann
0 siblings, 1 reply; 23+ messages in thread
From: Michał Górny @ 2020-10-10 20:36 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 8587 bytes --]
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 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.
> 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?
Yes, again, this is not perfect. It was never supposed to be. It's
better than what we had before (local solutions). Keeping the key
relatively correct via ebuild is easier than keeping it on multiple
machines used for development.
> 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 lowered security because more
> people will now stop paying attention:
>
> - Previous developers who carefully checked distfiles will stop
> doing that.
>
> - Nobody will question anything because there is a new passed
> check.
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.
> In worst case scenario, we are now emerging a signed malicious package
> we could be aware of if some human would have checked upstream and
> noticed that release key was revoked. But this will not happen anymore
> because we rely that once we have recorded a key in the metadata that
> some system will tell us in case there is a problem. And what do you
> expect what will happen when after the download something will tell us
> “Oh, this file is not signed with currently known key”? Right, that
> developer who we do not want to trust that he/she verified the distfile
> will just add a reference to the new matching key which will silence any
> warning.
>
> No, sorry. Security required education. You need to understand where
> security is depending on so that you know when you need to take action.
> Every attempt to move this away from the user will actually add needless
> complexity, allow for new attack vectors and will not improve security.
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?
> The purpose of this email is to get this addition removed ASAP.
Why do you claim to have the power to removed somebody's work just
because it doesn't fit your view of the world?
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-10 20:36 ` Michał Górny
@ 2020-10-11 13:40 ` Thomas Deutschmann
2020-10-11 14:35 ` Joonas Niilola
0 siblings, 1 reply; 23+ messages in thread
From: Thomas Deutschmann @ 2020-10-11 13:40 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1.1: Type: text/plain, Size: 7468 bytes --]
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 Gentoo's threat model. Once you
understand why we are using signatures you need to understand the
boundaries (limits) of signatures. The way how we are using signatures
is for example different because we are operating our own key
infrastructure and revocation process, we aren't affected by the
previous outlined issues.
>> The purpose of this email is to get this addition removed ASAP.
>
> Why do you claim to have the power to removed somebody's work just
> because it doesn't fit your view of the world?
I am gonna merge this with my answer to first paragraph.
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).
Of course I don't have any power to remove somebody's work (and I am
still wondering why you assume I have), but you obviously had the power
to just push your 'idea' which is still a draft to everyone and also
forces everyone to participate in your beta testing...
I hope to get a majority decision on that topic with the result to kill
it unless it will add any significant improvement we all want.
From my point of view the current implementation is only creating
security problems due to giving anyone a false sense of security and
ultimately resources are wasted by everyone because there is no benefit.
Sure, if I am the only having that opinion and most people see a value
in this and disagree with me...
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-11 13:40 ` Thomas Deutschmann
@ 2020-10-11 14:35 ` Joonas Niilola
2020-10-12 15:24 ` Alec Warner
0 siblings, 1 reply; 23+ messages in thread
From: Joonas Niilola @ 2020-10-11 14:35 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1.1: Type: text/plain, Size: 1257 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
2020-10-11 14:35 ` Joonas Niilola
@ 2020-10-12 15:24 ` Alec Warner
0 siblings, 0 replies; 23+ messages in thread
From: Alec Warner @ 2020-10-12 15:24 UTC (permalink / raw
To: Gentoo Dev
[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]
On Sun, Oct 11, 2020 at 7:35 AM Joonas Niilola <juippis@gentoo.org> 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
>
>
[-- Attachment #2: Type: text/html, Size: 3965 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread