Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1288743 - This is a tracking bug for letsencrypt in EPEL7
Summary: This is a tracking bug for letsencrypt in EPEL7
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: letsencrypt
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: James Hogarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1288746 (view as bug list)
Depends On: 998679 1279261 1288221 1288487 1288688 1289345 1289348 1291573 1332519
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-05 18:59 UTC by James Hogarth
Modified: 2016-05-03 11:38 UTC (History)
9 users (show)

Fixed In Version: letsencrypt-0.2.0-3.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-25 01:29:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description James Hogarth 2015-12-05 18:59:51 UTC
This is a bug to track the dependencies needed to get letsencrypt into EPEL7

Comment 1 James Hogarth 2015-12-05 19:12:10 UTC
*** Bug 1288746 has been marked as a duplicate of this bug. ***

Comment 2 Robert Buchholz 2015-12-07 21:47:17 UTC
Besides all the packages currently blocking this bug, we'll need the following additional packages for either letencrypt or python-acme in EPEL7

- python-sphinxcontrib-programoutput, currently has no epel7 branch
- python-pyrfc3339
- python-dialog, already approved for epel, but no build. See bug 998679 and bug 1288356
- pyOpenSSL:
    package is in EL7 (0.13.1)
    acme (claims it) needs >= 0.15
    RH maintainer denied upgrading to 0.14 or later in bug 1227505


In addition, python-six is needed from RHEL 7.2 which currently requires CentOS's CR repository.

I would like to see the security issue in python-cryptography in RHEL fixed before we start using letencrypt with that, bug 1267548.

Comment 3 James Hogarth 2015-12-08 08:51:39 UTC
(In reply to Robert Buchholz from comment #2)
> Besides all the packages currently blocking this bug, we'll need the
> following additional packages for either letencrypt or python-acme in EPEL7
> 
> - python-sphinxcontrib-programoutput, currently has no epel7 branch

I'm happy to change the way docs are currently handled and carry a patch (to submit back upstream) with a decent man page and not the poor thing that is just the output of --help all ...

We can potentially drop this if it becomes troublesome.

> - python-pyrfc3339

I hear the maintainer of this is a real pain to work with ... ;)

> - python-dialog, already approved for epel, but no build. See bug 998679 and

That's fairly easy to poke someone or just take over if need be

> bug 1288356
> - pyOpenSSL:
>     package is in EL7 (0.13.1)
>     acme (claims it) needs >= 0.15
>     RH maintainer denied upgrading to 0.14 or later in bug 1227505
> 

This could be a pain. Let's just build against the existing pyOpenSSL and see what breaks (or even if it just works!) ...

If it doesn't work with the version in base we'll need to look at the letsencrypt code and work out a way of accomplishing the same thing against the version in the repos.

Once that's sorted we can initially carry a maintainer patch to get this going and submit a pull request upstream. SO far my interaction with upstream has been positive so I don't expect to see much difficulty in such a patch lowering the pyOpenSSL requirements as being troublesome to push back up.


> 
> In addition, python-six is needed from RHEL 7.2 which currently requires
> CentOS's CR repository.
> 

The main release is any day now, certainly before we get this out so it's not a problem.

> I would like to see the security issue in python-cryptography in RHEL fixed
> before we start using letencrypt with that, bug 1267548.

Have you verified the actual issue still exists in the version released in RHEL? Since it's a base package now they tend to backport and fix up things like that there ... worth grabbing the changelog from the equivalent centos package and taking a look.

Comment 4 Nick 2015-12-08 13:02:16 UTC
If we could work out a way to drop the dependency for sphinx etc for docs then that would save a lot of work in the long run. A simple man page would be much more useful IMHO.

Comment 5 Robert Buchholz 2015-12-10 19:45:36 UTC
Regarding the man page, I actually like the man page generated from the verbose documentation and realized we don't actually package that. I've to head out right now, but I'll push a patch later that also packages that man: http://pastebin.centos.org/37046/

Regarding pyOpenSSL, the 0.13 version won't do as a dep for python-acme. While documentation only lists one of the >= 0.15 functions in use, it actually uses several internal (!) and public APIs of pyOpenSSL. I've tried building with the 0.13, but about 5% of unit tests fail (for different reasons).

I think the safest route would be to introduce 0.15 as a new package that blocks pyOpenSSL 0.13, but I'll need to check the reverse dependencies to avoid that rendering the system unusable.

Comment 6 James Hogarth 2015-12-10 20:03:32 UTC
(In reply to Robert Buchholz from comment #5)
> Regarding the man page, I actually like the man page generated from the
> verbose documentation and realized we don't actually package that. I've to
> head out right now, but I'll push a patch later that also packages that man:
> http://pastebin.centos.org/37046/
> 

The current Fedora package does. Note that the pastebin can't be used as is since it refers to letsencrypt-auto ... I corrected that in the current Fedora spec.

> Regarding pyOpenSSL, the 0.13 version won't do as a dep for python-acme.
> While documentation only lists one of the >= 0.15 functions in use, it
> actually uses several internal (!) and public APIs of pyOpenSSL. I've tried
> building with the 0.13, but about 5% of unit tests fail (for different
> reasons).
> 
> I think the safest route would be to introduce 0.15 as a new package that
> blocks pyOpenSSL 0.13, but I'll need to check the reverse dependencies to
> avoid that rendering the system unusable.

We can't put a newer pyOpenSSL into EPEL if out already exists in RHEL. This is a strict policy matter which we can't bypass.

If that is the case we need to provide patches to remove this dependency and, ideally, submit and have it included upstream.

If we can't do this then it's likely this package is not going to be viable for inclusion in EPEL after all.

Comment 7 Robert Buchholz 2015-12-10 22:16:09 UTC
(In reply to James Hogarth from comment #6)
> The current Fedora package does. Note that the pastebin can't be used as is
> since it refers to letsencrypt-auto ... I corrected that in the current
> Fedora spec.

Ah, yes the "auto" documentation. But the "webroot" docs are rather good. Any idea how we could build conditional parts of the docs? Probably easiest to patch/remove the parts we're not building and then provide the lentencrypt(7)?

> We can't put a newer pyOpenSSL into EPEL if out already exists in RHEL. This
> is a strict policy matter which we can't bypass.

Oh, I forgot again my own comment above. Does that policy even forbid a "pyOpenSSL015" package that conflicts with the RHEL-provided pyOpenSSL?

> If that is the case we need to provide patches to remove this dependency
> and, ideally, submit and have it included upstream.

Oh pains.

> If we can't do this then it's likely this package is not going to be viable
> for inclusion in EPEL after all.

The same goes for the EPEL6 inclusion where pyOpenSSL-0.13.1-2.el6.x86_64 is in the EL tree.

Comment 8 James Hogarth 2015-12-11 01:05:58 UTC
(In reply to Robert Buchholz from comment #7)
> (In reply to James Hogarth from comment #6)
> > The current Fedora package does. Note that the pastebin can't be used as is
> > since it refers to letsencrypt-auto ... I corrected that in the current
> > Fedora spec.
> 
> Ah, yes the "auto" documentation. But the "webroot" docs are rather good.
> Any idea how we could build conditional parts of the docs? Probably easiest
> to patch/remove the parts we're not building and then provide the
> lentencrypt(7)?
> 

I think better generation overall would benefit everybody. Let's work out a way of making upstream happy for improved docs being generated in an easier manner.

> > We can't put a newer pyOpenSSL into EPEL if out already exists in RHEL. This
> > is a strict policy matter which we can't bypass.
> 
> Oh, I forgot again my own comment above. Does that policy even forbid a
> "pyOpenSSL015" package that conflicts with the RHEL-provided pyOpenSSL?
> 
> > If that is the case we need to provide patches to remove this dependency
> > and, ideally, submit and have it included upstream.
> 
> Oh pains.
> 
> > If we can't do this then it's likely this package is not going to be viable
> > for inclusion in EPEL after all.
> 
> The same goes for the EPEL6 inclusion where pyOpenSSL-0.13.1-2.el6.x86_64 is
> in the EL tree.

Good news on this front!

https://github.com/letsencrypt/letsencrypt/issues/1861

One of the devs there looked into this for us and doesn't see why they can't drop this to 0.13+ ... especially since this easies Debian 7 support for them as well.

Hopefully this isn't too tricky and they can make their 0.1.1 milestone reasonably swiftly.

Comment 9 Didier 2016-01-15 11:51:23 UTC
https://community.letsencrypt.org/t/client-version-0-2-0-released/8886 :

"Relaxed PyOpenSSL version requirements. This adds support for systems
with PyOpenSSL versions 0.13 or 0.14."

Comment 10 Peter Eckersley 2016-01-19 22:35:15 UTC
The relaxed PyOpenSSL dependency was included in our upstream 0.2.0 release.  Please let us know if there's anything else we can do to facilitate EPEL7 backporting.

Comment 11 Nick 2016-01-22 02:36:55 UTC
Thanks Peter. Just an issue with sphinx to resolve and then we can push this package.

Comment 12 Fedora Update System 2016-01-22 15:59:30 UTC
letsencrypt-0.2.0-1.el7 python-acme-0.2.0-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4826773e90

Comment 13 Nick Bebout 2016-01-22 16:17:12 UTC
I have went ahead and pushed a version to EPEL7 that has docs disabled, although I'd like to get the docs built eventually.

Comment 14 Fedora Update System 2016-01-24 04:23:06 UTC
letsencrypt-0.2.0-3.el7, python-acme-0.2.0-1.el7, python-configargparse-0.10.0-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4826773e90

Comment 15 Fedora Update System 2016-01-25 01:29:46 UTC
letsencrypt-0.2.0-3.el7, python-acme-0.2.0-1.el7, python-configargparse-0.10.0-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.