[gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Michał Górny]

Hi,

Here's a patchset that introduces provenance verification (i.e.
verify-sig equivalent) for pypi.eclass.  It also cleans up eclassdoc
a bit.

The technical details are provided on the individual patches.

-- 
Best regards,
Michał Górny


Michał Górny (4):
  pypi.eclass: Fix eclassdoc typo; <package> → <project>
  pypi.eclass: Update the @DESCRIPTION
  pypi.eclass: Introduce provenance verification API
  dev-python/pypi-attestations: Enable provenance verification

 dev-python/pypi-attestations/Manifest         |   1 +
 .../pypi-attestations-0.0.27.ebuild           |   1 +
 eclass/pypi.eclass                            | 133 ++++++++++++++++--
 3 files changed, 124 insertions(+), 11 deletions(-)

[gentoo-dev] [PATCH 1/4] pypi.eclass: Fix eclassdoc typo; <package> → <project>

[Michał Górny]

Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 eclass/pypi.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/pypi.eclass b/eclass/pypi.eclass
index 47d40449d13a..7c1d79cbbc0c 100644
--- a/eclass/pypi.eclass
+++ b/eclass/pypi.eclass
@@ -161,7 +161,7 @@ _pypi_sdist_url() {
 # generated using build systems that did not follow PEP 625
 # (i.e. the sdist name contains uppercase letters, hyphens or dots).
 #
-# If <package> is unspecified, it defaults to ${PYPI_PN}.  The package
+# If <project> is unspecified, it defaults to ${PYPI_PN}.  The package
 # name is normalized according to the specification unless
 # `--no-normalize` is passed.
 #
@@ -183,7 +183,7 @@ pypi_sdist_url() {
 # @DESCRIPTION:
 # Output the wheel filename for the specified project/version tuple.
 #
-# If <package> is unspecified, it defaults to ${PYPI_PN}.  The package
+# If <project> is unspecified, it defaults to ${PYPI_PN}.  The package
 # name is normalized according to the wheel specification.
 #
 # If <version> is unspecified, it defaults to ${PV} translated
@@ -221,7 +221,7 @@ pypi_wheel_name() {
 # the wheel contents will be unpacked straight into ${WORKDIR}.
 # You need to add a BDEPEND on app-arch/unzip.
 #
-# If <package> is unspecified, it defaults to ${PYPI_PN}.
+# If <project> is unspecified, it defaults to ${PYPI_PN}.
 #
 # If <version> is unspecified, it defaults to ${PV} translated
 # via pypi_translate_version.  If it is specified, then it is used

[gentoo-dev] [PATCH 2/4] pypi.eclass: Update the @DESCRIPTION

[Michał Górny]

Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 eclass/pypi.eclass | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/eclass/pypi.eclass b/eclass/pypi.eclass
index 7c1d79cbbc0c..04a2bbd0380c 100644
--- a/eclass/pypi.eclass
+++ b/eclass/pypi.eclass
@@ -11,16 +11,18 @@
 # @DESCRIPTION:
 # The pypi.eclass can be used to easily obtain URLs for artifacts
 # uploaded to PyPI.org.  When inherited, the eclass defaults SRC_URI
-# and S to fetch .tar.gz sdist.  The project filename is normalized
-# by default (unless PYPI_NO_NORMALIZE is set prior to inheriting
-# the eclass), and the version is translated using
+# and S to fetch .tar.gz sdist.  The eclass defaults to using ${PN}
+# as PyPI project name; PYPI_PN can be set prior to inheriting it
+# to override that.  The source distribution filename is assumed
+# to be normalized by default; PYPI_NO_NORMALIZE can be set prior
+# to inherit to override that.  The version is translated using
 # pypi_translate_version.
 #
 # If necessary, SRC_URI and S can be overridden by the ebuild.  Two
 # helper functions, pypi_sdist_url and pypi_wheel_url are provided
 # to generate URLs to artifacts of specified type, with customizable
 # URL components.  Additionally, pypi_wheel_name can be used to generate
-# wheel filename.
+# the wheel filename.
 #
 # pypi_normalize_name can be used to normalize an arbitrary project name
 # according to sdist/wheel normalization rules.  pypi_translate_version

[gentoo-dev] [PATCH 3/4] pypi.eclass: Introduce provenance verification API

[Michał Górny]

Introduce a new API to verify provenance of PyPI artifacts.  To enable
it, set PYPI_VERIFY_REPO to the upstream repository URL.  The eclass
will automatically add a verify-sig flag along with dependencies,
fetch the provenance file from PyPI and export src_unpack() to verify
it.

Support for provenance verification can be checked on PyPI's project
page.  If it is supported, the project metadata (i.e. "Project links")
is found in "Verified details", whereas otherwise only "Maintainers"
are in that section.  It can also be seen under "view details" for
individual artifacts.

The eclass also provides the low-level functions to account for special
needs: pypi_provenance_url and pypi_verify_provenance.

The bits are implemented directly in pypi.eclass rather than
verify-sig.eclass since they are pretty tightly bound to PyPI
infrastructure, with nontrivial URLs and a dedicated provenance file
format.

Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 eclass/pypi.eclass | 119 +++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 114 insertions(+), 5 deletions(-)

diff --git a/eclass/pypi.eclass b/eclass/pypi.eclass
index 04a2bbd0380c..cefe8031a671 100644
--- a/eclass/pypi.eclass
+++ b/eclass/pypi.eclass
@@ -18,17 +18,24 @@
 # to inherit to override that.  The version is translated using
 # pypi_translate_version.
 #
-# If necessary, SRC_URI and S can be overridden by the ebuild.  Two
-# helper functions, pypi_sdist_url and pypi_wheel_url are provided
-# to generate URLs to artifacts of specified type, with customizable
-# URL components.  Additionally, pypi_wheel_name can be used to generate
-# the wheel filename.
+# If PYPI_VERIFY_REPO is set to a non-empty value, verify-sig flag
+# is added along with necessary BDEPEND.  The provenance file
+# for the default source distribution is added to SRC_URI, and a default
+# src_unpack() is exported to verify its provenance.
+#
+# If necessary, SRC_URI and S can be overridden by the ebuild.  Three
+# helper functions, pypi_sdist_url, pypi_wheel_url and pypi_provenance_url
+# are provided to generate URLs to artifacts of specified type, with
+# customizable URL components.  Additionally, pypi_wheel_name can be
+# used to generate the wheel filename.
 #
 # pypi_normalize_name can be used to normalize an arbitrary project name
 # according to sdist/wheel normalization rules.  pypi_translate_version
 # can be used to translate a Gentoo version string into its PEP 440
 # equivalent.
 #
+# pypi_verify_provenance can be used to verify the provenance directly.
+#
 # @EXAMPLE:
 # @CODE
 # inherit pypi
@@ -65,6 +72,15 @@ _PYPI_ECLASS=1
 # @CODE
 : "${PYPI_PN:=${PN}}"
 
+# @ECLASS_VARIABLE: PYPI_VERIFY_REPO
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# The repository to verify provenance against.  If set to a non-empty
+# value, the eclass will add a "verify-sig" flag that can be used
+# to download the provenance for the distribution, and verify it
+# against the provenance and the specified repository.
+
 # @FUNCTION: _pypi_normalize_name
 # @INTERNAL
 # @USAGE: <name>
@@ -259,6 +275,76 @@ pypi_wheel_url() {
 	fi
 }
 
+# @FUNCTION: _pypi_provenance_url
+# @INTERNAL
+# @USAGE: <dist> [<project> [<version>]]
+# @DESCRIPTION:
+# Internal function to generate provenance URL for <dist>, using
+# specified <project> and <version>.  Returns the result
+# via _PYPI_ATTESTATION_URL.
+_pypi_provenance_url() {
+	if [[ ${#} -lt 1 || ${#} -gt 3 ]]; then
+		die "Usage: ${FUNCNAME} <dist> [<project> [<version>]]"
+	fi
+
+	local dist=${1}
+	local project=${2-"${PYPI_PN}"}
+	local version=${3-"$(pypi_translate_version "${PV}")"}
+	_PYPI_ATTESTATION_URL="https://pypi.org/integrity/${project}/v${version}/${dist}/provenance"
+}
+
+# @FUNCTION: pypi_provenance_url
+# @USAGE: <dist> [<project> [<version>]]
+# @DESCRIPTION:
+# Output the URL to PyPI provenance for the specified artifact.
+pypi_provenance_url() {
+	local _PYPI_PROVENANCE_URL
+	_pypi_provenance_url "${@}"
+	echo "${_PYPI_PROVENANCE_URL}"
+}
+
+# @FUNCTION: pypi_verify_provenance
+# @USAGE: <dist> <provenance> [<repo>]
+# @DESCRIPTION:
+# Verify the specified artifact's provenance.  <dist> is the path
+# to the artifact to verify, while <provenance> is the provenance file.
+#
+# The function defaults to using PYPI_VERIFY_REPO as the expected
+# repository URL.  This can be overridden by specfying <repo>.
+#
+# The function dies on verification failure.
+pypi_verify_provenance() {
+	if [[ ${#} -lt 2 || ${#} -gt 3 ]]; then
+		die "Usage: ${FUNCNAME} <dist> <provenance> [<repo>]"
+	fi
+
+	local dist=${1}
+	local provenance=${2}
+	local repo=${3-"${PYPI_VERIFY_REPO}"}
+
+	einfo "Verifying ${dist##*/} ..."
+	pypi-attestations verify pypi --offline \
+		--repository "${repo}" \
+		--provenance-file "${provenance}" \
+		"${dist}" ||
+		die "Provenance verification failed for ${dist##*/}"
+}
+
+# @FUNCTION: pypi_src_unpack
+# @DESCRIPTION:
+# A src_unpack implementation that verifies provenances.  Exported only
+# with PYPI_VERIFY_REPO.
+pypi_src_unpack() {
+	if use verify-sig; then
+		local sdist_url=$(pypi_sdist_url)
+		local filename=${sdist_url##*/}
+
+		pypi_verify_provenance "${DISTDIR}/${filename}"{,.provenance}
+	fi
+
+	default
+}
+
 # @FUNCTION: _pypi_set_globals
 # @INTERNAL
 # @DESCRIPTION:
@@ -278,8 +364,31 @@ _pypi_set_globals() {
 	fi
 
 	SRC_URI=${_PYPI_SDIST_URL}
+
+	if [[ -n ${PYPI_VERIFY_REPO} ]]; then
+		local dist=${_PYPI_SDIST_URL##*/}
+		local _PYPI_ATTESTATION_URL
+		_pypi_provenance_url "${dist}" "${PYPI_PN}" \
+			"${_PYPI_TRANSLATED_VERSION}"
+
+		IUSE="verify-sig"
+		SRC_URI+="
+			verify-sig? (
+				${_PYPI_ATTESTATION_URL} -> ${dist}.provenance
+			)
+		"
+		BDEPEND="
+			verify-sig? (
+				dev-python/pypi-attestations
+			)
+		"
+	fi
 }
 
 _pypi_set_globals
 
+if [[ -n ${PYPI_VERIFY_REPO} ]]; then
+	EXPORT_FUNCTIONS src_unpack
+fi
+
 fi

[gentoo-dev] [PATCH 4/4] dev-python/pypi-attestations: Enable provenance verification

[Michał Górny]

Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 dev-python/pypi-attestations/Manifest                        | 1 +
 dev-python/pypi-attestations/pypi-attestations-0.0.27.ebuild | 1 +
 2 files changed, 2 insertions(+)

diff --git a/dev-python/pypi-attestations/Manifest b/dev-python/pypi-attestations/Manifest
index 1396b9a869b9..2d475693a137 100644
--- a/dev-python/pypi-attestations/Manifest
+++ b/dev-python/pypi-attestations/Manifest
@@ -1 +1,2 @@
 DIST pypi_attestations-0.0.27.tar.gz 123543 BLAKE2B 11e6dabcb58c5201af4df0392784c5cda02eabfde4d6d2cd39464d3bf89fa7a54495c435e86e5b7031ed7d9a85230ec273279d2f8ab86ba5e1dec2eb431829e4 SHA512 206c6aaf523a0143defe2ef35ee886d8d5d3cc7d3010a5f1ef6d5e9f0af3dac56b2a3b3af87256b50bf475d88ff397ea35f7512aac540a2918e8a52c91ac6e03
+DIST pypi_attestations-0.0.27.tar.gz.provenance 9602 BLAKE2B 70ace0f798e6bdeb1be3af64c78ba3d774a2944239776728c70c8d06f91c7a6fef1f929ca63ed52ffd83e4d623b1dfe457a670ab5c9e72908b59d93d1b54a3c5 SHA512 9cd9bed860bedd479800c52637e24a9fcbe9f03a8ea8c25a5c4029e4f8c61743843dbb583afd7958c6fa8418ef734f08d4a55a7c4222956fe1f934004c14cdf6
diff --git a/dev-python/pypi-attestations/pypi-attestations-0.0.27.ebuild b/dev-python/pypi-attestations/pypi-attestations-0.0.27.ebuild
index c19a7c9fe83a..bd6e00af8a18 100644
--- a/dev-python/pypi-attestations/pypi-attestations-0.0.27.ebuild
+++ b/dev-python/pypi-attestations/pypi-attestations-0.0.27.ebuild
@@ -4,6 +4,7 @@
 EAPI=8
 
 DISTUTILS_USE_PEP517=setuptools
+PYPI_VERIFY_REPO=https://github.com/trailofbits/pypi-attestations
 PYTHON_COMPAT=( python3_{11..13} )
 
 inherit distutils-r1 pypi

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 876 bytes --]

On 8/24/25 3:12 PM, Michał Górny wrote:
> Hi,
> 
> Here's a patchset that introduces provenance verification (i.e.
> verify-sig equivalent) for pypi.eclass.  


I strongly believe this should *not* be merged.

There are a couple reasons why I don't think this is beneficial and
would strongly push back against implementing it in any package I
maintain (even if the relevant files are uploaded to PyPI). But the main
issue is the one you said already in IRC:

"yes, it worked. yes, it's all theater"

I am opposed to implementing anything which even the author thinks is
useless.

I am opposed to implementing anything which constitutes "security
theater as a matter of policy". Security theater is a *net negative*. It
makes people think that security guarantees exist which don't in fact
exist, and they let down their guard.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

On Sun, 2025-08-24 at 15:32 -0400, Eli Schwartz wrote:
> On 8/24/25 3:12 PM, Michał Górny wrote:
> > Hi,
> > 
> > Here's a patchset that introduces provenance verification (i.e.
> > verify-sig equivalent) for pypi.eclass.  
> 
> 
> I strongly believe this should *not* be merged.
> 
> There are a couple reasons why I don't think this is beneficial and
> would strongly push back against implementing it in any package I
> maintain (even if the relevant files are uploaded to PyPI). But the main
> issue is the one you said already in IRC:
> 
> "yes, it worked. yes, it's all theater"
> 
> I am opposed to implementing anything which even the author thinks is
> useless.

My personal opinion about this or about using GitHub doesn't change
the fact that it's the official upstream recommendation.  The flags
aren't intended to be used by users, users have Manifests.  They are
helpful for developers to double-check that the artifacts aren't
compromised (or more likely, that "something went wrong").

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Sam James]

Eli Schwartz <eschwartz@gentoo.org> writes:

> On 8/24/25 3:12 PM, Michał Górny wrote:
>> Hi,
>> 
>> Here's a patchset that introduces provenance verification (i.e.
>> verify-sig equivalent) for pypi.eclass.  
>
>
> I strongly believe this should *not* be merged.
>
> There are a couple reasons why I don't think this is beneficial and
> would strongly push back against implementing it in any package I
> maintain (even if the relevant files are uploaded to PyPI). But the main
> issue is the one you said already in IRC:
>
> "yes, it worked. yes, it's all theater"
>
> I am opposed to implementing anything which even the author thinks is
> useless.
>
> I am opposed to implementing anything which constitutes "security
> theater as a matter of policy". Security theater is a *net negative*. It
> makes people think that security guarantees exist which don't in fact
> exist, and they let down their guard.

I have to admit I'm sceptical sa
well. https://blog.trailofbits.com/2024/11/14/attestations-a-new-generation-of-signatures-on-pypi/
is some useful background.

On the one hand, I feel like using something that PyPI makes available
has some weight by itself, even if we don't approve of it.

On the other hand, the gain (at least for us, given we do source builds)
feels dubious. If I understand the mechanism correctly, it has a lot of
magic based on the GH repo and allows "automated releases" to be signed,
whereas a lot of the benefit of PGP verification is that the workflow
really steers you towards doing it manually at some point in the
process.

Maybe more importantly: supposing verification fails for a release, I am
not sure I yet fully understand how that can happen or what it implies,
or what reasons upstream could give me that are bogus (i.e. I don't know
if having it as USE=verify-sig would achieve anything). I understand the
failure modes and weak points of PGP, I don't understand the failure
modes and weak points of this scheme yet.

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Sam James]

Sam James <sam@gentoo.org> writes:

> Eli Schwartz <eschwartz@gentoo.org> writes:
>
>> On 8/24/25 3:12 PM, Michał Górny wrote:
>>> Hi,
>>> 
>>> Here's a patchset that introduces provenance verification (i.e.
>>> verify-sig equivalent) for pypi.eclass.  
>>
>>
>> I strongly believe this should *not* be merged.
>>
>> There are a couple reasons why I don't think this is beneficial and
>> would strongly push back against implementing it in any package I
>> maintain (even if the relevant files are uploaded to PyPI). But the main
>> issue is the one you said already in IRC:
>>
>> "yes, it worked. yes, it's all theater"
>>
>> I am opposed to implementing anything which even the author thinks is
>> useless.
>>
>> I am opposed to implementing anything which constitutes "security
>> theater as a matter of policy". Security theater is a *net negative*. It
>> makes people think that security guarantees exist which don't in fact
>> exist, and they let down their guard.
>
> I have to admit I'm sceptical sa
> well. https://blog.trailofbits.com/2024/11/14/attestations-a-new-generation-of-signatures-on-pypi/
> is some useful background.
>
> On the one hand, I feel like using something that PyPI makes available
> has some weight by itself, even if we don't approve of it.
>
> On the other hand, the gain (at least for us, given we do source builds)
> feels dubious. If I understand the mechanism correctly, it has a lot of
> magic based on the GH repo and allows "automated releases" to be signed,
> whereas a lot of the benefit of PGP verification is that the workflow
> really steers you towards doing it manually at some point in the
> process.
>
> Maybe more importantly: supposing verification fails for a release, I am
> not sure I yet fully understand how that can happen or what it implies,
> or what reasons upstream could give me that are bogus (i.e. I don't know
> if having it as USE=verify-sig would achieve anything). I understand the
> failure modes and weak points of PGP, I don't understand the failure
> modes and weak points of this scheme yet.

From the post I linked:

> Longer term, we can do even better: doing “one off” verifications
> means that the client has no recollection of which identities should
> be trusted for which distributions. To address this, installation
> tools need a notion of “trust on first use” for signing identities,
> meaning that subsequent installations can be halted and inspected by a
> user if the attesting identity changes (or the package becomes
> unattested etween versions).

Once this is implemented upstream (it sounds like it isn't a thing yet),
combined with the fact it's the upstream recommendation (even if I don't
love the scheme), I could accept it.

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Jay Faulkner]

On 8/24/25 10:35 PM, Sam James wrote:
> I feel like using something that PyPI makes available has some weight by itself, even if we don't approve of it.

This is 100% where I land on this, unequivocally. We may not agree with 
the philosophy taken by the upstream (trusting Microsoft with the 
"keys", effectively), but from my perspective, our ideal is to implement 
what upstream does -- adding additional verification if we think it's 
necessary.

I don't have a specific case where this is possible (and I think it'd be 
a bit brave to suggest it's impossible), but imagine what happens if 
something is caught by pypi attestation but not Gentoo python project 
because we didn't implement it? The downside is *huge* of not 
implementing it and it being the wrong decision. The downside is much, 
much smaller if we make the change and, as posited here by many, it's 
not actually improving the security profile for Gentoo.


-JayF

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1125 bytes --]

On 8/25/25 1:33 AM, Michał Górny wrote:
> My personal opinion about this or about using GitHub doesn't change
> the fact that it's the official upstream recommendation.


I don't see why upstream distfile services recommending a thing has to
do with this topic.

But I'm willing to be persuaded -- as soon as we also switch to their
recommendation that each and every python program in Gentoo is installed
in a virtualenv.

Also I did not say anything about "github", so I don't know where your
criticism comes from? Am I supposed to, I don't know, have a vendetta
against github copilot to the point where I don't trust github actions
to do CI? Seems farfetched to me.


> The flags
> aren't intended to be used by users, users have Manifests.  They are
> helpful for developers to double-check that the artifacts aren't
> compromised (or more likely, that "something went wrong").

It is *precisely* developers who, per my belief, should strictly refrain
from this eclass addition and refuse to believe that it makes any
statement about whether artifacts are compromised.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 3194 bytes --]

On 8/25/25 1:35 AM, Sam James wrote:

> I have to admit I'm sceptical sa
> well. https://blog.trailofbits.com/2024/11/14/attestations-a-new-generation-of-signatures-on-pypi/
> is some useful background.
> 
> On the one hand, I feel like using something that PyPI makes available
> has some weight by itself, even if we don't approve of it.
> 
> On the other hand, the gain (at least for us, given we do source builds)
> feels dubious. If I understand the mechanism correctly, it has a lot of
> magic based on the GH repo and allows "automated releases" to be signed,
> whereas a lot of the benefit of PGP verification is that the workflow
> really steers you towards doing it manually at some point in the
> process.


I feel like you're entirely missing my concern. I didn't say the gain is
dubious. I said it is actively harmful.

It verifies nothing (0% usefulness, already fully covered by blake2
checksums in Manifest) while *looking* like it does something else.
Again, "security theater" is inherently damaging and detrimental to
users' and developers' understanding of threat models.


> Maybe more importantly: supposing verification fails for a release, I am
> not sure I yet fully understand how that can happen or what it implies,
> or what reasons upstream could give me that are bogus (i.e. I don't know
> if having it as USE=verify-sig would achieve anything). I understand the
> failure modes and weak points of PGP, I don't understand the failure
> modes and weak points of this scheme yet.


The failure mode of this scheme is that anyone who can upload a
malicious release to PyPI can also upload a malicious provenance file
that passes validation.

***NOT*** "what if they can also".

The ability to upload a malicious release ***also grants as a side
effect*** the ability to upload a provenance file with green checkmarks.

It's the same access bit.

The whole point of "provenance files" is that you can only create them
via github actions or gitlab CI, and those are also (supposed to be) the
only thing with access permissions to publish to PyPI.

- nobody has publish tokens for PyPI, other than the forge-based CI/CD

- the ability to push commits or tags to github/gitlab by hacking
  developers (ssh keys but also Personal Access Tokens) automatically
  grants the ability to run CI/CD on push, because that is precisely how
  the legitimate developers publish

- this whole model assumes "the cloud" is harder to hack than developer
  laptops, which -- given "reusable workflows" can be and have been
  hacked in the past -- is humorously the opposite to reality

- creating a release via forge-based CI/CD automatically creates a valid
  "green checkmark" provenance file


In exchange for these non-promises ("participation trophy" / automatic
free green checkmarks), we get something that has to be individually
p.use.masked on a per package basis because sigstore only works on
amd64, and whose mere presence in emerge -pv output causes the
maintainer of the ebuild to believe that it's "so verified already that
it surely isn't worth diffing the release distfiles".


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[gentoo-dev] Re: [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Duncan]

Eli Schwartz posted on Sun, 24 Aug 2025 15:32:07 -0400 as excerpted:

> I am opposed to implementing anything which constitutes "security
> theater as a matter of policy". Security theater is a *net negative*. It
> makes people think that security guarantees exist which don't in fact
> exist, and they let down their guard.

So yeah, it's theater, and I agree, certainly net-negative (and FWIW I'd 
have worded it as flat dangerous, at least as-is!) in general, in part 
because it seems to prove something it doesn't.

Jayf does have a point, however.  Theater tho it may be, what happens if 
some how, some way, that theater catches something upstream and gentoo 
doesn't because it didn't implement it?

So I asked myself if there was a way to counteract that negative/dangerous 
bit while still doing the hoop-jump theater to counteract jayf's what-if 
as well?

I can't seem to grep it any longer, but some years ago I recall coming 
across a USE flag for some package: gaping-security-hole (or some such, 
that's from memory).  Naturally on seeing that flag I had to equery uses 
the package to see just what sort of description that USE flag had, and it 
was pretty much what the name suggested, but (reading a bit more into 
things than was actually explicit) apparently a presumably large site 
installation had some sort of local use-case where the security concerns 
didn't apply, so given that it had an upstream-available config option, 
the Gentoo maintainer had obliged them with a USE flag but labeled it 
exactly what he considered it to be in the process.

That was a memorable USE flag!

Borrowing that blatant call-out idea, what if we called it 
PYPI_VERIFICATION_THEATER or PYPI_HOOP_JUMPING_THEATER instead of 
PYPI_VERIFY_REPO, with accordingly matched low-level function names?  Or 
even PYPI_FAKE_VERIFICATION or PYPI_VERIFICATION_FAKEOUT and etc, to more 
directly call it what it is...

From here that looks to get the message across both for Gentoo devs and 
upstream/downstream if anyone cares to look, while never-the-less going 
through the motions upstream's proposing in case jayf somehow some way 
looks prescient in a couple years.  (No offense intended jayf, tho surely 
you'd rather you didn't, too! =:^)

Of course if upstream ever does the second step and gets the halt-on-
change sam's quote pointed to working we'd arguably want to tone down our 
names a bit, but at least we'd have worked out any bugs in our initial 
implementation during the theater (aka dry-run test) period, and that bit 
should continue to work once there's at least /some/ value to it.

Not that I'll be broken-hearted if that proposal isn't implemented, but 
the option is there...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Mon, 2025-08-25 at 18:03 -0400, Eli Schwartz wrote:
> It verifies nothing (0% usefulness, already fully covered by blake2
> checksums in Manifest) while *looking* like it does something else.
> Again, "security theater" is inherently damaging and detrimental to
> users' and developers' understanding of threat models.

Manifests only cover what the developer has fetched.  If you believe
that developers actively verify the source distributions they've
downloaded, think again.  In fact, verify-sig was added precisely
because we wanted at least some minimal verification in place.

Please correct me if I'm wrong.  Without the change, the attack vectors
include all attacks against the upstream repository + attacks against
the PyPI infrastructure and CDN.  With the change, we're protecting
against the attacks on the latter, so even if you believe they to be
unlikely, it's still a reduction of the attack surface.  Isn't that
a net gain?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Sam James]

Michał Górny <mgorny@gentoo.org> writes:

> On Mon, 2025-08-25 at 18:03 -0400, Eli Schwartz wrote:
>> It verifies nothing (0% usefulness, already fully covered by blake2
>> checksums in Manifest) while *looking* like it does something else.
>> Again, "security theater" is inherently damaging and detrimental to
>> users' and developers' understanding of threat models.
>
> Manifests only cover what the developer has fetched.  If you believe
> that developers actively verify the source distributions they've
> downloaded, think again.  In fact, verify-sig was added precisely
> because we wanted at least some minimal verification in place.
>
> Please correct me if I'm wrong.  Without the change, the attack vectors
> include all attacks against the upstream repository + attacks against
> the PyPI infrastructure and CDN.  With the change, we're protecting
> against the attacks on the latter, so even if you believe they to be
> unlikely, it's still a reduction of the attack surface.  Isn't that
> a net gain?

Right, this is the point Jay is making as well.

My issue was/is that given it seems quite weak (the lack of TOFU right
now), it might even persuade someone that something is fine when it
isn't if it passes, given it provides extremely little ("Oh, at least
the provenance is fine"). On the other hand, I can't see a case where we
*know* something is off but the provenance is fine and we therefore
dismiss it, because of this same reason (the very weak verification).

I still don't get what attack in its current form it is actually
supposed to prevent.

But I am sympathetic to the argument that it is the upstream approved way of
doing things, and that *if* it somehow caught something which we miss
because we're not using it, it would be pretty devastating.

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

On Wed, 2025-08-27 at 14:52 +0100, Sam James wrote:
> Michał Górny <mgorny@gentoo.org> writes:
> 
> > On Mon, 2025-08-25 at 18:03 -0400, Eli Schwartz wrote:
> > > It verifies nothing (0% usefulness, already fully covered by blake2
> > > checksums in Manifest) while *looking* like it does something else.
> > > Again, "security theater" is inherently damaging and detrimental to
> > > users' and developers' understanding of threat models.
> > 
> > Manifests only cover what the developer has fetched.  If you believe
> > that developers actively verify the source distributions they've
> > downloaded, think again.  In fact, verify-sig was added precisely
> > because we wanted at least some minimal verification in place.
> > 
> > Please correct me if I'm wrong.  Without the change, the attack vectors
> > include all attacks against the upstream repository + attacks against
> > the PyPI infrastructure and CDN.  With the change, we're protecting
> > against the attacks on the latter, so even if you believe they to be
> > unlikely, it's still a reduction of the attack surface.  Isn't that
> > a net gain?
> 
> Right, this is the point Jay is making as well.
> 
> My issue was/is that given it seems quite weak (the lack of TOFU right
> now), it might even persuade someone that something is fine when it
> isn't if it passes, given it provides extremely little ("Oh, at least
> the provenance is fine"). On the other hand, I can't see a case where we
> *know* something is off but the provenance is fine and we therefore
> dismiss it, because of this same reason (the very weak verification).

I don't understand how TOFU is related to this.  The way I understand
it, it's hierarchical model.  The repo hosting key is verified
by the central key, and that key is used to verify artifacts.  Plus,
the repository URL is verified against the signature, so we effectively
verify that the artifact is associated with upstream repository.

> 
> I still don't get what attack in its current form it is actually
> supposed to prevent.

My understand would be PyPI itself or CDN being compromised -- i.e.
a third party adding/replacing a sdist (in our case) that did not
originate from upstream repository.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2718 bytes --]

On 8/27/25 11:08 AM, Michał Górny wrote:

> I don't understand how TOFU is related to this.  The way I understand
> it, it's hierarchical model.  The repo hosting key is verified
> by the central key, and that key is used to verify artifacts.  Plus,
> the repository URL is verified against the signature, so we effectively
> verify that the artifact is associated with upstream repository.




>> I still don't get what attack in its current form it is actually
>> supposed to prevent.
> 
> My understand would be PyPI itself or CDN being compromised -- i.e.
> a third party adding/replacing a sdist (in our case) that did not
> originate from upstream repository.


CDN compromise is protected by a) TLS, b) geographically global
verification of Manifest. So is PyPI compromise after the fact. PyPI
compromise of any sort will be all kinds of headline news, and will
affect far more packages not covered by this snake oil at all, even for
updating ebuilds. So we are left with "someone hacks pypi's underlying
server, affecting only packages released after that date".

The fact remains that for packages which enable github actions based
automation of release (mandatory prerequisite for "provenance"), no
non-github publishing tokens traditionally exist, and it is
astronomically more likely -- in fact, very likely, actually -- that
compromised packages will be compromised via a hacked password or a
leaked github token, or via supply chain security attacks. In all
plausible cases, the malicious artifact has originated from the upstream
repository and the provenance check passes.

I already pointed all this out. This sort of thing *already* happens
practically on the regular.

As you already pointed out, it is security theater. Therefore I don't
see why we should take any risk at all in the possibility of the people
who already replied to this thread saying they'd impute meaning to this
flag, actually doing so.

Meanwhile, the fact that provenance exists at all has measurably
decreased the security of software I care about, since provenance was
used as an excuse to disable the ability of members of the PGP community
to upload code-signing attestations, and consequently, authors of
software I package and use have said "it's not worth fighting PyPI, no I
won't upload to github releases, blame PyPI. I'll just only continue
signing my non-PyPI software projects".

I think it sends an extremely bad message to approve and condone
something that will always pass provenance checks **even if it is
malicious**, and frankly I'm not sure why despite *you* saying it's
security theater, you're determined to add it anyway.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-dev] [PATCH 0/4] pypi.eclass: Provenance verification (and minor fixes)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On Sun, 2025-09-07 at 04:25 -0400, Eli Schwartz wrote:
> Meanwhile, the fact that provenance exists at all has measurably
> decreased the security of software I care about, since provenance was
> used as an excuse to disable the ability of members of the PGP community
> to upload code-signing attestations, and consequently, authors of
> software I package and use have said "it's not worth fighting PyPI, no I
> won't upload to github releases, blame PyPI. I'll just only continue
> signing my non-PyPI software projects".
> 
> I think it sends an extremely bad message to approve and condone
> something that will always pass provenance checks **even if it is
> malicious**, and frankly I'm not sure why despite *you* saying it's
> security theater, you're determined to add it anyway.

I'm not really happy about the push against OpenPGP either, but I don't
see how sulking over this and pretending attestations don't exist is
going to help us.  What I really prefer to do is make the best of this,
and use it as an argument to have test files in source distributions, so
we wouldn't have to rely on autogenerated GitHub archives.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]