10:22 a.m.
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
--
Jeremy Cline
XMPP: jeremy(a)jcline.org
IRC: jcline
12:33 p.m.
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
9:12 a.m.
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.
--
Jeremy Cline
XMPP: jeremy(a)jcline.org
IRC: jcline
1:19 p.m.
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
2:37 p.m.
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/73425a97c2cf0ae2188f0964988f0...
--
Jeremy Cline
XMPP: jeremy(a)jcline.org
IRC: jcline
2394
days inactive
2404
days old
infrastructure@lists.fedoraproject.org
4 comments
2 participants
participants (2)
-
Jeremy Cline -
Kevin Fenzi