On Fri, Feb 3, 2017 at 9:52 PM, Heikki Linnakangas wrote:
> On 12/20/2016 03:47 AM, Michael Paquier wrote:
>>
>> The first thing is to be able to understand in the SCRAM code if a
>> string is UTF-8 or not, and this code is in src/common/. pg_wchar.c
>> offers a set of routines exactly for this pu
On 12/20/2016 03:47 AM, Michael Paquier wrote:
The first thing is to be able to understand in the SCRAM code if a
string is UTF-8 or not, and this code is in src/common/. pg_wchar.c
offers a set of routines exactly for this purpose, which is built with
libpq but that's not available for src/commo
On 02/02/2017 05:50 AM, David Rowley wrote:
On 2 February 2017 at 00:13, Heikki Linnakangas wrote:
Ok, I'll drop the second patch for now. I committed the first patch after
fixing the things you and Michael pointed out. Thanks for the review!
dbd69118 caused small compiler warning for me.
Th
On 2 February 2017 at 00:13, Heikki Linnakangas wrote:
> Ok, I'll drop the second patch for now. I committed the first patch after
> fixing the things you and Michael pointed out. Thanks for the review!
dbd69118 caused small compiler warning for me.
The attached fixed it.
--
David Rowley
On 01/17/2017 11:51 PM, Peter Eisentraut wrote:
On 1/3/17 9:09 AM, Heikki Linnakangas wrote:
Since not everyone agrees with this approach, I split this patch into
two. The first patch refactors things, replacing the isMD5() function
with get_password_type(), without changing the representation o
On Wed, Jan 18, 2017 at 2:46 PM, Michael Paquier
wrote:
> FWIW, this patch is on a "waiting on author" state and that's right.
> As the discussion on SASLprepare() and the decisions regarding the way
> to implement it, or at least have it, are still pending, I am not
> planning to move on with any
On Thu, Jan 19, 2017 at 6:17 PM, Simon Riggs wrote:
> We seem to be caught between adding lots of new things as parameters
> and adding new detail into pg_hba.conf.
>
> Parameters like password_encryption are difficult here because they
> essentially repeat what has already been said in the pg_hba
On 19 January 2017 at 06:32, Noah Misch wrote:
> On Wed, Jan 18, 2017 at 02:30:38PM +0900, Michael Paquier wrote:
>> On Wed, Jan 18, 2017 at 2:23 PM, Noah Misch wrote:
>> > The latest versions document this precisely, but I agree with Peter's
>> > concern
>> > about plain "scram". Suppose it's
On Wed, Jan 18, 2017 at 02:30:38PM +0900, Michael Paquier wrote:
> On Wed, Jan 18, 2017 at 2:23 PM, Noah Misch wrote:
> > The latest versions document this precisely, but I agree with Peter's
> > concern
> > about plain "scram". Suppose it's 2025 and PostgreSQL support SASL
> > mechanisms
> > O
On Tue, Dec 20, 2016 at 10:47 AM, Michael Paquier
wrote:
> And Heikki has mentioned me that he'd prefer not having an extra
> dependency for the normalization, which is LGPL-licensed by the way.
> So I have looked at the SASLprep business to see what should be done
> to get a complete implementati
On Wed, Jan 18, 2017 at 2:23 PM, Noah Misch wrote:
> The latest versions document this precisely, but I agree with Peter's concern
> about plain "scram". Suppose it's 2025 and PostgreSQL support SASL mechanisms
> OAUTHBEARER, SCRAM-SHA-256, SCRAM-SHA-256-PLUS, and SCRAM-SHA3-512. What
> should t
On Tue, Nov 15, 2016 at 07:52:06AM +0900, Michael Paquier wrote:
> On Sat, Nov 5, 2016 at 9:36 PM, Michael Paquier
> wrote:
> > On Sat, Nov 5, 2016 at 12:58 AM, Peter Eisentraut
> > wrote:
> > pg_hba.conf uses "scram" as keyword, but scram refers to a family of
> > authentication methods. There
On 1/3/17 9:09 AM, Heikki Linnakangas wrote:
> Since not everyone agrees with this approach, I split this patch into
> two. The first patch refactors things, replacing the isMD5() function
> with get_password_type(), without changing the representation of
> pg_authid.rolpassword. That is hopeful
On Thu, Jan 5, 2017 at 10:31 PM, Peter Eisentraut
wrote:
> On 1/3/17 9:09 AM, Heikki Linnakangas wrote:
>> Since not everyone agrees with this approach, I split this patch into
>> two. The first patch refactors things, replacing the isMD5() function
>> with get_password_type(), without changing th
On 1/3/17 9:09 AM, Heikki Linnakangas wrote:
> Since not everyone agrees with this approach, I split this patch into
> two. The first patch refactors things, replacing the isMD5() function
> with get_password_type(), without changing the representation of
> pg_authid.rolpassword. That is hopeful
On Tue, Jan 3, 2017 at 11:09 PM, Heikki Linnakangas wrote:
> Since not everyone agrees with this approach, I split this patch into two.
> The first patch refactors things, replacing the isMD5() function with
> get_password_type(), without changing the representation of
> pg_authid.rolpassword. Tha
On 12/21/2016 04:09 AM, Michael Paquier wrote:
Thanks for having a look! Attached is a new version, with that bug fixed.
I have been able more advanced testing without the crash and things
seem to work properly. The attached set of tests is also able to pass
for all the combinations of hba conf
On 12/14/2016 01:33 PM, Heikki Linnakangas wrote:
I just noticed that the manual for CREATE ROLE says:
Note that older clients might lack support for the MD5 authentication
mechanism that is needed to work with passwords that are stored
encrypted.
That's is incorrect. The alternative to MD5 a
On Tue, Dec 20, 2016 at 9:23 PM, Heikki Linnakangas wrote:
> On 12/16/2016 03:31 AM, Michael Paquier wrote:
> Actually, it does still perform that check. There's a new function,
> plain_crypt_verify, that passwordcheck uses now. plain_crypt_verify() is
> intended to work with any future hash forma
David,
* David Fetter (da...@fetter.org) wrote:
> On Tue, Dec 20, 2016 at 06:14:40PM -0500, Stephen Frost wrote:
> > * David Fetter (da...@fetter.org) wrote:
> > > On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> > > > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > > > > Even if
On Tue, Dec 20, 2016 at 06:14:40PM -0500, Stephen Frost wrote:
> David,
>
> * David Fetter (da...@fetter.org) wrote:
> > On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> > > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > > > Even if you have a separate "verifier type" column, it
David,
* David Fetter (da...@fetter.org) wrote:
> On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > > Even if you have a separate "verifier type" column, it's not fully
> > > normalized, because there's still a dependency between t
On Wed, Dec 21, 2016 at 1:08 AM, David Fetter wrote:
> Would a view that shows only what's to the left of the first semicolon
> suit this purpose?
Of course it would, you would just need to make the routines now
checking the shape of MD5 and SCRAM identifiers available at SQL level
and feed the s
On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> Heikki,
>
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > Even if you have a separate "verifier type" column, it's not fully
> > normalized, because there's still a dependency between the
> > verifier and verifier type columns. Y
Heikki,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> Even if you have a separate "verifier type" column, it's not fully
> normalized, because there's still a dependency between the verifier
> and verifier type columns. You will always need to look at the
> verifier type to make sense of the ver
On Tue, Dec 20, 2016 at 6:37 AM, Heikki Linnakangas wrote:
> It's more convenient to carry the type information with the verifier itself,
> in backend code, in pg_dump, etc. Sure, you could have a separate "transfer"
> text format that has the prefix, and strip it out when the datum enters the
> s
On 12/16/2016 03:31 AM, Michael Paquier wrote:
On Thu, Dec 15, 2016 at 9:48 PM, Heikki Linnakangas wrote:
The only way to distinguish, is to know about every verifier kind there is,
and check whether rolpassword looks valid as anything else than a plaintext
password. And we already got tripped
On 12/16/2016 05:48 PM, Robert Haas wrote:
On Thu, Dec 15, 2016 at 8:40 AM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 12/14/2016 04:57 PM, Stephen Frost wrote:
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
On 12/14/16 5:15 AM, Michael Paquier wrote:
On Sat, Dec 17, 2016 at 5:48 PM, Michael Paquier
wrote:
> On Sun, Dec 18, 2016 at 3:59 AM, Robert Haas wrote:
>> On Fri, Dec 16, 2016 at 5:30 PM, Michael Paquier
>> wrote:
>>> From the discussions of last year on -hackers, it was decided to *not*
>>> have an additional column per complains from
On Thu, Dec 15, 2016 at 3:17 PM, Michael Paquier
wrote:
> In the case where the binaries are *not* built with libidn, I think
> that we had better reject valid UTF-8 string directly and just allow
> ASCII? SASLprep is a no-op on ASCII characters.
>
> Thoughts about this approach?
And Heikki has m
On Sun, Dec 18, 2016 at 3:59 AM, Robert Haas wrote:
> On Fri, Dec 16, 2016 at 5:30 PM, Michael Paquier
> wrote:
>> From the discussions of last year on -hackers, it was decided to *not*
>> have an additional column per complains from a couple of hackers
>> (Robert you were in this set at this poi
On Fri, Dec 16, 2016 at 5:30 PM, Michael Paquier
wrote:
> On Sat, Dec 17, 2016 at 5:42 AM, Stephen Frost wrote:
>> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>>> On 12/15/16 8:40 AM, Stephen Frost wrote:
>>> > I don't follow why we can't change the syntax for CREATE USER to allo
On Sat, Dec 17, 2016 at 10:23 AM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> (Robert you were in this set at this point), and the same thing was
>> concluded during the informal lunch meeting at PGcon. The point is,
>> the existing SCRAM patch set can survive wi
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Dec 17, 2016 at 5:42 AM, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >> On 12/15/16 8:40 AM, Stephen Frost wrote:
> >> > I don't follow why we can't change the syntax for CREATE USE
On Sat, Dec 17, 2016 at 5:42 AM, Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> On 12/15/16 8:40 AM, Stephen Frost wrote:
>> > I don't follow why we can't change the syntax for CREATE USER to allow
>> > specifying the verifier type independently.
>>
>> That'
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 12/15/16 8:40 AM, Stephen Frost wrote:
> > I don't follow why we can't change the syntax for CREATE USER to allow
> > specifying the verifier type independently.
>
> That's what the last patch set I looked at actually does.
Well, s
On 12/15/16 8:40 AM, Stephen Frost wrote:
> I don't follow why we can't change the syntax for CREATE USER to allow
> specifying the verifier type independently.
That's what the last patch set I looked at actually does.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Devel
On Thu, Dec 15, 2016 at 8:40 AM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> On 12/14/2016 04:57 PM, Stephen Frost wrote:
>> >* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> >>On 12/14/16 5:15 AM, Michael Paquier wrote:
>> >>>I would be tempted to sugges
On Thu, Dec 15, 2016 at 9:48 PM, Heikki Linnakangas wrote:
> The only way to distinguish, is to know about every verifier kind there is,
> and check whether rolpassword looks valid as anything else than a plaintext
> password. And we already got tripped by a bug-of-omission on that once. If
> we
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 12/14/2016 04:57 PM, Stephen Frost wrote:
> >* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >>On 12/14/16 5:15 AM, Michael Paquier wrote:
> >>>I would be tempted to suggest adding the verifier type as a new column
> >>>of pg_authid
On 12/15/2016 03:00 AM, Michael Paquier wrote:
On Wed, Dec 14, 2016 at 8:33 PM, Heikki Linnakangas wrote:
But, a password stored in plaintext works with either MD5 or SCRAM, or any
future authentication mechanism. So as soon as we have SCRAM authentication,
it becomes somewhat useful again.
In
On 12/14/2016 04:57 PM, Stephen Frost wrote:
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
On 12/14/16 5:15 AM, Michael Paquier wrote:
I would be tempted to suggest adding the verifier type as a new column
of pg_authid
Yes please.
This discussion seems to continue to come up
On Tue, Dec 13, 2016 at 2:44 PM, Michael Paquier
wrote:
> SASLPrep is defined here:
> https://tools.ietf.org/html/rfc4013
> And stringprep is here:
> https://tools.ietf.org/html/rfc3454
> So that's roughly applying a conversion from the mapping table, taking
> into account prohibited, bi-direction
On Wed, Dec 14, 2016 at 8:33 PM, Heikki Linnakangas wrote:
> But, a password stored in plaintext works with either MD5 or SCRAM, or any
> future authentication mechanism. So as soon as we have SCRAM authentication,
> it becomes somewhat useful again.
>
> In a nutshell:
>
> auth / stored MD5
On 12/14/2016 11:41 AM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 14 December 2016 20:12:05 EET, Bruce Momjian wrote:
On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote:
Storing plaintext passwords has been bad form for just about forever and
I would
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 14 December 2016 20:12:05 EET, Bruce Momjian wrote:
> >On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote:
> >> I would so like to just drop support for plain passwords completely
> >:) But
> >> there's a backwards compatibility issue
On 14 December 2016 20:12:05 EET, Bruce Momjian wrote:
>On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote:
>> I would so like to just drop support for plain passwords completely
>:) But
>> there's a backwards compatibility issue to think about of course.
>>
>> But -- is there any
On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote:
> I would so like to just drop support for plain passwords completely :) But
> there's a backwards compatibility issue to think about of course.
>
> But -- is there any actual usecase for them anymore?
I thought we recommended 'pass
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 12/14/16 5:15 AM, Michael Paquier wrote:
> > I would be tempted to suggest adding the verifier type as a new column
> > of pg_authid
>
> Yes please.
This discussion seems to continue to come up and I don't entirely
understand why w
On 12/14/16 5:15 AM, Michael Paquier wrote:
> I would be tempted to suggest adding the verifier type as a new column
> of pg_authid
Yes please.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-
On 12/14/2016 12:27 PM, Magnus Hagander wrote:
I would so like to just drop support for plain passwords completely :) But
there's a backwards compatibility issue to think about of course.
But -- is there any actual usecase for them anymore?
Hmm. At the moment, I don't think there is.
But, a p
On 12/14/2016 12:15 PM, Michael Paquier wrote:
This work is definitely something that should be done before anything
else. Need a patch or are you on it?
I'm on it..
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
On Wed, Dec 14, 2016 at 9:51 AM, Heikki Linnakangas wrote:
> On 12/09/2016 10:19 AM, Michael Paquier wrote:
>
>> On Fri, Dec 9, 2016 at 5:11 PM, Heikki Linnakangas
>> wrote:
>>
>>> Couple of things I should write down before I forget:
>>>
>>> 1. It's a bit cumbersome that the scram verifiers sto
On Wed, Dec 14, 2016 at 5:51 PM, Heikki Linnakangas wrote:
> The tip of the work branch can now do SCRAM authentication, when a user has
> a plaintext password in pg_authid.rolpassword. The reverse doesn't work,
> however: you cannot do plain "password" authentication, when the user has a
> SCRAM
On 12/09/2016 10:19 AM, Michael Paquier wrote:
On Fri, Dec 9, 2016 at 5:11 PM, Heikki Linnakangas wrote:
Couple of things I should write down before I forget:
1. It's a bit cumbersome that the scram verifiers stored in
pg_authid.rolpassword don't have any clear indication that they're scram
ve
On Tue, Dec 13, 2016 at 10:43 AM, Michael Paquier
wrote:
> On Mon, Dec 12, 2016 at 11:39 PM, Heikki Linnakangas wrote:
>> A few couple more things that caught my eye while hacking on this:
Looking at what we have now, in the branch...
>> * Use SASLPrep for passwords.
SASLPrep is defined here:
On Mon, Dec 12, 2016 at 11:39 PM, Heikki Linnakangas wrote:
> A few couple more things that caught my eye while hacking on this:
>
> 1. We don't use SASLPrep to scrub username's and passwords. That's by
> choice, for usernames, because historically in PostgreSQL usernames can be
> stored in any en
On 12 December 2016 at 22:39, Heikki Linnakangas wrote:
> * Throw an error if an "authorization identity" is given. ATM, we just
> ignore it, but seems better to reject the attempt than do something that
> might not be what the client expects.
Yeah. That might be an opportunity to make admins' a
A few couple more things that caught my eye while hacking on this:
1. We don't use SASLPrep to scrub username's and passwords. That's by
choice, for usernames, because historically in PostgreSQL usernames can
be stored in any encoding, but SASLPrep assumes UTF-8. We dodge that by
passing an em
On 12/09/2016 01:10 PM, Michael Paquier wrote:
On Fri, Dec 09, 2016 at 11:51:45AM +0200, Heikki Linnakangas wrote:
On 12/09/2016 05:58 AM, Michael Paquier wrote:
One thing is: when do we look up at pg_authid? After receiving the
first message from client or before beginning the exchange? As th
On Fri, Dec 09, 2016 at 11:51:45AM +0200, Heikki Linnakangas wrote:
> On 12/09/2016 05:58 AM, Michael Paquier wrote:
> >
> > One thing is: when do we look up at pg_authid? After receiving the
> > first message from client or before beginning the exchange? As the
> > first message from client has t
On 12/09/2016 05:58 AM, Michael Paquier wrote:
One thing is: when do we look up at pg_authid? After receiving the
first message from client or before beginning the exchange? As the
first message from client has the user name, it would make sense to do
the lookup after receiving it, but from PG p
On Fri, Dec 9, 2016 at 5:11 PM, Heikki Linnakangas wrote:
> Couple of things I should write down before I forget:
>
> 1. It's a bit cumbersome that the scram verifiers stored in
> pg_authid.rolpassword don't have any clear indication that they're scram
> verifiers. MD5 hashes are readily identifia
Couple of things I should write down before I forget:
1. It's a bit cumbersome that the scram verifiers stored in
pg_authid.rolpassword don't have any clear indication that they're scram
verifiers. MD5 hashes are readily identifiable by the "md5" prefix. I
think we should use a "scram-sha-256:
On 12/09/2016 05:58 AM, Michael Paquier wrote:
On Thu, Dec 8, 2016 at 10:05 PM, Michael Paquier
wrote:
On Thu, Dec 8, 2016 at 5:55 PM, Heikki Linnakangas wrote:
Actually, we don't give away that information currently. If you try to log
in with password or MD5 authentication, and the user does
On Thu, Dec 8, 2016 at 10:05 PM, Michael Paquier
wrote:
> On Thu, Dec 8, 2016 at 5:55 PM, Heikki Linnakangas wrote:
>> On 12/08/2016 10:18 AM, Michael Paquier wrote:
>>> Hmmm. How do we handle the case where the user name does not match
>>> then? The spec gives an error message e= specifically fo
On Thu, Dec 8, 2016 at 5:55 PM, Heikki Linnakangas wrote:
> On 12/08/2016 10:18 AM, Michael Paquier wrote:
>> Hmmm. How do we handle the case where the user name does not match
>> then? The spec gives an error message e= specifically for this case.
>
> Hmm, interesting. I wonder how/when they imag
On 12/08/2016 10:18 AM, Michael Paquier wrote:
On Thu, Dec 8, 2016 at 5:54 AM, Heikki Linnakangas wrote:
Attached those here, as add-on patches to your latest patch set.
Thanks for looking at it!
I'll continue reviewing, but a couple of things caught my eye that you may want
to jump on, in
On Thu, Dec 8, 2016 at 5:54 AM, Heikki Linnakangas wrote:
> Attached those here, as add-on patches to your latest patch set.
Thanks for looking at it!
> I'll continue reviewing, but a couple of things caught my eye that you may
> want
> to jump on, in the meanwhile:
>
> On error messages, the s
On 12/07/2016 08:39 AM, Michael Paquier wrote:
On Tue, Nov 29, 2016 at 1:36 PM, Michael Paquier
wrote:
Nothing more will likely happen in this CF, so I have moved it to
2017-01 with the same status of "Needs Review".
Attached is a new set of patches using the new routines
pg_backend_random()
On Fri, Nov 18, 2016 at 2:51 AM, Michael Paquier
wrote:
> On Thu, Nov 17, 2016 at 8:12 AM, Robert Haas wrote:
>> So, the problem isn't Darwin-specific. I experimented with this on
>> Linux and found Linux does the same thing with libpgcommon_srv.a that
>> macOS does: a file in the archive that i
On Thu, Nov 17, 2016 at 8:12 AM, Robert Haas wrote:
> So, the problem isn't Darwin-specific. I experimented with this on
> Linux and found Linux does the same thing with libpgcommon_srv.a that
> macOS does: a file in the archive that is totally unused is omitted
> from the postgres binary. In Li
On Wed, Nov 16, 2016 at 11:28 PM, Michael Paquier
wrote:
> On Wed, Nov 16, 2016 at 8:04 PM, Michael Paquier
> wrote:
>> In the current set of patches, the sha2 functions would not get used
>> until the main patch for SCRAM gets committed so that's a couple of
>> steps and many months ahead.. And
On Wed, Nov 16, 2016 at 8:04 PM, Michael Paquier
wrote:
> In the current set of patches, the sha2 functions would not get used
> until the main patch for SCRAM gets committed so that's a couple of
> steps and many months ahead.. And --as-needed/--no-as-needed are not
> supported in macos. So I wou
On Wed, Nov 16, 2016 at 6:51 PM, Robert Haas wrote:
> So, it seems that the linker is willing to drop archive members if the
> entire .o file is used, but not individual symbols. That explains why
> Michael thinks we need to do something special here, because with his
> 0001 patch, nothing in the
On Wed, Nov 16, 2016 at 7:36 PM, Andres Freund wrote:
> With -Wl,--as-neeeded the linker will dismiss unused symbols found in a
> static library. Maybe that's the difference?
The man page --as-needed says that --as-needed modifies the behavior
of dynamic libraries, not static ones. If there is a
Hi,
On 2016-11-16 19:29:41 -0500, Robert Haas wrote:
> On Wed, Nov 16, 2016 at 6:56 PM, Michael Paquier
> wrote:
> > On Wed, Nov 16, 2016 at 11:24 AM, Robert Haas wrote:
> >> diff --git a/contrib/pgcrypto/Makefile b/contrib/pgcrypto/Makefile
> >> index 805db76..ddb0183 100644
> >> --- a/contrib/
On Wed, Nov 16, 2016 at 6:56 PM, Michael Paquier
wrote:
> On Wed, Nov 16, 2016 at 11:24 AM, Robert Haas wrote:
>> diff --git a/contrib/pgcrypto/Makefile b/contrib/pgcrypto/Makefile
>> index 805db76..ddb0183 100644
>> --- a/contrib/pgcrypto/Makefile
>> +++ b/contrib/pgcrypto/Makefile
>> @@ -1,6 +1
On Wed, Nov 16, 2016 at 11:24 AM, Robert Haas wrote:
> diff --git a/contrib/pgcrypto/Makefile b/contrib/pgcrypto/Makefile
> index 805db76..ddb0183 100644
> --- a/contrib/pgcrypto/Makefile
> +++ b/contrib/pgcrypto/Makefile
> @@ -1,6 +1,6 @@
> # contrib/pgcrypto/Makefile
>
> -INT_SRCS = md5.c sha1.
On Wed, Nov 16, 2016 at 1:53 PM, Michael Paquier
wrote:
>> Yeah, I don't see a point to that.
>
> OK, by doing so here is what I have. The patch generated by
> format-patch, as well as diffs generated by git diff -M are reduced
> and the patch gets half in size. They could be reduced more by addin
On Wed, Nov 16, 2016 at 4:46 AM, Robert Haas wrote:
> On Tue, Nov 15, 2016 at 5:12 PM, Michael Paquier
> wrote:
>> On Tue, Nov 15, 2016 at 12:40 PM, Robert Haas wrote:
>>> On Tue, Nov 15, 2016 at 2:24 PM, Michael Paquier
>>> wrote:
How do you plug in that with OpenSSL? Are you suggesting t
On Tue, Nov 15, 2016 at 5:12 PM, Michael Paquier
wrote:
> On Tue, Nov 15, 2016 at 12:40 PM, Robert Haas wrote:
>> On Tue, Nov 15, 2016 at 2:24 PM, Michael Paquier
>> wrote:
>>> How do you plug in that with OpenSSL? Are you suggesting to use a set
>>> of undef definitions in the new header in the
On Tue, Nov 15, 2016 at 12:40 PM, Robert Haas wrote:
> On Tue, Nov 15, 2016 at 2:24 PM, Michael Paquier
> wrote:
>> How do you plug in that with OpenSSL? Are you suggesting to use a set
>> of undef definitions in the new header in the same way as pgcrypto is
>> doing, which is rather ugly? Becaus
On Tue, Nov 15, 2016 at 2:24 PM, Michael Paquier
wrote:
> How do you plug in that with OpenSSL? Are you suggesting to use a set
> of undef definitions in the new header in the same way as pgcrypto is
> doing, which is rather ugly? Because that's what the deal is about in
> this patch.
Perhaps tha
On Tue, Nov 15, 2016 at 10:40 AM, Robert Haas wrote:
> On Fri, Nov 4, 2016 at 11:58 AM, Peter Eisentraut
> wrote:
>> The organization of these patches makes sense to me.
>>
>> On 10/20/16 1:14 AM, Michael Paquier wrote:
>>> - 0001, moving all the SHA2 functions to src/common/ and introducing a
>>
On Fri, Nov 4, 2016 at 11:58 AM, Peter Eisentraut
wrote:
> The organization of these patches makes sense to me.
>
> On 10/20/16 1:14 AM, Michael Paquier wrote:
>> - 0001, moving all the SHA2 functions to src/common/ and introducing a
>> PG-like interface. No actual changes here.
>
> That's probabl
On Wed, 9 Nov 2016 15:23:11 +0900
Michael Paquier wrote:
>
> (This is about patch 0007, not 0001)
> Thanks, you are right. That's not good as-is. So this basically means
> that the characters here should be from 32 to 127 included.
Really, most important is to exclude comma from the list of al
On Wed, Nov 9, 2016 at 3:13 PM, Victor Wagner wrote:
> On Tue, 18 Oct 2016 16:35:27 +0900
> Michael Paquier wrote:
>
> Hi
>> Attached is a rebased patch set for SCRAM, with the following things:
>> - 0001, moving all the SHA2 functions to src/common/ and introducing a
>> PG-like interface. No ac
On Tue, 18 Oct 2016 16:35:27 +0900
Michael Paquier wrote:
Hi
> Attached is a rebased patch set for SCRAM, with the following things:
> - 0001, moving all the SHA2 functions to src/common/ and introducing a
> PG-like interface. No actual changes here.
It seems, that client nonce generation in th
On Sat, Nov 5, 2016 at 12:58 AM, Peter Eisentraut
wrote:
> The organization of these patches makes sense to me.
>
> On 10/20/16 1:14 AM, Michael Paquier wrote:
>> - 0001, moving all the SHA2 functions to src/common/ and introducing a
>> PG-like interface. No actual changes here.
>
> That's probabl
The organization of these patches makes sense to me.
On 10/20/16 1:14 AM, Michael Paquier wrote:
> - 0001, moving all the SHA2 functions to src/common/ and introducing a
> PG-like interface. No actual changes here.
That's probably alright, although the patch contains a lot more changes
than I wou
On 10/17/2016 12:27 PM, Heikki Linnakangas wrote:
On 10/17/2016 12:18 PM, Michael Paquier wrote:
You removed the part of pgcrypto in charge of randomness, nice move. I
was wondering about how to do with the perfc and the unix_std at some
point, and ripping them off as you did is fine for me.
Y
On 10/17/2016 12:18 PM, Michael Paquier wrote:
You removed the part of pgcrypto in charge of randomness, nice move. I
was wondering about how to do with the perfc and the unix_std at some
point, and ripping them off as you did is fine for me.
Yeah. I didn't understand the need for the perfc stu
On Mon, Oct 17, 2016 at 5:55 PM, Heikki Linnakangas wrote:
> On 10/15/2016 04:26 PM, Michael Paquier wrote:
>>>
>>> * Now that we don't call random() in postmaster anymore, is there any
>>> point
>>> in calling srandom() there (i.e. where the above incorrect comment was)?
>>> Should we remove it?
On 10/15/2016 04:26 PM, Michael Paquier wrote:
* Now that we don't call random() in postmaster anymore, is there any point
in calling srandom() there (i.e. where the above incorrect comment was)?
Should we remove it? random() might be used by pre-loaded extensions,
though. (Hopefully not for cryp
On Fri, Oct 14, 2016 at 9:08 PM, Heikki Linnakangas wrote:
> On 10/12/2016 11:11 AM, Michael Paquier wrote:
> * Changed pg_strong_random() to return false on error, and let the callers
> handle errors. That's more error-prone than throwing an error in the
> function itself, as it's an easy mistake
On 10/14/2016 03:08 PM, Heikki Linnakangas wrote:
I spent some time whacking that around:
Sigh, forgot attachment. Here you go.
- Heikki
>From 4b3000df3dc71ad41018a6606c92bc4a0adeb8f5 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Fri, 14 Oct 2016 14:58:44 +0300
Subject: [PATCH 1/1]
On 10/12/2016 11:11 AM, Michael Paquier wrote:
And so we are back on that, with a new set:
Great! I'm looking at this first one for now:
- 0001, introducing pg_strong_random() in src/port/ to have the
backend portion of SCRAM use it instead of random(). This patch is
from Magnus who has kindl
On Wed, Sep 28, 2016 at 8:55 PM, Michael Paquier
wrote:
>> Our b64_encode routine does use whitespace, so we can't use it as is for
>> SCRAM. As the patch stands, we might never output anything long enough to
>> create linefeeds, but let's be tidy. The base64 implementation is about 100
>> lines o
Heikki, Michael, Magnus,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Sep 27, 2016 at 10:42 PM, Heikki Linnakangas wrote:
> > The libpq-side is not. Just calling random() won't do. We haven't needed for
> > random numbers in libpq before, but now we do. Is the pgcrypto solution
1 - 100 of 173 matches
Mail list logo
