From my practical expexperience, @ebo's suggestion will work best for me. The other thing I have seen is to not use -signed but to append the initials of the signers.

I know Microsoft is probably not the best example, but copying an already copied file with the Windows Explorer you get "Copy of Copy of Copy of originalname.txt". Moreover, I think foo_signed_signed_signed.pdf makes it pretty clear that this is a PDF that has been signed multiple times. I would leave it as-is. People who don't like the name can easily change it.

How about adding "-2" to a document where before _signed already was in the name, i.e. foo_signed.pdf -> foo_signed-2.pdf and so on: foo_signed-3.pdf, ...

Just for reference:
Make it signature pretty: https://dev.gnupg.org/T6732
Default path: https://dev.gnupg.org/T6731
signed_signed: https://dev.gnupg.org/T6730

Unfortunately, "make it not ugly" is a bit hard to work with. I'm open for ideas.

I'm going to assign this to @aheinecke - but @ebo might also have opinion on how it would be nice.

As this issue was originally just about the "versioned file" and where to place _signed, I think we should keep this closed. Will create new issues based on the notes here.

I'm told that this is also what acrobat does, which is one of the reasons for the current approach.

well yes, it ends now in "_signiert.pdf" with German language settings and "_signed.pdf" in English.

Tested with current version. Works.

This should be in the newest for testing.

Here is an example from my QES cert:

That does not mean that this is a good idea. And well, I heard that Poppler does not have a stable API.

The poppler api exposes it. Has done it since more or less the incarnation of pdf signing in poppler I think.

Don't do that. The key usage extensions rarely useful. This is the usual X.509 DbC (design by commitee) mess. See for example https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt . Let's not try to follow this path.

The poppler API exposes key usage extensions, and I'm trying to reconstruct them from the canX flags, which of course is highly inaccurate.

Technically, the canX are already checking a flag internally because _gpgme_key stores the can_X values as single bits. There are still 17 unused bits in _gpgme_key, i.e. there's plenty of space for more flags like can_haz_cheezeburger.

OK, still the whole usage stuff screams for a flag style api IMO. With all the canX then reduced to checking for the according flags internally.
@werner I am assigning this to you for triage. Basically set it to wontfix or whishlist if you think it would be worthwhile or not for future canHazCheezeburger things

Use the is_qualified flag to figure out QES certificates. This is more than just a capability flag.

NonRepudiation is not a well defined term. It is used by X.509 but often used similar to a digital signature. Thus this does not make sense. The is_qualified flag is what we need for QeS and it seems we already got this in gpgme.

gpgme puts digitalSignature and norRepudiation into canSign. We need them separated at the sources (maybe exposing keyUsage directly in gpgme. That would also make the code in poppler better and more accurate. I'm trying to reconstruct the keyUsages from the canSign&friends functions.

signing works, too

Ready for testing. I could view a signed PDF and verify the signature with the gpg backend, but other things may not work because of missing dependencies.