Currently, when encrypting with GPGME, you either hide all key IDs or none of them. This is a problem for MUAs that are trying to safely Bcc people.
fab8b1a166ff indicates at least one possible path forward.
Another path would be a new _encrypt() variant that takes a list of hidden recipients in addition to its list of non-hidden recipients.
This latter approach seems simplest to me, as a MUA developer, and i would be happy to use it.
| rM GPGME | |||
| rM969700bc56ce doc: Suggest the use of strconcat for recipient strings. | |||
| rM4bba3b8e2c35 core: Allow for --hidden keyword in OpenPGP recpstrings. | |||
I don't think that -R is a good way to implement BCC - it would be better to encrypt it separately. But people may have different ideas on this.
1.11 features a set of extended encryption functions which may optionally take a string as key specifications. In contrast to the array of key objects this string is a linefeed delimited list of key specifications which are passed verbatim to gpg. For OpenPGP a keyword feature is supported. For example the string
"wk@gnupg.org \n --hidden \n hoover@fbi.gov \n 0x1234567812345678"
creates this gpg invocation (only relevant options):
gpg -e -r wk@gnupg.org -R hoover@fbi.gov -R 0x1234567812345678
To suppress these keywords the common "--" can be used:
"--\n wk@gnupg.org \n --hidden \n hoover@fbi.gov \n 0x1234567812345678"
which yields
gpg -e -r wk@gnupg.org -r '--hidden' -r hoover@fbi.gov -r 0x1234567812345678
I think i can understand why this decision was made, but i'm not convinced it's a great solution. In particular, string-based arguments for C libraries are asking for trouble, and compound string arguments of the type described above are even more risky.
The C API has no way of exposing what features of the string-parser are supported, and if there is a failure in a given string, it's not clear how the library user is supposed to identify the failure, let alone how to fix it.
If future versions of gpgme extend the syntax further, or expose this particular feature outside of OpenPGP, then implementers who want to rely on the new features will have a very hard time writing code that behaves reasonably when compiled or linked against different versions of gpgme :/
I know that GPGME (and libgcrypt itself) both already make use of string-based arguments, so this is not adding a new problem to the interface of these libraries. But it is further entrenching an existing problem, which makes it harder to imagine a cleaner API in some future version, unfortunately.
My experience is that using a string is much easier and less error prone that to build up and allocate an error obj objects. A string leads to less code and bugs are easier to detect. There are enough patter on to handle strings in a safe way and key specs are in most cases already available in string form (e.g. hex fingerprints), be it from a mail interface, as a result of a database query or from the command line.
The keywords are of course a hack but I think they are easy to understand and they avoid complicated interfaces to further attribute key specifications. Pointing out which key is the the reason for a failure is already a problem and it does not really matter whether this is an array or a string. The plan is to add an extended error interface to gpgme to store detailed error information in the context and allow to query that.
I added two examples to the manual on how to create a string in a safe way.