PostgreSQL by default does not store configuration file.  The configuration is
generated by 'initdb' before the server is started (and AFAIK the default
value is 'HIGH:MEDIUM:+3DES:!aNULL').

I'm ok to send patch upstream, but I'm not sure whether this PROFILE=SYSTEM is
Fedora-only feature, it is not described in SSL_CTX_set_cipher_list manual
page.

I don't like the idea of patching the initdb binary downstream-only.

The PROFILE=SYSTEM is Fedora-only. However, having a binary generate configuration is quite alarming. My recommendation would be for the binary to not generate any openssl configuration at all and thus leave the application use the default configuration (which is equivalent to PROFILE=SYSTEM in Fedora).

Alternatively one could introduce an upstream configure or Makefile option to setup the default policy to be generated by the initdb binary. That way we can set it up to output PROFILE=SYSTEM in Fedora.

(In reply to Nikos Mavrogiannopoulos from comment #2)
> The PROFILE=SYSTEM is Fedora-only. However, having a binary generate
> configuration is quite alarming.

Why?  :) I am shocked that the 'PROFILE=SYSTEM' is downstream only (I was
about to starting from which version openssl supports this feature to
discuss automatizing upstraem).

Not having this upstream first (openssl) makes us to fix one-by-one component
downstream (config in most cases, binary in postgresql case) which is
unfortunate.

> My recommendation would be for the binary to not generate any openssl
> configuration at all and thus leave the application use the default
> configuration (which is equivalent to PROFILE=SYSTEM in Fedora).

By default you get _commented_ "default" in your generated configure file,
something like:

  '#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers

But you can change that during 'initdb' run by commandline option option.
This is something really natural for PostgreSQL, and it wouldn't be even wise
to sumbit patches against this architecture.

Pavel

(In reply to Pavel Raiskup from comment #4)
> (In reply to Nikos Mavrogiannopoulos from comment #2)
> > The PROFILE=SYSTEM is Fedora-only. However, having a binary generate
> > configuration is quite alarming.
> 
> Why?  :) I am shocked that the 'PROFILE=SYSTEM' is downstream only (I was
> about to starting from which version openssl supports this feature to
> discuss automatizing upstraem).

OpenSSL upstream doesn't always consider the needs of software distributors like Fedora/Red Hat. In that particular case they decided that this is not an issue they would like to address, at least at this moment.

> Not having this upstream first (openssl) makes us to fix one-by-one component
> downstream (config in most cases, binary in postgresql case) which is
> unfortunate.

Upstreaming in openssl would make no difference in that effort since components will still need to be fixed one by one. In any case, this is how we handle it in all Fedora components (see blocked bug). There is no reason for postgresql to be an exception.

> By default you get _commented_ "default" in your generated configure file,
> something like:
>   '#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
> But you can change that during 'initdb' run by commandline option option.

That seems like an invitation to the administrator to uncomment that option and _not_ use the system-wide policy. If that's the case please make that explicit in the comment. I'd appreciate if you check the suggestion in comment 3, or provide some other solution which integrates better with postgresql.

(In reply to Nikos Mavrogiannopoulos from comment #5)
> (In reply to Pavel Raiskup from comment #4)
> > (In reply to Nikos Mavrogiannopoulos from comment #2)
> > > The PROFILE=SYSTEM is Fedora-only. However, having a binary generate
> > > configuration is quite alarming.
> > 
> > Why?  :) I am shocked that the 'PROFILE=SYSTEM' is downstream only (I was
> > about to starting from which version openssl supports this feature to
> > discuss automatizing upstraem).
> 
> OpenSSL upstream doesn't always consider the needs of software distributors
> like Fedora/Red Hat. In that particular case they decided that this is not
> an issue they would like to address, at least at this moment.

Links?  Maybe it is the right time to reiterate?

> > Not having this upstream first (openssl) makes us to fix one-by-one component
> > downstream (config in most cases, binary in postgresql case) which is
> > unfortunate.
> 
> Upstreaming in openssl would make no difference in that effort since
> components will still need to be fixed one by one. In any case, this is how
> we handle it in all Fedora components (see blocked bug). There is no reason
> for postgresql to be an exception.

It is actually really big difference between (a) backporting a patch which is
already applied upstream and (b) inventing dowstream patch and maintaining it
forever.

> > By default you get _commented_ "default" in your generated configure file,
> > something like:
> >   '#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
> > But you can change that during 'initdb' run by commandline option option.
> 
> That seems like an invitation to the administrator to uncomment that option
> and _not_ use the system-wide policy.

It is invitation to uncomment & edit (when needed).  Playing with ssl defaults
was source of issues before, so I don't see this as the way to go.

> If that's the case please make that explicit in the comment. I'd appreciate
> if you check the suggestion in comment 3, or provide some other solution
> which integrates better with postgresql.

Touching crypto defaults caused issues before, so I don't think there is a
good solution we could do downstream-only.

Why don't we re-iterate the communication with openssl upstream?  Having
system-wide "defaults" configurable - and supported - makes perfect sense
to me.

ATM, if I patched initdb's defaults, people would just end-up staring at
completely undocumented:

"#ssl_ciphers = 'PROFILE=SYSTEM'"

Pavel

(In reply to Pavel Raiskup from comment #6)

> > OpenSSL upstream doesn't always consider the needs of software distributors
> > like Fedora/Red Hat. In that particular case they decided that this is not
> > an issue they would like to address, at least at this moment.
> Links?  Maybe it is the right time to reiterate?
https://github.com/openssl/openssl/pull/192

> > Upstreaming in openssl would make no difference in that effort since
> > components will still need to be fixed one by one. In any case, this is how
> > we handle it in all Fedora components (see blocked bug). There is no reason
> > for postgresql to be an exception.
> It is actually really big difference between (a) backporting a patch which is
> already applied upstream and (b) inventing dowstream patch and maintaining it
> forever.
> > > By default you get _commented_ "default" in your generated configure file,
> > > something like:
> > >   '#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
> > > But you can change that during 'initdb' run by commandline option option.
> > 
> > That seems like an invitation to the administrator to uncomment that option
> > and _not_ use the system-wide policy.
> It is invitation to uncomment & edit (when needed).  Playing with ssl
> defaults was source of issues before, so I don't see this as the way to go.
> > If that's the case please make that explicit in the comment. I'd appreciate
> > if you check the suggestion in comment 3, or provide some other solution
> > which integrates better with postgresql.
> Touching crypto defaults caused issues before, so I don't think there is a
> good solution we could do downstream-only.
> Why don't we re-iterate the communication with openssl upstream?  Having
> system-wide "defaults" configurable - and supported - makes perfect sense
> to me.

This is not what this bug is about. Feel free to help in getting that in openssl upstream, but this bug is about postgresql following the Fedora packaging guidelines.

> ATM, if I patched initdb's defaults, people would just end-up staring at
> completely undocumented:
> "#ssl_ciphers = 'PROFILE=SYSTEM'"

This is in accordance to the guidelines:
https://fedoraproject.org/wiki/Packaging:CryptoPolicies

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

I'm curious why the CryptoPolicies guideline does not point to the actual
defaults, because otherwise it is a grep-work through openssl sources:

  /etc/crypto-policies/back-ends/openssl.config

There's:

  kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!EXP:!DES:!RC4:!RC2:!IDEA\
  :!SEED:!eNULL:!aNULL:!MD5:!SSLv2

Current PostgreSQL backend's default is:

  HIGH:MEDIUM:+3DES:!aNULL

So the new config would be a strict subset of the actual setup.

If I interpret 'openssl ciphers -v -tls1' outputs correctly (on RHEL5 and
on Fedora 25 with the Fedora's PROFILE=SYSTEM limitation), even RHEL 5
client should be able to negotiate cipher with newer server (server picks
the cipher from client's list).  Would RHEL4 client be able to offer
compatible cipher, too?

Working on testing packages:
https://copr.fedorainfracloud.org/coprs/praiskup/postgresql-rhbz1348125/

Upstream proposal for configure-time knob:
https://www.postgresql.org/message-id/1597541.4SyjC8fqHr@nb.usersys.redhat.com

Thank you for pursuing that.

Is there any update on the issue?

The upstream position on this is that this all initiative is just about
single-crypto-lib/single-distro hack, and there's not much I can argue
against such opinion (because I completely agree with upstream).

So, no progress so far -- what remains is the downstream patching of
PostgreSQL -- which I'm wholeheartedly against;  but guidelines are
guidelines :( -- I wish we could delay the guideline till there's some
upstream solution (now fedora security guys have much smaller motivation
to get this upstream fixed).

So, basically -- I'm waiting for bug 1420232.

The upstream mail thread is referenced in comment #12.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Postgres should be affected by crypto policies, and I don't see the relevant dist-git commit