Robert Haas writes:
> Of course, if there's some sort of commonly-used library out there for
> this sort of thing where we can just link against it and call whatever
> APIs it exposes, that might be a better alternative, or something to
> support in addition, but I don't really know whether there'
On Wed, Jan 4, 2017 at 11:49 AM, Stephen Frost wrote:
>> systemd has support for getting passwords to services without tty.
>
> Oh, that's interesting, I wasn't aware of that.
>
>> So if someone is interested, there is some room for enhancement here.
>
> Agreed.
The first thing that pops into my
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/4/17 10:57 AM, Tom Lane wrote:
> > I still maintain that the existing solution for passphrases is useless,
> > but in the interest of removing objections to the current patch, I'll
> > go make that happen.
>
> Sounds good.
Agreed
On 1/4/17 10:57 AM, Tom Lane wrote:
> I still maintain that the existing solution for passphrases is useless,
> but in the interest of removing objections to the current patch, I'll
> go make that happen.
Sounds good.
Looking around briefly (e.g., Apache, nginx), the standard approach
appears to
Peter Eisentraut writes:
> On 1/4/17 10:26 AM, Tom Lane wrote:
>> How will you know whether there's a pass phrase?
> One could register a password callback that remembers whether it was called.
Hmm ... actually, we don't even need to work that hard. If we simply
use the callback that's there no
On 1/4/17 10:26 AM, Tom Lane wrote:
> Andreas Karlsson writes:
>> Sorry, I was very unclear. I meant refusing the reload the SSL context
>> if there is a pass phrase, but that the rest of the config will be
>> reloaded just fine. This will lead to some log spam on every SIGHUP for
>> people wit
Andreas Karlsson writes:
> Sorry, I was very unclear. I meant refusing the reload the SSL context
> if there is a pass phrase, but that the rest of the config will be
> reloaded just fine. This will lead to some log spam on every SIGHUP for
> people with a pass phrase but should otherwise work
Stephen Frost writes:
> Indeed, this is important functionality that people are using.
Who exactly are these people, and why haven't they complained about how
crappy the support is now? I'm *completely* unconvinced by the argument
that the way it has worked in the past is an important feature th
* Andreas Karlsson (andr...@proxel.se) wrote:
> On 01/04/2017 04:14 PM, Stephen Frost wrote:
> >* Andreas Karlsson (andr...@proxel.se) wrote:
> >>A possible solution might be to only add the error throwing hook
> >>when loading certificates during SIGHUP (and at Windows) and to work
> >>as before o
On 01/04/2017 04:14 PM, Stephen Frost wrote:
* Andreas Karlsson (andr...@proxel.se) wrote:
A possible solution might be to only add the error throwing hook
when loading certificates during SIGHUP (and at Windows) and to work
as before on startup. Would that be an acceptable solution? I could
wri
* Andreas Karlsson (andr...@proxel.se) wrote:
> On 01/04/2017 03:48 PM, Magnus Hagander wrote:
> >On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane >It does not; what would be the point, if the key would be lost at
> >SIGHUP?
> >
> >If we lost it, yes. But we could keep the old key around if it has
On 01/04/2017 03:48 PM, Magnus Hagander wrote:
On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane
That means storing the pass phrase in the memory of the postmaster,
which does not sound like a terribly good idea to me, but I have never
used keys with pass phrases for daemons so it might be a common so
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> > > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote:
> > >> I think probably the right thing for now is to install a do-nothing
> > >> callback, so that at least we don't
On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote:
> >> I think probably the right thing for now is to install a do-nothing
> >> callback, so that at least we don't have the issue of the postmaster
> >> freezing at SIGHU
Magnus Hagander writes:
> On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote:
>> I think probably the right thing for now is to install a do-nothing
>> callback, so that at least we don't have the issue of the postmaster
>> freezing at SIGHUP. If someone feels like trying to revive support
>> of pas
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote:
>
> > Magnus Hagander writes:
> > > On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane wrote:
> > >> Before we leave this area, though, there is a loose end that requires
> > >> more thought. That is, what a
On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane wrote:
> >> Before we leave this area, though, there is a loose end that requires
> >> more thought. That is, what about passphrase-protected server keys?
> >> ...
> >> 2. Add
Peter Eisentraut writes:
> On 1/2/17 10:02 PM, Tom Lane wrote:
>> Before we leave this area, though, there is a loose end that requires
>> more thought. That is, what about passphrase-protected server keys?
> I don't have experience with this in practice, but my hunch would be
> that you can con
Magnus Hagander writes:
> On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane wrote:
>> Before we leave this area, though, there is a loose end that requires
>> more thought. That is, what about passphrase-protected server keys?
>> ...
>> 2. Add a password callback function that would supply the passphrase
On 1/2/17 10:02 PM, Tom Lane wrote:
> Before we leave this area, though, there is a loose end that requires
> more thought. That is, what about passphrase-protected server keys?
I don't have experience with this in practice, but my hunch would be
that you can continue to use passphrases as before
On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane wrote:
> Peter Eisentraut writes:
> > Yeah, it seems that if you want to know whether you are using SSL, then
> > we already have that. I don't see the need for this new read-only
> setting.
>
> I concur --- there might be use for more reporting about SS
Peter Eisentraut writes:
> Yeah, it seems that if you want to know whether you are using SSL, then
> we already have that. I don't see the need for this new read-only setting.
I concur --- there might be use for more reporting about SSL status, but
that patch doesn't seem like quite the right th
On 12/5/16 12:17 AM, Michael Paquier wrote:
> OK, here is attached what I had in mind as reload-ssl-v08-02.patch for
> reference. This applies on top of the main patch
> reload-ssl-v08-01.patch that is the same version as v7 with the issues
> I reported previously as addressed. LoadedSSL is mapped
On Mon, Dec 5, 2016 at 9:50 AM, Andreas Karlsson wrote:
> On 12/04/2016 03:20 PM, Michael Paquier wrote:
>> On Sun, Dec 4, 2016 at 11:11 PM, Andreas Karlsson
>> wrote:
>>> On 12/04/2016 02:12 PM, Michael Paquier wrote:
>>> Does this have a precedent in the code?
>>
>>
>> data_checksums in guc.c i
On 12/04/2016 03:20 PM, Michael Paquier wrote:
On Sun, Dec 4, 2016 at 11:11 PM, Andreas Karlsson wrote:
On 12/04/2016 02:12 PM, Michael Paquier wrote:
One last thing that I think is missing in this patch is for users the
possibility to check via SQL if the SSL context is actually loaded or
no
On Sun, Dec 4, 2016 at 11:11 PM, Andreas Karlsson wrote:
> On 12/04/2016 02:12 PM, Michael Paquier wrote:
>>
>> One last thing that I think is missing in this patch is for users the
>> possibility to check via SQL if the SSL context is actually loaded or
>> not. As the context is reloaded after al
On 12/04/2016 02:12 PM, Michael Paquier wrote:
One last thing that I think is missing in this patch is for users the
possibility to check via SQL if the SSL context is actually loaded or
not. As the context is reloaded after all the new values are
available, with the current patch users may see t
On Fri, Dec 2, 2016 at 1:02 PM, Michael Paquier
wrote:
> On Fri, Dec 2, 2016 at 11:26 AM, Andreas Karlsson wrote:
>> I have attached a new version. The commitfest should technically have been
>> closed by now, so do what you like with the status. I can always submit the
>> patch to the next commi
On Fri, Dec 2, 2016 at 11:26 AM, Andreas Karlsson wrote:
> I have attached a new version. The commitfest should technically have been
> closed by now, so do what you like with the status. I can always submit the
> patch to the next commitfest.
I have just moved it to the next CF. Will look at it
On 11/30/2016 06:52 AM, Michael Paquier wrote:
On Mon, Nov 28, 2016 at 2:01 PM, Michael Paquier
Looking at the latest patch at code-level, there is some refactoring
to introduce initialize_context(). But it is actually not necessary
(perhaps this is the remnant of a past version?) as be_tls_init
On Mon, Nov 28, 2016 at 2:01 PM, Michael Paquier
wrote:
> On Thu, Nov 24, 2016 at 11:15 PM, Andreas Karlsson wrote:
>> Never mind, I had not fetched the latest master. Once I had done so these
>> tests were both broken in my rebased branch and in the master branch without
>> any modifications. I
On Thu, Nov 24, 2016 at 11:15 PM, Andreas Karlsson wrote:
> Never mind, I had not fetched the latest master. Once I had done so these
> tests were both broken in my rebased branch and in the master branch without
> any modifications. I guess I will have to bisect this once I get home.
>
> Inof for
On 11/24/2016 02:49 PM, Andreas Karlsson wrote:
Thanks for finding this. I will look at this more once I get home, but
the tests do not fail on my computer. I wonder what I do differently.
What versions of Perl and OpenSSL do you run and how did you run the
tests when the failed? I ran the tests
On 11/24/2016 08:46 AM, Michael Paquier wrote:
On Sat, Nov 12, 2016 at 3:42 AM, Andreas Karlsson wrote:
On 11/11/2016 07:40 PM, Andreas Karlsson wrote:
Here is a new version of the patch with the only differences;
1) The SSL tests have been changed to use reload rather than restart
Did you
On Sat, Nov 12, 2016 at 3:42 AM, Andreas Karlsson wrote:
> On 11/11/2016 07:40 PM, Andreas Karlsson wrote:
>> Here is a new version of the patch with the only differences;
>>
>> 1) The SSL tests have been changed to use reload rather than restart
Did you check if the tests pass? I am getting a co
On Wed, Nov 23, 2016 at 5:48 AM, Michael Banck
wrote:
> On Fri, Nov 11, 2016 at 07:42:05PM +0100, Andreas Karlsson wrote:
>> On 11/11/2016 07:40 PM, Andreas Karlsson wrote:
>> >Here is a new version of the patch with the only differences;
>> >
>> >1) The SSL tests have been changed to use reload r
Hi,
On Fri, Nov 11, 2016 at 07:42:05PM +0100, Andreas Karlsson wrote:
> On 11/11/2016 07:40 PM, Andreas Karlsson wrote:
> >Here is a new version of the patch with the only differences;
> >
> >1) The SSL tests have been changed to use reload rather than restart
> >
> >2) Rebased on master
>
> And
On 11/11/2016 07:40 PM, Andreas Karlsson wrote:
Hi,
Here is a new version of the patch with the only differences;
1) The SSL tests have been changed to use reload rather than restart
2) Rebased on master
And here with a fix to a comment.
Andreas
diff --git a/doc/src/sgml/runtime.sgml b/doc
Hi,
Here is a new version of the patch with the only differences;
1) The SSL tests have been changed to use reload rather than restart
2) Rebased on master
Please take a look.
Andreas
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 787cfce..5e78d81 100644
--- a/doc/sr
On 11/10/2016 07:16 AM, Michael Paquier wrote:
On Wed, Nov 9, 2016 at 7:46 PM, Andreas Karlsson wrote:
Those tests fail due to that listen_addresses cannot be changed on reload so
none of the test cases can even connect to the database. When I hacked
ServerSetup.pm to set the correct listen_add
On Wed, Nov 9, 2016 at 7:46 PM, Andreas Karlsson wrote:
> Those tests fail due to that listen_addresses cannot be changed on reload so
> none of the test cases can even connect to the database. When I hacked
> ServerSetup.pm to set the correct listen_address before starting all tests
> pass.
Hm..
On 11/09/2016 06:54 AM, Michael Paquier wrote:
It seems to me that this patch is missing something... To begin with,
src/test/ssl/ServerSetup.pm should be patched so as the new SSL
configuration is reloaded after pg_ctl reload, and not after an
instance restart. That's straight-forward:
--- a/src
On Wed, Nov 9, 2016 at 3:48 AM, Andreas Karlsson wrote:
> On 11/08/2016 01:22 PM, Michael Banck wrote:
>>
>> Thanks! I couldn't find furhter faults in my testing. I guess the
>> question what to do about this on Windows is possibly still open, but as
>> I am not familiar with the Windows port at a
On 11/08/2016 01:22 PM, Michael Banck wrote:
Thanks! I couldn't find furhter faults in my testing. I guess the
question what to do about this on Windows is possibly still open, but as
I am not familiar with the Windows port at all I've marked it Ready for
Committer for now.
Thanks again for the
On Tue, Nov 8, 2016 at 9:22 PM, Michael Banck wrote:
> Thanks! I couldn't find furhter faults in my testing. I guess the
> question what to do about this on Windows is possibly still open, but as
> I am not familiar with the Windows port at all I've marked it Ready for
> Committer for now.
The co
Hi,
On Mon, Nov 07, 2016 at 02:36:00AM +0100, Andreas Karlsson wrote:
> Thanks for the review! I have fixed all your feedback in the attached
> patch.
Thanks! I couldn't find furhter faults in my testing. I guess the
question what to do about this on Windows is possibly still open, but as
I am no
Thanks for the review! I have fixed all your feedback in the attached patch.
On 11/03/2016 04:24 PM, Michael Banck wrote:
It does not update the documentation, I think at least section 18.9
"Secure TCP/IP Connections with SSL" needs updating as it says: "The
files server.key, server.crt, root.cr
Hi,
this is a first review of this patch.
As a feature, I think this functionality is very welcome. Having to
schedule a downtime in order to enable SSL or change the SSL certificate
is a nuisance and it might make admins think twice, reducing security.
The patch applies cleanly (modulo fuzz in
I have attached a version of the patch rebased on top of the OpenSSL 1.1
changes.
Andreas
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index 668f217..a1b582f 100644
--- a/src/backend/libpq/be-secure-openssl.c
+++ b/src/backend/libpq/be-secure-openss
On Wed, 7 Sep 2016 17:09:17 +0900
Michael Paquier wrote:
> On Sun, Sep 4, 2016 at 11:39 PM, Andreas Karlsson
> wrote:
> > 1) Serialize the certificates, key, and CRL and write them to the
> > backend_var temp file and then deserialize everything in the
> > backends.
> >
> > Sounds like you would
On Sun, Sep 4, 2016 at 11:39 PM, Andreas Karlsson wrote:
> 1) Serialize the certificates, key, and CRL and write them to the
> backend_var temp file and then deserialize everything in the backends.
>
> Sounds like you would need to write some code for every SSL library to
> support the serializati
On 08/31/2016 11:34 PM, Peter Geoghegan wrote:
On Sun, Nov 22, 2015 at 7:29 PM, Andreas Karlsson wrote:
Sorry for dropping this patch, but now I have started looking at it again.
Any chance of picking this up again soon, Andreas? I think it's an
important project. I would like to review it.
On Sun, Nov 22, 2015 at 7:29 PM, Andreas Karlsson wrote:
> Sorry for dropping this patch, but now I have started looking at it again.
Any chance of picking this up again soon, Andreas? I think it's an
important project. I would like to review it.
--
Peter Geoghegan
--
Sent via pgsql-hackers
On Mon, Nov 23, 2015 at 12:29 PM, Andreas Karlsson wrote:
> On 08/26/2015 07:46 AM, Michael Paquier wrote:
>>
>> On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier
>> wrote:
>>>
>>> On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote:
[...]
So I think the way to move this forward is t
On 08/26/2015 07:46 AM, Michael Paquier wrote:
On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier
wrote:
On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote:
[...]
So I think the way to move this forward is to investigate how to hold
the SSL config constant until SIGHUP in an EXEC_BACKEND build.
On 2015-08-27 01:12:54 +0200, Andreas Karlsson wrote:
> I think this is a real concern and one that I will look into, to see if it
> can be fixed with a reasonable amount of work.
This patch has been in waiting-for-author for a month. Marking it as
returned-with-feedback.
Greetings,
Andres Freun
On 08/26/2015 03:57 AM, Tom Lane wrote:
Is it unreasonable of me to ask for the Windows behavior to be fixed at
the same time? I dunno. It's perhaps less broken than the Unix behavior,
but that doesn't make it desirable. OTOH it might be a significantly
larger patch, and I confess I'm not even
On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier
wrote:
> On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote:
>> [...]
>> So I think the way to move this forward is to investigate how to hold
>> the SSL config constant until SIGHUP in an EXEC_BACKEND build. If we
>> find out that that's unreasona
On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote:
> [...]
> So I think the way to move this forward is to investigate how to hold
> the SSL config constant until SIGHUP in an EXEC_BACKEND build. If we
> find out that that's unreasonably difficult, maybe we'll decide that
> we can live without it;
[ moving this discussion back to the patch thread ]
Andreas Karlsson writes:
> On 08/25/2015 09:39 AM, Michael Paquier wrote:
>> -- Reload SSL certificates on SIGHUP: returned with feedback? I think
>> that this patch needs more work to be in a commitable state.
> Maybe I am being dense here, bu
On 07/29/2015 03:24 AM, Tom Lane wrote:
Peter Eisentraut writes:
I don't have a problem with rebuilding the SSL context on every reload
cycle. We already do a lot of extra reloading every time, so a bit more
shouldn't hurt. But I'm not so sure whether we should do that in the
SIGHUP handler.
On Wed, Jul 29, 2015 at 10:24 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> I don't have a problem with rebuilding the SSL context on every reload
>> cycle. We already do a lot of extra reloading every time, so a bit more
>> shouldn't hurt. But I'm not so sure whether we should do that in t
On 07/23/2015 07:19 AM, Michael Paquier wrote:
On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson wrote:
On 07/02/2015 06:13 PM, Peter Eisentraut wrote:
I think this would be a useful feature, and the implementation looks
sound. But I don't like how the reload is organized. Reinitializing
Peter Eisentraut writes:
> I don't have a problem with rebuilding the SSL context on every reload
> cycle. We already do a lot of extra reloading every time, so a bit more
> shouldn't hurt. But I'm not so sure whether we should do that in the
> SIGHUP handler. I don't know how we got into the s
On 7/21/15 8:52 PM, Andreas Karlsson wrote:
> It is not enough to just add a hook to the GUCs since I would guess most
> users would expect the certificate to be reloaded if just the file has
> been replaced and no GUC was changed. To support this we would need to
> also check the mtimes of the SSL
On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson wrote:
> On 07/02/2015 06:13 PM, Peter Eisentraut wrote:
>>
>> I think this would be a useful feature, and the implementation looks
>> sound. But I don't like how the reload is organized. Reinitializing
>> the context in the sighup handler, aside
On 07/02/2015 06:13 PM, Peter Eisentraut wrote:
I think this would be a useful feature, and the implementation looks
sound. But I don't like how the reload is organized. Reinitializing
the context in the sighup handler, aside from questions about how much
work one should do in a signal handler,
On 5/30/15 10:14 PM, Andreas Karlsson wrote:
> I have written a patch which makes it possible to change SSL
> certificates (and other SSL parameters, including the CRL) without
> restarting PostgreSQL. In fact this patch also makes it possible to turn
> on or off ssl entirely without restart. It do
Hi,
I have written a patch which makes it possible to change SSL
certificates (and other SSL parameters, including the CRL) without
restarting PostgreSQL. In fact this patch also makes it possible to turn
on or off ssl entirely without restart. It does so by initializing a new
SSL context whe
69 matches
Mail list logo
