About the verify-sig and verify-provenance

[papu]

hi,

I decided to activate USE=" verify-sig" in my make.conf.
Now, verify-provenance (which seems to be only for Python packages what is it for? why is it only for Python ? Should I put it in make.conf too?

[logrusx]

I don't know why one would enable something they don't know what it actually is.

According to the description of the use flag: verifies that the artifact comes from upstream source repository

But portage already performs checksum verification of all distfiles it downloads so it does not make sense to me. It looks redundant.

You can find more information in the man page of pypi.eclass (app-doc/eclass-manpages) or maybe even read the eclass itself.

Best Regards,
Georgi

[papu]

I don't know why one would enable something they don't know what it actually is.

According to the description of the use flag: verifies that the artifact comes from upstream source repository

But portage already performs checksum verification of all distfiles it downloads so it does not make sense to me. It looks redundant.

You can find more information in the man page of pypi.eclass (app-doc/eclass-manpages) or maybe even read the eclass itself.

Best Regards,
Georgi

Sorry, My previous post was wrong I would mean I am already using USE="verify-sig" in my make.conf , but don't know about verify-provenance

thanks!

[Zucca]

I don't know why one would enable something they don't know what it actually is.

No need to be so negative about it.
Many users here are experimenting and/or learning. Despite OP was asking the effects of the USE flag (to which you did answer to).

[Hu]

Code: Select all

# 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 sec-keys/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.
#
# If you need to use signify, you may want to copy distfiles into WORKDIR to
# work around "Too many levels of symbolic links" error.
#
# A more complete guide can be found at:
# https://mgorny.pl/articles/verify-sig-by-example.html

Thus, while most users will not need it, it is helpful to users because it makes it easier for developers to do the right thing when bumping. Users can validate a download by relying on the checksums in the manifests, but the checksums are set by the developers when updating the ebuild, and only confirm that the user downloaded the file that the developer meant for you to download. If the developer added a checksum without verifying that the input file is a legitimate release, then the checksum validation would accept a potentially inappropriate file. USE=verify-sig aids developers by making signature verification an integral part of the workflow, so that a developer cannot accidentally add an inappropriate checksum.

[papu]

The question was more to ask specifically about verify-provenance, since I already have verify-sig enabled for a few days. Will it gradually be applied to more packages like happened with verify-sig? That is, for now it only affects Python packages

thanks!

[sam_]

verify-provenance is separate from verify-sig because we believe it is of "different" value to verify-sig.

See the gentoo-dev mailing list thread from its introduction, but in short, it's only in Gentoo because for some upstreams, it is the only verification method they provide, so we may as well use it. Sadly, pypi dropped PGP signatures because they were "underused" but instead of working on the UX around that, they dropped it entirely.

verify-sig is not reserved solely for PGP (we use it for minisig etc too) but we believe that the type of verification offered by "trusted publishers" is different enough to warrant marking it separately.