Usability of OpenSSL vs GNUPG

[halfdog]

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