Peter Eisentraut writes:
> On ons, 2012-02-29 at 14:27 -0500, Tom Lane wrote:
>> Hm? Obviously I misunderstood what changes you were proposing to make,
>> so would you mind spelling it out?
> The details are to be determined, but a possible change would likely be
> that instead of looking for a
On ons, 2012-02-29 at 14:27 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote:
> >> In particular, I observe that we get pushback anytime we break something
> >> in a way that makes SSL config files be required on the client side;
> >> see bug
Peter Eisentraut writes:
> On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote:
>> In particular, I observe that we get pushback anytime we break something
>> in a way that makes SSL config files be required on the client side;
>> see bug #6302 for most recent example.
> *If* we were to make a chan
On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote:
> In particular, I observe that we get pushback anytime we break something
> in a way that makes SSL config files be required on the client side;
> see bug #6302 for most recent example.
*If* we were to make a change in libpq analogous to the serv
Peter Eisentraut writes:
> On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote:
>> Yes, ignoring a missing file in a security context is definitely not good.
>> It should throw an error.
>>
>> We have a few bad defaults from the old days around SSL for this, but if it
>> requires breaking ba
On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote:
> > I'm still worried about this. If we ignore a missing root.crt, then the
> > effect is that authentication and certificate verification might fail,
> > which would be annoying, but you'd notice it soon enough. But if we
> > ignore a mis
On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote:
> > My best idea at the moment is that we should set these parameters to
> > empty by default, and make users point them to existing files if they
> > want to use that functionality. Comments?
> >
>
> +1. Anybody who actually cares about s
On Tuesday, February 7, 2012, Peter Eisentraut wrote:
> On tis, 2012-01-24 at 22:05 +0200, Peter Eisentraut wrote:
> > > > One thing that is perhaps worth thinking about: Currently, we just
> > > > ignore missing root.crt and root.crl files. With this patch, we
> still
> > > > do this, even if t
On tis, 2012-01-24 at 22:05 +0200, Peter Eisentraut wrote:
> > > One thing that is perhaps worth thinking about: Currently, we just
> > > ignore missing root.crt and root.crl files. With this patch, we still
> > > do this, even if the user has given a specific nondefault location.
> > > That seem
On tor, 2012-01-19 at 15:44 -0500, Robert Haas wrote:
> On Sat, Jan 14, 2012 at 8:40 AM, Peter Eisentraut wrote:
> > On mån, 2012-01-02 at 06:32 +0200, Peter Eisentraut wrote:
> >> I think I would like to have a set of GUC parameters to control the
> >> location of the server-side SSL files.
> >
>
On Sat, Jan 14, 2012 at 8:40 AM, Peter Eisentraut wrote:
> On mån, 2012-01-02 at 06:32 +0200, Peter Eisentraut wrote:
>> I think I would like to have a set of GUC parameters to control the
>> location of the server-side SSL files.
>
> Here is the patch for this.
>
> One thing that is perhaps worth
On mån, 2012-01-02 at 06:32 +0200, Peter Eisentraut wrote:
> I think I would like to have a set of GUC parameters to control the
> location of the server-side SSL files.
Here is the patch for this.
One thing that is perhaps worth thinking about: Currently, we just
ignore missing root.crt and roo
On Tue, Jan 3, 2012 at 9:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 3, 2012 at 6:25 PM, Peter Eisentraut wrote:
>>> [ reasons ]
>
>> I agree with these reasons. We don't get charged $0.50 per GUC, so
>> there's no particular reason to contort things to have fewer of them.
>
> W
Robert Haas writes:
> On Tue, Jan 3, 2012 at 6:25 PM, Peter Eisentraut wrote:
>> [ reasons ]
> I agree with these reasons. We don't get charged $0.50 per GUC, so
> there's no particular reason to contort things to have fewer of them.
Well, there definitely is a distributed cost to each additio
On Tue, Jan 3, 2012 at 6:25 PM, Peter Eisentraut wrote:
> On mån, 2012-01-02 at 23:42 -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote:
>> >> Were you thinking one option pointing to a directory or one option per
>> >> file?
>>
>> >
On mån, 2012-01-02 at 23:42 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote:
> >> Were you thinking one option pointing to a directory or one option per
> >> file?
>
> > One option per file:
>
> That seems like serious overkill. Why
Peter Eisentraut writes:
> On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote:
>> Were you thinking one option pointing to a directory or one option per
>> file?
> One option per file:
That seems like serious overkill. Why not one option specifying the
directory? What use-case is there
On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote:
> Were you thinking one option pointing to a directory or one option per
> file?
One option per file:
ssl_cert_file
ssl_key_file
ssl_ca_file
ssl_crl_file
This is very similar to the configuration of, for example, Apache,
Dovecot, Postfix,
On Jan 2, 2012 5:33 AM, "Peter Eisentraut" wrote:
>
> I think I would like to have a set of GUC parameters to control the
> location of the server-side SSL files. In a setup that has all the
> other configuration files under /etc, the SSL files ought to go there as
> well. (For comparison, most
19 matches
Mail list logo
