Bug 1272243

Ad 1. I think the answer is "YES". For once m2crypto is IMHO (via SWIG, etc.) de facto C application, which certainly sets SSL_CTX_set_cipher_list.

Also, concerning libraries, I think the argument can go exactly in the opposite direction; not only libraries should not be exempted, but even more they should be even more strict, because many Python programs run

ctx = SSL.Context()

expecting getting something secure.

Actually, I have strong feelings about weak_crypto itself. Do we have some strong reasons to have this at all? In case somebody is suicidal she can always use SSL.set* methods later on her new context. I am not sure why we should help it. I can see https://gitlab.com/m2crypto/m2crypto/commit/94ba38c0a6 but it doesn’t contain any persuasive reason for the existence of the parameter.

2. So, yes, I believe we should put "PROFILE=SYSTEM" to the default self.set_cipher_list().

3. Not sure what’s the situation with this upstream. Do these profiles exist upstream at all? Do all operation systems support it? What happens on Windows, Mac OS X, other Unices?

(In reply to Matěj Cepl from comment #1)
> Ad 1. I think the answer is "YES". For once m2crypto is IMHO (via SWIG,
> etc.) de facto C application, which certainly sets SSL_CTX_set_cipher_list.
[...]
> 3. Not sure what’s the situation with this upstream. Do these profiles exist
> upstream at all? Do all operation systems support it? What happens on
> Windows, Mac OS X, other Unices?

The crypto policies is a Fedora feature and there is no meaning pushing that string upstream. You should notify upstream of insecure default settings though.
This particular string seems to allow anonymous ECDH which is susceptible to man-in-the-middle attacks.

(In reply to Matěj Cepl from comment #1)
> Ad 1. I think the answer is "YES". For once m2crypto is IMHO (via SWIG,
> etc.) de facto C application, which certainly sets SSL_CTX_set_cipher_list.
> 
> Also, concerning libraries, I think the argument can go exactly in the
> opposite direction; not only libraries should not be exempted, but even more
> they should be even more strict, because many Python programs run
> 
> ctx = SSL.Context()
> 
> expecting getting something secure.

I don’t know; I could reasonably see a case for “we will not be changing library APIs, but instead patch every end-user application”. Nikos?

> Actually, I have strong feelings about weak_crypto itself. Do we have some
> strong reasons to have this at all? In case somebody is suicidal she can
> always use SSL.set* methods later on her new context. I am not sure why we
> should help it. I can see
> https://gitlab.com/m2crypto/m2crypto/commit/94ba38c0a6 but it doesn’t
> contain any persuasive reason for the existence of the parameter.

There might not be a good reason for adding something like that (though M2Crypto never seemed too sure whether it is just an OpenSSL binding or a layer which makes OpenSSL easier to use — see M2Crypto.SSL.Checker); that’s different from a reason for removing it and breaking the API now that it exists..

(In reply to Miloslav Trmač from comment #3)
> (In reply to Matěj Cepl from comment #1)
> > Ad 1. I think the answer is "YES". For once m2crypto is IMHO (via SWIG,
> > etc.) de facto C application, which certainly sets SSL_CTX_set_cipher_list.
> > 
> > Also, concerning libraries, I think the argument can go exactly in the
> > opposite direction; not only libraries should not be exempted, but even more
> > they should be even more strict, because many Python programs run
> > 
> > ctx = SSL.Context()
> > 
> > expecting getting something secure.
> 
> I don’t know; I could reasonably see a case for “we will not be changing
> library APIs, but instead patch every end-user application”. Nikos?

There is no requirement to change APIs to enforce crypto policies. There is nothing preventing the enhancement of APIs to better accommodate system defaults, or some default string applicable to many applications.

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

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. 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 '24'.

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 24 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.

(In reply to Nikos Mavrogiannopoulos from comment #5)
> There is no requirement to change APIs to enforce crypto policies. There is
> nothing preventing the enhancement of APIs to better accommodate system
> defaults, or some default string applicable to many applications.

Nikos, could you elaborate here, please, what you mean?

(In reply to Matěj Cepl from comment #8)
> (In reply to Nikos Mavrogiannopoulos from comment #5)
> > There is no requirement to change APIs to enforce crypto policies. There is
> > nothing preventing the enhancement of APIs to better accommodate system
> > defaults, or some default string applicable to many applications.
> 
> Nikos, could you elaborate here, please, what you mean?

It is a generic statement, not a particular suggestion as I am unaware of the m2crypto apis. If you know the package's APIs you are in better position to figure out what to update than me.

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

Sometime in the meantime, the self.set_cipher_list call was removed; there is only 

>         if weak_crypto is None and protocol in ('sslv23', 'tls'):
>            self.set_options(m2.SSL_OP_ALL | m2.SSL_OP_NO_SSLv2 |
>                             m2.SSL_OP_NO_SSLv3)
(with the condition usually true).

So perhaps we are now fine?

Yes, that should be OK.

This has been changed in the commit c295b5bc from Wed Jul 27 15:32:00 2016 +0200                which was first released in 0.26.0.

Could we get 0.28.2 in F27 as well? I would love to have some users (I have my doubts about number of people using Rawhide), plus this could be also fixed.

(In reply to Matěj Cepl from comment #13)
> This has been changed in the commit c295b5bc from Wed Jul 27 15:32:00 2016
> +0200                which was first released in 0.26.0.

That changes the set_options call, but the set_cipher_list call has actually been removed in 0.25.0 already AFAICT; and that is available in F25 and all later releases.  Hence, closing as CURRENTRELEASE.  Thanks!

(In reply to Matěj Cepl from comment #14)
> Could we get 0.28.2 in F27 as well? I would love to have some users (I have
> my doubts about number of people using Rawhide), plus this could be also
> fixed.

There are various ABI changes, e.g. dropping the PGP subpackage, which seem unsuitable for a stable release, at least in principle (I don’t have a strong opinion on whether someone will notice in practice, but that’s a difficult line to walk).  At least this particular issue doesn’t need the rebase AFAICS.