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

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

[Michał Górny]

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

diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
new file mode 100644
index 000000000000..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 <mgorny@gentoo.org>
+# @SUPPORTED_EAPIS: 7
+# @AUTHOR:
+# Michał Górny <mgorny@gentoo.org>
+# @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: <file> <sig-file> [<key-file>]
+# @DESCRIPTION:
+# Read the detached signature from <sig-file> and verify <file> against
+# it.  <key-file> 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
+			found=
+			for suffix in .sig; do
+				if [[ ${f} == *${suffix} ]]; then
+					signatures+=( "${f}" )
+					found=sig
+					break
+				else
+					if has "${f}${suffix}" ${A}; then
+						distfiles+=( "${f}" )
+						found=dist+sig
+						break
+					fi
+				fi
+			done
+			if [[ ! ${found} ]]; then
+				nosigfound+=( "${f}" )
+			fi
+		done
+
+		# check if all distfiles are signed
+		if [[ ${#nosigfound[@]} -gt 0 ]]; then
+			eerror "The following distfiles lack detached signatures:"
+			for f in "${nosigfound[@]}"; do
+				eerror "  ${f}"
+			done
+			die "Unsigned distfiles found"
+		fi
+
+		# check if there are no stray signatures
+		for f in "${signatures[@]}"; do
+			if ! has "${f%.*}" "${distfiles[@]}"; then
+				straysigs+=( "${f}" )
+			fi
+		done
+		if [[ ${#straysigs[@]} -gt 0 ]]; then
+			eerror "The following signatures do not match any distfiles:"
+			for f in "${straysigs[@]}"; do
+				eerror "  ${f}"
+			done
+			die "Unused signatures found"
+		fi
+
+		# now perform the verification
+		for f in "${signatures[@]}"; do
+			verify-sig_verify_detached \
+				"${DISTDIR}/${f%.*}" "${DISTDIR}/${f}"
+		done
+	fi
+
+	# finally, unpack the distfiles
+	default_src_unpack
+}
+
+_VERIFY_SIG_ECLASS=1
+fi
-- 
2.28.0

[gentoo-dev] [PATCH 2/5] use.desc: Add verify-sig flag

[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

[gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst

[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

[gentoo-dev] [PATCH 4/5] net-libs/miniupnpc: Use verify-sig.eclass

[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

[gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: Use verify-sig.eclass

[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

Re: [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: Use verify-sig.eclass

[Alexey Sokolov]

вт, 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
>
>

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

[Ulrich Mueller]

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

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

[Ulrich Mueller]

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

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

[Michał Górny]

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

Re: [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst

[Ulrich Mueller]

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

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

[Ulrich Mueller]

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

Re: [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst

[Michał Górny]

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

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

[Michał Górny]

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

Re: [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: Use verify-sig.eclass

[Michał Górny]

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

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

[Frédéric Pierret]

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

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

[Ulrich Mueller]

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

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

[Ulrich Mueller]

>>>>> On Tue, 06 Oct 2020, Michał Górny wrote:

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

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

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

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

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

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

Ulrich

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

[Michał Górny]

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

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

[Thomas Deutschmann]

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

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

[Michał Górny]

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

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

[Thomas Deutschmann]

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

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

[Joonas Niilola]

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

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

[Alec Warner]

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