> >If i understand the sequence here: The current git HEAD is that > >pgp_pub_decrypt would throw an error if given a signed and encrypted > >message, and earlier version of your patch changed that to decrypt the > >message and ignore the signature, and the current version went back to > >throwing an error. > > > >I think I prefer the middle of those behaviors. The original behavior > >seems like a bug to me, and I don't think we need to be backwards > >compatible with bugs. Why should a function called "decrypt" care if the > >message is also signed? That is not its job. > > I haven't updated the patch yet because I don't want to waste my > time going back and forth until we have a consensus, but I think I > prefer Jeff's suggestion here to make the _decrypt() functions > ignore signatures. Does anyone else want to voice their opinion?
+1 for ignoring sigs. If somebody want to check sigs, that's a separate step. Maybe we could have an optional boolean flag, default false, to enable checking sigs, but that seems material for a future patch.
That said, I do wonder if it's a behavior change with security implications: if somebody is relying on the current behavior of throwing an error when sigs don't match, they wouldn't be thrilled to hear that their security checks now fail to detect a problem because we don't verify signatures when decrypting. In other words, is this established practice already? If not, it's okay; otherwise, hmm.
If it is established practise, I think the only security model that could be used to justify it is "The bad guys will be nice enough to always sign their attacks, while the good guys will refrain from signing them." It is not clear why the bad guys would cooperate with that.
Anyone who can produce an encrypted and signed attack message could also produce an encrypted and unsigned one, couldn't they?