Re: pgcrypto: PGP signatures - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: pgcrypto: PGP signatures
Date
Msg-id 541308D2.3000402@joh.to
Whole thread Raw
In response to Re: pgcrypto: PGP signatures  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: pgcrypto: PGP signatures
List pgsql-hackers
Hi Jeff,

On 9/8/14 7:30 PM, Jeff Janes wrote:
> There seems to be a memory leak in pgp_sym_decrypt_verify that does not
> exist in pgp_sym_decrypt.  It is about 58 bytes per decryption.

Thanks.  There seemed to have been a small confusion about the ownership
of ctx->sig_digest_ctx.  I've fixed that now and the test case you
provided doesn't appear to be leaking memory anymore.  I also added some
other missing free calls to pgp_free().

I've attached a patch with this problem fixed, in case you still want to
keep testing (all your work so far very much appreciated, btw!)  The
attached also fixes the ntohl() problem I pointed out in my previous
patch, and now AFAIK there aren't any outstanding technical issues.

However..

> 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?


.marko

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: ALTER SYSTEM RESET?
Next
From: Heikki Linnakangas
Date:
Subject: Re: pgbench throttling latency limit