We won't fix that for 2.2.

Interesting. i'm also not sure this is a good feature. I also still don't think the gpgv man page explains this clearly, but if you don't want to clarify it, i won't bother re-opening this issue.

All given data files are concatenated; not sure whether this is a good feature but iirc pgp 2 did it the same way.

Thanks for this prompt fix! but they're still not aligned. with this fix, the Synopsis is:

So after taking this down to where it was only patching status.h and mainproc.c to add a write_status_output() I realized the whole issue is down to status-codes.h not being updated automatically if you apply a patch to status.h in a released version.

Having looked at the build log again after applying the patch, I see the first test failing is

So I cherry-picked this onto 2.4.4 and I ended up with a failing build due to failed tests (it built fine without the patch)

We check the actual used signature and the corresponding (sub)key. Whether you trust this key is a different thing and we are not able to check that. Note that the same subkey may be used with different primary keys. The whole point of gpgv is to that you pass a list of trusted keys - actually this makes this new option superfluous but in gpg it makes sense. It was easy to add it to gpgv, though.

Do note there could be subkeys as well.

In T6946#181608, @werner wrote:

The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.

A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.

I noticed the Debian bug and was about to answer but a feature request is also a good thing.

For what it's worth when I filed the Debian bug I mistakenly believed min-rsa-key-length in gpg would do that but it only applies to de-vs compliance profile and is *silently* ignored otherwise.

Bug is in 2.2, too.

Fixed in rG591a53d716aa: gpg: Don't call keybox_compress when KEYDB_RESOURCE_FLAG_READONLY..

I found that the warning is emitted when it tries to call keybox_compress.
It should not be called when it's READONLY (which gpgv specifies).

Problem seems to be that there is no ~/trustedkeys.gpg file and that the fallback to the kbx file does not anymore work. I can replicate that with 2.40 and 2.4.4-beta.

Because we use dot-locking in GnuPG and copy-update-write for keyrings. Granted: For gpgv this is not required but the code is identical to the gpg code and adding new code does not make much sense. After all gpgv is a stripped down version of gpg I once wrote for Debian. I see your use case but tehre are other ways to do this and thus anthing here has low priority.

out of curiosity, why does gpgv need the name of the file?

In that case, you can treat this ticket as a bug in the documentation, which still needs to be resolved.

We need random access and the name of the file. Thus a file descriptor is not sufficient.

Applied to 2.2 and master. Thanks.

Editor fault. The browser's editor is not like Emacs and here o my laptop the backspace key does not work as intended. I guess I was about to write ".. a back signature's usage flag".

what does "back signature's usage tool" mean? can we make an addition to the test suite that ensures that bad signatures will be rejected?

The fix was not fully correct because it considered a back signature's usage tool.

Fix will also go into 2.2.9

The new unified compliance checker was not initialized. Fixed in the 2.2 branch.

As part of switching debsig-verify from using --list-packets to gpg with --list-keys --with-colons and gpgv, it would be helpful to eventually be able to get the fingerprint instead of the keyid. This is needed because debsig-verify uses the keyid to select which one of its policy files it has to load, to apply for the subsequent actual verification of the .deb package.

Fixed in 6e23416fe61d4130918f2d1bf6e1f98d102c4610.

I understand, So this is another special case like the one when a keyring has
permissions which don't allow it to be read.

the reason "no public key" is confusing is because gpgv already knows that there
can be no public key. So the message that the naive user needs to see in this
case is "no keyring available".

If there is at least one keyring available, then saying something like "no
public key found in keyrings X and Y and Z" is reasonable. but if there are no
keyrings at all, the message should just be something like "no keyring found to
validate signature against".

I agree on the first part. This needs to be fixed.

I do not understand wht you think "no public key" is the wrong message. We have
always used this message if the public key is not available for verification.
Do you think the text should be changed to "public key not found" ? That would
be a simple change in libgpg-error.

Libgpg-error has a GPG_ERR_MISSING_KEY but that code indicates wrong usage of
functions or bad data structures.