I don't have problem with MUST, but probably SHOULD would be more appropriate.

That "MUST" was there already in David Woodhouse's proposal in 2016. I can change it if the FPC wants. What do others think?

I agree, MUST is a bit strong here.
Especially since it would render all existing .specs for packages with verifiable upstream sources non-conformant.

Why not use plain gpg2 as suggested in https://pagure.io/packaging-committee/issue/610#comment-535966 ? It'll work across EPEL and Fedora the same way.

Why not use plain gpg2 as suggested in https://pagure.io/packaging-committee/issue/610#comment-535966 ?

Because that's much harder to do right for packagers who aren't GnuPG experts:

1. GnuPG doesn't accept armored keyrings, so a separate dearmoring step may or may not be necessary. This requires packagers to understand what ASCII-armor is, and makes for complex instructions in the guidelines, which are already uncomfortably long. Using my script, packagers don't need to even know that there is a difference between armored and unarmored keyrings.

2. GnuPG requires specific unintuitive parameters, or else it may use the wrong keyring. This again makes the instructions complex. People tend to ignore instructions when they don't understand why the instructions are necessary. Some will undoubtedly try to simplify the command by omitting "--homedir" and "./", and thereby introduce security bugs. My script doesn't allow itself to be used wrong.

It'll work across EPEL and Fedora the same way.

So will my script. I have tested it in CentOS 6 and 7. We can add the script and macro to a suitable EPEL package and have them work the same way across EPEL and Fedora. Would epel-rpm-macros be a good choice?

I have updated the proposed text to show that spec files must require GnuPG, matching this pull request:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/54

I have also weakened the policy to "SHOULD" as requested.

double quotes are not needed here.

use

`+%gpgverify+`

please

Once redhat-rpm-config is merged, I'll merge this as well. Sorry for such long delay.

Well, I disagree about the grammar. The percent sign isn't part of the macro name, it's syntax for expanding a macro. But I won't let an important security policy be held up by a squabble about grammar.

I made the two requested grammar changes, and suddenly this pull request shows as a gigantic patch with 48 changed files. According to Git the added section "Source File Verification" is the only difference. I guess Pagure must be confused somehow.

Yeah, I think you'd need to do rebase on top of master.

Sigh. OK, I reapplied all the commits. Now the commit history is linear and simple, and Pagure seems able to understand it.

Commit 957404ef fixes this pull-request