Hey folks,
I'd like to propose that we build a newer version of pyOpenSSL for EL7. The version provided by base RHEL is 0.13.1. We need at least 16.1.0.
The motivation for this proposal is that at the moment, fedmsg has two implementations of message signing and verification. The first is based on M2Crypto and m2ext, while the second is based on cryptography and pyOpenSSL.
The reason there are two implementations is that M2Crypto does not support Python 3. Python 2 reaches end of life in 30 months. fedmsg is a dependency of nearly every Infrastructure application and thus it supporting Python 3 is critical so that we can start the process of supporting Python 3 in our applications.
In order to provide a Python 3 build of fedmsg for EL7, we need to build a newer pyOpenSSL. I reviewed the changelogs[0][1] and from what I can tell APIs were only extended until pyOpenSSL-17.1.0, at which point several backwards-incompatible changes were made. I believe we could safely update to 17.0.0 without breaking applications that depend on it.
I've made a small list of pros and cons to doing this:
Cons ----
* Building a package provided by RHEL's base repository.
* Some risk of breaking applications and libraries using pyOpenSSL.
* We have to maintain it and keep an eye open for any CVEs.
* Even if we do this, fedmsg has to continue to carry the M2Crypto code unless we want to stop updating fedmsg in EPEL (I'm open to this, but I'm biased - I really don't want to maintain M2Crypto code).
Pros ----
* Applications have an easier time porting to Python 3. New applications can seriously consider being Python 3 only.
* A single code path for signing and validating messages for our applications.
What do people think? Is it worth the headache/risk?
[0] https://github.com/pyca/pyopenssl/blob/master/doc/ChangeLog_old.txt#L188 [1] https://pyopenssl.org/en/stable/changelog.html
On 09/19/2017 08:22 AM, Jeremy Cline wrote:
Hey folks,
I'd like to propose that we build a newer version of pyOpenSSL for EL7. The version provided by base RHEL is 0.13.1. We need at least 16.1.0.
The motivation for this proposal is that at the moment, fedmsg has two implementations of message signing and verification. The first is based on M2Crypto and m2ext, while the second is based on cryptography and pyOpenSSL.
The reason there are two implementations is that M2Crypto does not support Python 3. Python 2 reaches end of life in 30 months. fedmsg is a dependency of nearly every Infrastructure application and thus it supporting Python 3 is critical so that we can start the process of supporting Python 3 in our applications.
In order to provide a Python 3 build of fedmsg for EL7, we need to build a newer pyOpenSSL. I reviewed the changelogs[0][1] and from what I can tell APIs were only extended until pyOpenSSL-17.1.0, at which point several backwards-incompatible changes were made. I believe we could safely update to 17.0.0 without breaking applications that depend on it.
I've made a small list of pros and cons to doing this:
...snip...
What do people think? Is it worth the headache/risk?
Could we build the new pyOpenSSL/cryptography for epel7, but as python3 only? (so it doesn't override the base rhel one)?
I suppose that would force a massive amount of upfront porting to python3 that would be difficult?
I guess I'd be ok doing this (we are kind of in a bad place, so none of the choices are great), but we should get at least 3-4 of us to watch commits on the fedora pyOpenSSL and cryptography to make sure we see issues/bugs/updates as they happen?
kevin
On 09/20/2017 01:33 PM, Kevin Fenzi wrote:
Could we build the new pyOpenSSL/cryptography for epel7, but as python3 only? (so it doesn't override the base rhel one)?
We could do that. The only downsides I can really think of is it's surprising to have different versions of the same library on Python 2 vs Python 3, but since this is in our own repository I don't think that's a big deal.
I guess I'd be ok doing this (we are kind of in a bad place, so none of the choices are great), but we should get at least 3-4 of us to watch commits on the fedora pyOpenSSL and cryptography to make sure we see issues/bugs/updates as they happen?
Definitely, although fortunately pyOpenSSL is in maintenance mode and should be reasonably quiet. I'm a maintainer on the Fedora pyOpenSSL and cryptography, so as long as a couple more people keep an eye on them we should be set.
On 09/25/2017 07:12 AM, Jeremy Cline wrote:
On 09/20/2017 01:33 PM, Kevin Fenzi wrote:
Could we build the new pyOpenSSL/cryptography for epel7, but as python3 only? (so it doesn't override the base rhel one)?
We could do that. The only downsides I can really think of is it's surprising to have different versions of the same library on Python 2 vs Python 3, but since this is in our own repository I don't think that's a big deal.
Yeah, I think some people are already doing it, but I could see how it might be confusing...
Also, the number of people using python3 on epel is I suspect very low.
I guess I'd be ok doing this (we are kind of in a bad place, so none of the choices are great), but we should get at least 3-4 of us to watch commits on the fedora pyOpenSSL and cryptography to make sure we see issues/bugs/updates as they happen?
Definitely, although fortunately pyOpenSSL is in maintenance mode and should be reasonably quiet. I'm a maintainer on the Fedora pyOpenSSL and cryptography, so as long as a couple more people keep an eye on them we should be set.
Cool.
kevin
On 09/25/2017 10:12 AM, Jeremy Cline wrote:
On 09/20/2017 01:33 PM, Kevin Fenzi wrote:
Could we build the new pyOpenSSL/cryptography for epel7, but as python3 only? (so it doesn't override the base rhel one)?
We could do that. The only downsides I can really think of is it's surprising to have different versions of the same library on Python 2 vs Python 3, but since this is in our own repository I don't think that's a big deal.
I did think of an upside, which is that the m2crypto version of the validation code doesn't check that the CRL is signed by our CA, nor does it consider the expiration date, _and_ it rolls its own serial number lookup code[0].
All those issues would be addressed with an updated version of pyOpenSSL.
[0] https://github.com/fedora-infra/fedmsg/blob/73425a97c2cf0ae2188f0964988f0232...
infrastructure@lists.fedoraproject.org
-
Jeremy Cline -
Kevin Fenzi