Support for gpgsm

[tdussa]

I would like to be able to interface to gpgsm in addition to gpg because I'd like to be able to create S/MIME as well as GPG signatures. I believe this should be fairly easily doable; however, setting gpgbinary to gpgsm in the gnupg.GPG init call results in an error message:

ValueError: Error invoking gpg: 2: [GNUPG:] FAILURE option-parser 50331649
gpgsm: invalid option "--fixed-list-mode"

Describe the solution you'd like
Be able to initialize gnupg.GPG with gpgsm as the backend binary to be used.

Describe alternatives you've considered
There seem to be python-gnupg forks(?) that allow for exactly this, for example https://github.com/isislovecruft/python-gnupg; however, those forks are not packaged by, say, Debian or Arch.

Additional context
None.

[vsajip]

For gpgsm to be easily usable via gpgbinary, it needs to be completely command-line compatible with gpg.

You may be able to subclass gnupg.GPG to get the behaviour you want with gpgsm - you could override GPG._handle_io or GPG._open_subprocess and modify the args to suit gpgsm before passing to the base method.

The other fork you mention hasn't seen activity for many years; I would guess it's abandonware (though I may be wrong on that).

[tdussa]

I totally understand that it is not sufficient to set gpgbinary=gpgsm at the moment because gpgsm unfortunately is not command-line compatible. However, I would really love it if python-gnupg would implement gpgsm support. I am aware that this is potentially a substantial effort. I am also aware that the fork is not actively maintained. However, I wanted to point to it because it at least claims to support gpgsm, so it is possible that approaches how to handle the situation might be found there. I am somewhat cautiously optimistic that the required changes to gnupg.GPG might be limited. I'll have a look into what is necessary to be changed.

THX for your help!

[vsajip]

because it at least claims to support gpgsm

Sure, but it's years out of date now, as far as I know, so I'm not sure any claims it makes are still valid. I don't see that any approaches of value are to be found there (you'll see dozens of open issues and unaddressed PRs there).

From what I can see, it's just a case of using the appropriate command line parameters for the appropriate tool. This is the first time anyone has asked for S/MIME / gpgsm support since I released this library, so I'm not sure how much the support burden might be for what might be a niche use case (in terms of number of users wanting it).

I would suggest taking the subclass-and-override approach I suggested earlier, and if that works well, we can look and see if it's feasible to fold that in.