On Fri, Apr 02, 2021 at 10:10:36AM -0400, Bruce Momjian wrote:
> Works for me.
Thanks. I got to spend some time on this stuff again today and did a
complete review, without noticing any issues except some indentation
that was strange so I have applied it. Attached is a small extension
I have use
On Fri, Apr 2, 2021 at 07:04:18PM +0900, Michael Paquier wrote:
> On Mon, Feb 15, 2021 at 08:25:27PM +0900, Michael Paquier wrote:
> > Again a new rebase, giving v5:
> > - Fixed the APIs to return -1 if the caller gives NULL in input, to be
> > consistent with cryptohash.
> > - Added a length argu
On Mon, Feb 15, 2021 at 08:25:27PM +0900, Michael Paquier wrote:
> Again a new rebase, giving v5:
> - Fixed the APIs to return -1 if the caller gives NULL in input, to be
> consistent with cryptohash.
> - Added a length argument to pg_hmac_final(), wiht sanity checks.
So, this patch has been aroun
On Sat, Jan 23, 2021 at 01:43:20PM +0900, Michael Paquier wrote:
> Rebased patch is attached wiht SHA1 added as of a8ed6bb. Now that
> SHA1 is part of the set of options for cryptohashes, a lot of code of
> pgcrypto can be cleaned up thanks to the refactoring done here, but
> I am leaving that as
On Fri, Jan 08, 2021 at 04:11:53PM +0900, Michael Paquier wrote:
> Please find attached a rebased version. I have simplified the
> implementation to use an opaque pointer similar to the cryptohash
> part, leading to a large cleanup of the allocation logic for both
> implementations, with and witho
On Fri, Dec 18, 2020 at 03:46:42PM +0900, Michael Paquier wrote:
> This has been tested on Windows and Linux across all the versions of
> OpenSSL we support on HEAD. I am also attaching a small module called
> hmacfuncs that I used as a way to validate this patch across all the
> versions of OpenS
On Fri, Dec 18, 2020 at 07:42:02PM -0500, Bruce Momjian wrote:
> > Please note that on a related thread that I have begun yesterday,
> > Heikki has suggested some changes in the way we handle the opaque data
> > used by each cryptohash implementation.
> > https://www.postgresql.org/message-id/6ebe7
On Sat, Dec 19, 2020 at 09:35:57AM +0900, Michael Paquier wrote:
> On Fri, Dec 18, 2020 at 10:48:00AM -0500, Bruce Momjian wrote:
> > Great. See my questions in the key manager thread about whether I
> > should use the init/update/final API or just keep the one-line version.
> > As far as when to
On Fri, Dec 18, 2020 at 10:48:00AM -0500, Bruce Momjian wrote:
> Great. See my questions in the key manager thread about whether I
> should use the init/update/final API or just keep the one-line version.
> As far as when to commit this, I think the quiet time is actually better
> because if you b
On Fri, Dec 18, 2020 at 03:46:42PM +0900, Michael Paquier wrote:
> On Fri, Dec 18, 2020 at 08:41:01AM +0900, Michael Paquier wrote:
> > Knowing that we are in a period of vacations for a lot of people, and
> > that this is a sensitive area of the code that involves
> > authentication, I think that
On Fri, Dec 18, 2020 at 08:41:01AM +0900, Michael Paquier wrote:
> Knowing that we are in a period of vacations for a lot of people, and
> that this is a sensitive area of the code that involves
> authentication, I think that it is better to let this thread brew
> longer and get more eyes to look a
On Thu, Dec 17, 2020 at 12:53:06PM -0500, Bruce Momjian wrote:
> Very nice. Are you planning to apply this soon? If so, I will delay
> my key management patch until this is applied. If not, I will update my
> HMAC call when you apply this.
Knowing that we are in a period of vacations for a lot
On Wed, Dec 16, 2020 at 04:17:50PM +0900, Michael Paquier wrote:
> Please note that I have added code that should be enough for the
> compilation on Windows, but I have not taken the time to check that.
> I have checked that things compiled and that check-world passes
> with and without OpenSSL 1.1
13 matches
Mail list logo
