The guidelines are clear that %gpgverify is mandatory. However, that doesn't mean that there aren't other methods that could be written into the guidelines.

What are the advantages of minisign over the existing %gpgverify and /usr/lib/rpm/redhat/gpgverify usage?
What would verification with minisign look like? Can it be built into the existing gpgverify script?

In short, I'm sure that people would at least be willing to consider accepting changes to permit minisign usage, but the details are important and it's better if someone who fully understands the issues can at least propose the needed changes.

Hi @tibbs , thanks for reply.

The guidelines are clear that %gpgverify is mandatory. However, that doesn't mean that there aren't other methods that could be written into the guidelines.

It's not very clear to me because the whole section is prefaced with Where the upstream project publishes OpenPGP signatures of their releases, Fedora packages SHOULD verify that signature as part of the RPM build process.

What are the advantages of minisign over the existing %gpgverify and /usr/lib/rpm/redhat/gpgverify usage?
What would verification with minisign look like? Can it be built into the existing gpgverify script?

In short, I'm sure that people would at least be willing to consider accepting changes to permit minisign usage, but the details are important and it's better if someone who fully understands the issues can at least propose the needed changes.

I'm not trying to advocate for minisign usage because that could be a holy war that I'm not interested in fighting. There are lots of articles on the internet though. It starts with this OpenBSD signify article, then The PGP Problem criticizing the PGP usage. At least for me as upstream the advantage of minisign signatures is that it's public key is short enough to be embedded in README or spec files.

The verification looks like (SOURCE0 is the tarball, SOURCE1 is the signature)

/usr/bin/minisign -V -m %{SOURCE0} -x %{SOURCE1} -p %{SOURCE2}

or

/usr/bin/minisign -V -m %{SOURCE0} -x %{SOURCE1} -p %{public_key}

There's clearly value in verifying source files. The question is when upstream only publishes minisign signatures are Fedora packagers allowed to use that for verification?

@fkooman you packaged minisign, do you want to chime in or send a PR to update the guideline?

I can also try to submit a PR because that seems to be a preferred way to propose changes.

OK, just ignore me; I didn't realize that minisign was an entirely separate thing. I thought it was just an alternate method of verifying PGP signatures.

Really the guidelines don't say anything at all about verifying non-GPG signatures, besides expressing a general preference for signature verification in general. If minisign is really its own thing then I guess I don't understand how anyone could get the impression that the guidelines would somehow ban anyone from verifying minisign signatures. Is there anything there that suggests that useful signatures should be ignored because they aren't PGP ones?

But yes, it would be good for someone who is very familiar with this stuff to send a PR. It doesn't seem like minisign is complicated, but maybe there are pitfalls which are beyond my limited understanding. GPG is certainly complicated enough that it requires a separate script just to do the verification.

Is there anything there that suggests that useful signatures should be ignored because they aren't PGP ones?

Maybe they had also thought minisign was an alternative method of verifying PGP signatures. I can certainly clarify that with them.

The Verifying Signatures section when read alone also says one MUST use %{gpgverify} so that might also be interpreted as only PGP signatures are allowed.

While it is technically true that the guidelines only talk about OpenPGP, in reality many parts are equally applicable to any other signing method. At least the general SHOULD about verifying signatures if they are provided, parts about how to import the public key to dist-git, the rule about verifying before doing anything else. Probably the current situation came to be because when the section was written, OpenPGP was the only relevant signing method.

It would make sense to adjust the section so that generic rules are written in generic terms, and more specific rules about OpenPGP (such as the %{gpgverify} macro) are covered in their own section.

It turns out there is an old, ignored pull request that fixes this already:
https://pagure.io/packaging-committee/pull-request/917

Well, if someone wants to rework that PR (it isn't mergeable as is) and someone who knows can verify it for correctness, then we can move forward.

Note for future self: fedora-review contains a generic check that mentions gpgverify, that should also be updated.