Please convert to use the system's crypto policy for SSL and TLS: https://fedoraproject.org/wiki/Packaging:CryptoPolicies If this program is compiled against gnutls, change the default priority string to be "@SYSTEM" or to use gnutls_set_default_priority(). If this program is compiled against openssl, and there is no default cipher list specified, you don't need to modify it. Otherwise replace the default cipher list with "PROFILE=SYSTEM". In both cases please verify that the application uses the system's crypto policies. If the package is already using the system-wide crypto policies, or it does not use SSL or TLS, no action is required, the bug can simply be closed.
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
It appears this bug was missed in the EOL closure for F28 on 2019-05-28. If this bug still exists on supported versions, please reopen and update the version. If you cannot update the version, please needinfo the assignee.