This is still an issue. Since the double click opens a registry entry the working directory of Okular is Windows. Since it is the working directory of the explorer so that is unusable, but it should still be able to somehow take the location from the actually opened file and use that for a save file suggestion.

This works for me

should this go into the upcomming VSD release?

Existing file. I downloaded a pdf into the local Download folder of my Windows-VM and worked with that.

Is the document loaded from an existing file on disk or directly as a url from a remote server? http(s) or windows share ?

On VS-Desktop-3.1.90.287-Beta I get a suggestion of c:\Windows for saving the signed document, not the users directory any more.
So its gotten worse instead of better...

I want to have this for the next release since I want to use that mechanism for the promised "Tender version of Kleopatra". This will mean that we replace the "VERSION" file with a QSettings ini file where we can easily add more meta information as we like.

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.