> Von: Werner Koch [mailto:w...@gnupg.org]
>
> On Wed, 16 May 2018 16:24, roman.fied...@ait.ac.at said:
>
> > In my opinion it is hard to find such a "one size fits all"
> > solution. Like Werner's example: disabling decryption streaming
>
> The goal of the MDC is to assure that the message has been received
> exactly as the sender set it.  Thus there is just a binary decision:
> Okay or Fail.  Everything is like you have been dropped at boot time
> into manual fsck mode - you can do something about it or you just
> irginore things and restore the partition.

How could that work together with the memory based "wipe" approach, you 
envisioned in your message 
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last 
paragraph?

If I understand your approach correctly, it will imply that at least one 
do-not-apply-one-size-fits-all switch has to be present, thus contradicting one 
of your statements. Or did I get something wrong in my argument? The decision 
output (fail/ok) in the end might be binary for both use-cases but the internal 
logic (process model) for validation/output will be different.

> > 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.
>
> It is already there.  If you use "--output FILE" the file is either
> created or not.  Your choice.

Would that imply, that using e.g. "--output /proc/self/3" would implicitly 
change the security behavior of gpg, e.g. by switching from "output before 
validation" model to "validation before output" model (again compare your 
message, cited above)? Implicit feedback from selected output mode on security 
related MDC-check behavior would seem dangerous to me. Somehow rings an alarm 
bell, if that should be the proposed solution.

LG Roman
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to