I'm not entirely sure this is a particularly good idea. There are so many instances where you have a package with one file that comes from somewhere else.

In what circumstances do you see this being useful?

To me the use case is quite obvious.
A packager wants to make sure that only approved (signed) sources are used to build the package,
in this case, he has the option to force all sources to be verified with -a ll.

If there is the odd file from somewhere else, there are essentially two options:

A) it is irrelevant if this file contains anything dubious, then don't use the -a ll option and mix
signed and unsigned sources.

B) it matters that the packager can guarantee that the odd file is kosher, then he can sign it
with a key he controls (or creates) and all sources can be verified.

It strikes me as strange that the secure version should not be useful. Do we value security too little?

• Who is "we"?
• Why the hyperbole?
• Why would you think that me asking a simple question implies anything about how much "we" value security?

Of course it's useful in some limited circumstance, but Source: lines specify far more than just things which came from upstream, and I am not sure how many packages would actually benefit from this. Need to add an appdata file? You can't even prep your spec without messing with %gpg_verify.

And, yes, every piece of code has a cost and these costs must be balanced against other things. I don't think it should be such a big deal to ask you if you've looked at the packages we have and see where this could actually be used. I know it wouldn't be useful for exim, for example.

Why would you think that me asking a simple question implies anything about how much "we" value security?

Sorry Jason, it wasn't my intention to hyperbole. My focus was simply on security, and if there is no way to make sure all sources must be verified the only thing we have is a mixture of verified and not verified sources, in which case it is questionable why we (=%gpg_verify) verify at all.

Writing secure code means to make sure (or even likely) that bad things don't happen. Not being
able to force a verification on all sources seems, in this regard, undesirable. I only want to make
%gpg_verify better.

I can imagine that from a user's (or packager's) point of view it's best to have everything done for you in the background without any substantial involvement, but based on my experience, security won't be the result of this approach.

Need to add an appdata file? You can't even prep your spec without messing with %gpg_verify.

That's not what I proposed. Without the -a option unsigned sources, even all unsigned sources will be accepted, if that's what you want, just skip the -a option.

And, yes, every piece of code has a cost and these costs must be balanced against other things. I don't think it should be such a big deal to ask you if you've looked at the packages we have and see where this could actually be used. I know it wouldn't be useful for exim, for example.

It should be for openssl and similar packages, and for the cryptobone it is already useful.