Обсуждение: What happened to SSL_CIPHERS?
Folks, This doc says we ought to have the ssl_ciphers parameter: http://www.postgresql.org/docs/9.0/static/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SECURITY Nor is there anything in the 9.0 release notes about it going away. Yet: postgres=# select version(); version --------------------------------------------------------------------------------------------------------- PostgreSQL 9.0.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3, 64-bit (1 row) postgres=# show ssl_ciphers; ERROR: unrecognized configuration parameter "ssl_ciphers" So, did ssl_ciphers go away on purpose? If so, why? If not, why isn't it accessible? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
On Thu, Oct 28, 2010 at 22:33, Josh Berkus <josh@agliodbs.com> wrote: > Folks, > > This doc says we ought to have the ssl_ciphers parameter: > > http://www.postgresql.org/docs/9.0/static/runtime-config-connection.html#= RUNTIME-CONFIG-CONNECTION-SECURITY > > Nor is there anything in the 9.0 release notes about it going away. > > Yet: > > postgres=3D# select version(); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 version > -------------------------------------------------------------------------= -------------------------------- > =A0PostgreSQL 9.0.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (Ubu= ntu > 4.3.3-5ubuntu4) 4.3.3, 64-bit > (1 row) > > postgres=3D# show ssl_ciphers; > ERROR: =A0unrecognized configuration parameter "ssl_ciphers" > > So, did ssl_ciphers go away on purpose? =A0If so, why? =A0If not, why isn= 't it > accessible? Are you sure you're on an SSL enabled build? --=20 =A0Magnus Hagander =A0Me: http://www.hagander.net/ =A0Work: http://www.redpill-linpro.com/
>> So, did ssl_ciphers go away on purpose? If so, why? If not, why isn't it
>> accessible?
>
> Are you sure you're on an SSL enabled build?
Oh, good call ... I thought I'd installed the SSL build, but apparently not.
Mind you, we *also* need a doc patch. ("This parameter is only available
if PostgreSQL was built with SSL support").
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Fri, Oct 29, 2010 at 10:01, Josh Berkus <josh@agliodbs.com> wrote:
>
>>> So, did ssl_ciphers go away on purpose? =A0If so, why? =A0If not, why i=
sn't
>>> it
>>> accessible?
>>
>> Are you sure you're on an SSL enabled build?
>
> Oh, good call ... I thought I'd installed the SSL build, but apparently n=
ot.
>
> Mind you, we *also* need a doc patch. ("This parameter is only available =
if
> PostgreSQL was built with SSL support").
Actually, I think it'd be more user friendly to make the parameter
still exist and be a no-op (maybe show the value NULL?) on non-SSL
enabled builds. Same goes for all other parameters that depend on a
specific compile flag. That would make life easier on automated tools
*and* on people sitting down at a new installation.
Thoughts?
--=20
=A0Magnus Hagander
=A0Me: http://www.hagander.net/
=A0Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Fri, Oct 29, 2010 at 10:01, Josh Berkus <josh@agliodbs.com> wrote:
>> Mind you, we *also* need a doc patch. ("This parameter is only available if
>> PostgreSQL was built with SSL support").
> Actually, I think it'd be more user friendly to make the parameter
> still exist and be a no-op (maybe show the value NULL?) on non-SSL
> enabled builds. Same goes for all other parameters that depend on a
> specific compile flag. That would make life easier on automated tools
> *and* on people sitting down at a new installation.
Yeah, we're a bit schizophrenic about this. Some parameters still
exist, but can't be set to any value but "disabled", when the relevant
feature wasn't compiled. Others just aren't there.
It takes code space and work to make a parameter be present but behave
differently if disabled. I don't think that we should institute a
blanket policy of requiring that to happen; in particular, there are a
number of debug-type parameters for which I argue that it's not worth
the trouble. But for user-facing parameters I agree we should do it,
and ssl_ciphers is one of those.
In any case, a doc patch would be the right thing for the back branches.
regards, tom lane
On Fri, Oct 29, 2010 at 1:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >=A0But for user-facing parameters I agree we should do it, > and ssl_ciphers is one of those. +1. > In any case, a doc patch would be the right thing for the back branches. +1. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Oct 29, 2010 at 19:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Fri, Oct 29, 2010 at 10:01, Josh Berkus <josh@agliodbs.com> wrote:
>>> Mind you, we *also* need a doc patch. ("This parameter is only available if
>>> PostgreSQL was built with SSL support").
>
>> Actually, I think it'd be more user friendly to make the parameter
>> still exist and be a no-op (maybe show the value NULL?) on non-SSL
>> enabled builds. Same goes for all other parameters that depend on a
>> specific compile flag. That would make life easier on automated tools
>> *and* on people sitting down at a new installation.
>
> Yeah, we're a bit schizophrenic about this. Some parameters still
> exist, but can't be set to any value but "disabled", when the relevant
> feature wasn't compiled. Others just aren't there.
>
> It takes code space and work to make a parameter be present but behave
> differently if disabled. I don't think that we should institute a
> blanket policy of requiring that to happen; in particular, there are a
> number of debug-type parameters for which I argue that it's not worth
> the trouble. But for user-facing parameters I agree we should do it,
> and ssl_ciphers is one of those.
Here's a patch that does this for HEAD. AFAICT, only ssl_ciphers and
the syslog parameters are actually "user facing parameters" - all the
other ifdef'ed out ones are debug-style parameters.
> In any case, a doc patch would be the right thing for the back branches.
I can look at this too (yes, I know we just wrapped, but I'm working
down the backlog :S). You mean something as simple as "this parameter
is unavailable if the server was not compiled with support for SSL"?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Вложения
On 12/15/10 4:58 AM, Magnus Hagander wrote:
>> > In any case, a doc patch would be the right thing for the back branches.
>
> I can look at this too (yes, I know we just wrapped, but I'm working
> down the backlog :S). You mean something as simple as "this parameter
> is unavailable if the server was not compiled with support for SSL"?
Exactly. If you don't get around to it, bug me in January.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Thu, Dec 16, 2010 at 02:25, Josh Berkus <josh@agliodbs.com> wrote: > On 12/15/10 4:58 AM, Magnus Hagander wrote: >>> > In any case, a doc patch would be the right thing for the back branch= es. >> >> I can look at this too (yes, I know we just wrapped, but I'm working >> down the backlog :S). You mean something as simple as "this parameter >> is unavailable if the server was not compiled with support for SSL"? > > Exactly. =A0If you don't get around to it, bug me in January. Done, and applied (doc patch for back branches, code patch for HEAD) --=20 =A0Magnus Hagander =A0Me: http://www.hagander.net/ =A0Work: http://www.redpill-linpro.com/