Damien Goutte-Gattat via Gnupg-users writes: > On Sat, Dec 14, 2019 at 08:05:04PM -0500, Dave via Gnupg-users > wrote: >> I can’t recall encountering any similar complaints about >> OpenSSL. I find this somewhat curious, and am wondering if >> there are OpenSSL detractors out there that I simply haven’t >> come across > > OpenSSL definitely has its detractors. They were for example > very vocal back in 2014 in the aftermath of the Heartbleed > bug.
I cannot speak for anyone else but from my experience the GnuPG community ecosystem's way of dealing with issues is way more conflict prone than how OpenSSL handles this. One side of that conflict is how GnuPG treats the command line "API". While my written OpenSSL instructions, automation scripts around key generation, signing, de/encryption required (minor) modification due to OpenSSL software changes in the last years, GnuPG updates from Debian quite often require quite intruding changes to written manual instructions or automated scripts. To nail it down, here is the list of changes as an example and the time to fix (estimate from memory): OpenSSL: * Generate dh-params during deployment and always use them on connection (15 minutes) * Force SSL to drop older TLS versions on internal connections (5 minutes) GnuPG: * Initrd restructuring due to gnupg-agent use (4h) * Secure forced termination of gnupg-agent for single-use private key decryption (4h) * Update, testing of numerous procedures after introduction of "pin-entry-mode" (4h) * Decoding of PGP private key format using RFC to resurrect old private keys after suddenly not being useable any more after a minor update (1 day) * Workaround for secure GnuPG passphrase handling after gnupg started silently ignoring the command line parameters to have a stronger passphrase bruteforce security by integrating GnuPG with argon2. (4h) As I have the feeling I use OpenSSL and GnuPG in a similar number of procedures, the much huger amount of time required to keep GnuPG operational and secure does not make me cheerful about command line/operating system API stability. As mentioned above, this is only one side of that conflict. The other one is, that when such problems occur, which cannot be avoided even with best software, then documentation or online resources are usually not very helpful. Thus the community contact is sought, but to my opinion replies are often not acknowledging the problem (not accepting that someone might have used GnuPG for such procedures before the change and requires to find a working solution to keep production running), empathic (a reply like: "sorry, we understand this is annoying for you, but this change was technically required ...), not increasing community knowlege to build a better GnuPG community (the change was needed for use-case [reference], thus requirements [reference] contratict your use case. See [doc-url] for considerations, workarounds ..."). So for example following following sequence or events represents quite well the usual experience I perceive dealing with GnuPG software issues: * Discovering accidentially that GnuPG private key passphrase bruteforce somehow was reduced to 1/100 strength with new keys. * Searching the documentation, internet, not finding anything of relevance to this issue. * Asking the GnuPG security contact finding out a) the parameter for better bruteforce protection is silently ignored in GnuPG2 passphrase symmetric key generation b) there is no problem GnuPG downgrading security on its own without any warning by ignoring the parameter, c) the documention is outdated/ambiguous and does not mention the change, c) why do you want to have a strong bruteforce protection, the reduced value is way better for good user experience with gnupg-agent? and d) gnupg-agent will manage (calibrate) that parameter for optimized user experience automatically to 1/100, no need to mingle with that. * Me not being happy to reduce bruteforce protection to something used 10 years ago, thus integrating GnuPG with argon2 to have appropriate protection again. Having such experiences more than once reduced trust and sympathy for GnuPG, thus also willingness to contribute to testing or development. But maybe just my expectations of GnuPG as open source software are wrong and my limited communication skills do not allow me to sort it out in a more positive manner. hd _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
