> On 16 May 2018, at 13:44, Fiedler Roman <[email protected]> wrote: > > I am not sure, if gpg could support implementation/testing/life-cycle-efforts > to establish all those parameters and different process models for most of > the decryption processes gpg users envision to use gpg for.
Why do we need a plethora of configuration parameters to selectively turn off various parts of a security protocol? Why should we even encourage such a thing? With security, either everything seems to be ok, or it’s broken in such a way that it’s potentially an utter disaster. And quite probably both simultaneously. The only reasonable use case for selective disabling of security protocol features is for backwards compatibility. That doesn’t require fine grained control, just a version number. And even then, it opens up the possibility for user error. I’m going to preemptively quote RJH here before he gets around to it. Use the defaults! ;-) A _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
