Usability of OpenSSL vs GNUPG
me at halfdog.net
Wed Dec 18 13:12:15 CET 2019
Robert J. Hansen writes:
> > 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.
> One of my repeated complaints about GnuPG is that nobody can agree on
> what it is. Is it a toolkit for building bespoke cryptographic
> solutions? Is it an RFC4880 implementation meant for end-users? Is it
> an RFC4880 implementation meant for MUAs? Is it...
Yes, I fell this is exactly the cause. But what adds to that
frustration is, that e.g. offering to participate in defining
use cases, requirements, scope of various components seemed not
the way the project would like to go forward, maybe as this would
surface the conflicts in a short run (while avoiding them in
> A lot of the things you're (rightly, I think) criticizing are the result
> of this clouded vision of what GnuPG is meant to do. In the course of
> trying to be all things to all people it's occasionally being very
> You're using it as a toolkit for bespoke solutions. You want your tools
> to work consistently across versions.
> Other people are using it as an end-user tool. They want the end-user
> experience to be continuously refined.
> This leads to things like gpg-agent ignoring s2k iteration counts in
> order to give a positive end-user experience, at the risk of frustrating
> people who are wondering why their bespoke solutions with custom s2k
> iteration counts no longer work.
I can second nearly everything you wrote, but here I have a different
Changing the value might be good for gnupg as end-user tool and
therefore I completely understand, that a change in the default
is positive to most users and hence the project itself. It also
increases the security of the average user I guess, as most likely
they did not configure stronger KDF settings on their own.
I also understand, that such changes being fruitful for many
users (the main use cases) might require others with different
usecases to adopt to the new standard.
What I do not get is, why such design changes are applied in
a non-defensive manner, thus making the end users search for
the changes instead of clearly defining the new API, e.g. by
failing with exit(1). I would hope for that to be a standard
in security-aware software instead silently ignoring a parameter
that once before contributed major boost in protection.
By saying that, I hope I could make clear, that I am not against
having an agile approach to moving open source software forward,
when it is also causing some breakage sometimes. At least gnupg
should not be come the new MS with eternal backward compatibility
in some domains :-)
What I would wish for (and would offer to participate in creating
it) is some formalized, written down quality optimizing procedures
to drive development with such a life-cycle-model in mind for
API, features and deprecation. Maybe some of these already exists,
otherwise it might make sense to define it?
* Write down current usecases, requirements we are aiming to
fulfill at the moment. This makes it more transparent what
gnupg is at the moment and was it wants to be in the future.
By formalizing this process, different opinions are easier
to integreate at design phase thus avoiding troubles after
implementtion. I believe this could also reduce frustration
for gnupg-devs as changes are less disputed (usually only
those opposing are the ones being loud, thus reducing the
feel-good-factor of their great work).
* Rules for deprecation of features settings some rules for
backward compatibility but also removal of features. One thing
I could envision is something like a "--quality" mode switch
with GnuPG. Using this, the software will hard-fail if any
function marked for deprecation (--s2k-count, weak ciphers,
storage formats, ...) is used. While this would still allow
great flexibility for the average user (not depending on
special API or cryptographic properties) while the others
may also run with "--quality" in their continuous integration
environment, thus catching update frictions before those reach
* Define a user feedback process to get a better insight and
real numbers on their usecases (could be as something like
having a lime survey open plus a defined feature request/
positive criticism process) to have real numbers, hard evidence
where end users are moving to. This can then be combined
with the strategy, where we want to move them to, e.g. to
get mail-encryption more common.
More information about the Gnupg-users