> Von: Andrew Gallagher [mailto:andr...@andrewg.com] > > > On 16 May 2018, at 13:44, Fiedler Roman <roman.fied...@ait.ac.at> > 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.
In my opinion it is hard to find such a "one size fits all" solution. Like Werner's example: disabling decryption streaming operation might increase security for some use-cases (validation before decryption&output) but might make others impossible, like streaming of backups (decryption&output before final validation). So you need something on the interface to support that non-standard behavior, deviate from the default. > 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. Yes, another example for different use-cases and hence different process model requirements in software. > I’m going to preemptively quote RJH here before he gets around to it. Use the > defaults! ;-) Then why are there already so many command line options for decryption/validation gpg not just one: "--insecure"? From my point of view, monopolists might be able to push one set of defaults but the open source software ecosystem might work differently: those projects survive, that enable that many use-cases per development effort, so that they find sufficient developers/funds to support development. If they drift off, the project will fork/another project might take over. So gpg has to watch out for the optimum point between following extremes: 1) Only supporting one standard use-case with default settings (thus increasing security but loosing users) 2) Supporting many use-cases via different gpg-internal decryption/validation-process models (requiring loads of parameters, complex models, lot of implementation, risk to invoke gpg with wrong parameters) 3) Supporting one generic use-case/process model and leaving it to the caller (other side of interface) to decide what to make from it (risk, that other party just does not do it right - e.g. ignores a warning like with Efail) Assuming, that the ideal point would be somewhere in between, supporting only a single FAIL status like old-style shell commands might not be sufficient to attract sufficient users from world 1, 2, 3 above. LG Roman _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users