Usability of OpenSSL vs GNUPG

[halfdog]

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
long run).

> 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 
> annoying.
>
> 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
opinion:

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
  production.
* 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.


hd