On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
> Marko Kreen <marko@l-t.ee> writes:
> > On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
> >> That doesn't seem like a good idea at all. Why shouldn't an encryptable
> >> value be NULL? I think you should just make 'em strict.
>
> > Well, I have mainly issues with decrypt part. I'd like
> > to say, if decrypt succeeds, whoever put the data there,
> > had the key. Existing decrypt() has a smell of it - there
> > is 1/256 chance that data modification won't be detected.
>
> And that has what to do with throwing an error on NULL input?
It is not an encrypted value so do not succeed.
> > As for the crypt() case, lets say you have a new user with
> > hashed password field NULL. In addition, you have client
> > program that compares crypt() result with hashed field
> > itself, in addition it handles NULL's as empty string.
> > Result: it is possible to login with any password.
> > Lots of assumptions but in eg. PHP case they are all filled.
>
> A NULL password field is intended to have exactly that effect, no?
I hope not.
But I think I see - throwing error on NULL goes against standard
practice and anyway NULL handling should be user responsibility,
not pgcrypto's.
Maybe I'm getting too paranoid from tracking all the error
conditions in pgp code.
Michael, the result is, you can make them all STRICT.
--
marko