Created attachment 161470 [details] shar-v1 builds on 11a, 10.2i+a, 9.3, needs py-acme.
shar mostly from cpm@fbsd.es.
@kuba pointed me the right direction. https://github.com/letsencrypt/letsencrypt/issues/792#issuecomment-143864388
Kurt, I tested the letsencrypt port :) It works fine with the recently added py-acme dependency, but it shows the following message "Configurator could not be determined" Any thoughts?
(In reply to Carlos J Puga Medina from comment #3) In the WRKSRC, there are drwxrwxr-x 3 root wheel 5 Sep 18 07:26 letsencrypt-apache drwxrwxr-x 3 root wheel 5 Sep 18 07:26 letsencrypt-compatibility-test drwxrwxr-x 4 root wheel 6 Sep 18 07:26 letsencrypt-nginx and we probably need to install those as well ? Do we have to do those as seperate ports, similar to py-acme ?
(In reply to Kurt Jaeger from comment #4) Yes. Those ports are necessary as well.
Once created the 3 pending ports, we just have to add them in the Makefile. E.g. using these categories www/letsencrypt-apache security/letsencrypt-compatibility-test www/letsencrypt-nginx Per documentation are only necessary letsencrypt-apache and letsencrypy-nginx https://github.com/letsencrypt/letsencrypt/blob/master/readthedocs.org.requirements.txt
Hey, Let's Encrypt dev here :) Generally, https://github.com/letsencrypt/letsencrypt/blob/master/readthedocs.org.requirements.txt is not the source of truth, and in fact it should be updated to include more packages. Things that should be packaged: - acme - letsencrypt - letsencrypt-apache (should require Apache2 server) - letsencrypt-nginx (should require Nginx server) - letshelp-letsencrypt (this allows end-users to send debug data to the dev team) letsencrypt-compatibility-test is only useful for the devs and it shouldn't be packaged for end users. Lovely to see packaging efforts in FreeBSD! Let me know if you need any help.
(In reply to Jakub Warmuz from comment #7) Hi Jakub, We are working now to have a complete letsencrypt port. Hope you can help us to solve any question related. Only the letsencrypt port has been landed.
A commit references this bug: Author: pi Date: Tue Oct 13 19:12:18 UTC 2015 New revision: 399211 URL: https://svnweb.freebsd.org/changeset/ports/399211 Log: security/py-acme: 0.0.b1 -> 0.0.0.dev20151008 Changes: For now, see https://github.com/letsencrypt/letsencrypt/commits/master PR: 203405 Changes: head/security/py-acme/Makefile head/security/py-acme/distinfo
Created attachment 161995 [details] shar-v2 update for letsencrypt itself
Created attachment 161996 [details] apache letsencrypt-apache
Created attachment 161997 [details] nginx nginx
Created attachment 161998 [details] letshelp letshelp-letsencrypt
If someone wants to use le, le-<webserver> has to be installed. It installs the dependency le itself, and the <webserver>, and that's it ? Now, we need more tests on this. I'm sure it will not use the right path to the config files right now.
even worse, the version string causes errors like this: pkg_resources.DistributionNotFound: The 'acme==0.0.0.dev20151008' distribution was not found and is required by letsencrypt
upstream issue: https://github.com/letsencrypt/letsencrypt/issues/972
Even though cryptography 0.8.2 is listed as the minimal version needed to run letsencrypt, this version does not support DER encoded certificates. DER support was added in version 0.9. Therefore I just submitted PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203819 to update py-cryptography to 1.0.2 (which is the latest available version)
Ralf, nice finding, thanks! I've filed https://github.com/letsencrypt/letsencrypt/issues/1012 upstream.
Created attachment 162220 [details] shar-v3 New release available: https://github.com/letsencrypt/letsencrypt/releases
If we want the quarterly pkg users (FreeBSD 10.1+ by default) to have this when it lands we will need to MFH these new ports and the security/py-acme update, correct?
@Kurt I have the python client port sorted (security/py-letsencrypt) and ready to land (requires a py-acme update to match versions) Hit me up on IRC so we can all get on the same page
(In reply to Kurt Jaeger from comment #15) First, py-acme needs to use DISTVERSION (the current PORTVERSION is illegal) Second, our *_DEPENDS package version matching routines don't detect that x.y.z.d<datestamp > <someversionstring>. I haven't been able to isolate it completely, but there might be a first-three-tokens-only assumption in there somewhere. I've worked around this in the py-letsencrypt (client) port by using a file reference: ${PYTHON_SITELIBDIR}/acme/__init__.py:${PORTSDIR}/security/py-acme
(In reply to Mark Felder from comment #20) Quarterly users don't get new ports nor there dependencies (including any updates to those deps) right?
Please work on it, I'll still be busy for the next few days.
@Kurt How did I inherit the main port? :D In case it wasn't obvious in my original reply, i have the python "client" ready, and I'd like to land that on it's own. I believe this is possible, and unrelated to these ports? From the looks of this issue this contains many other (server, etc) components, is that correct?
Having created a port for what I originally believed was *only* the 'python client' component of letsencrypt, it turns out that the packaging approachfor letsencrypt is unsuitable. That is to say, the current method that upstream uses to bundle all the things, bootstrap and create an isolated virtual environment for all of the python packages (letsencrypt-*) are unnecessary, and beyond that, unsuitable for packaging. Specifically, a port depending on other python ports (themselves obtained from PyPI or elsewhere), must reference (read: import/use) those Python packages from the system Python path. More precisely, depending on python packages, and installing them anywhere other than the system python path (site-packages) means that pkg/portmaster et all cannot manage/upgrade them on an ongoing basis. From my now more complete understanding having gone through the documentation, repositories and the install process for the standalone client (ie; without webserver plugins), I believe the way this should be approached is as follows: security/py-letsencrypt (the "standalone" python client) security/py-letsencrypt-* (the webserver plugins, and other components) The standlone client, displays the following if the particular (apache,nginx, etc) plugins are not available: Choice of server plugins for obtaining and installing cert: (the apache plugin is not installed) --standalone Run a standalone webserver for authentication (nginx support is experimental, buggy, and not installed by default) This is a good thing in terms of only supporting the commands/functions if the requisite modules are installed and importable. Having already completed and tested successfully authenticating and obtaining a certificate from the production letsencrypt server, using the py-letsencrypt client, what's left is to package the webserver plugins separately. These can then be added as NGINX/APACHE options to the py-letsencrypt port/package. These patches/ports thus need to be updated to match Python port/package conventions, in particular the py- prefix, and switched to using the PyPI sdists (releases) as noted/recommended upstream. I intend to land security/py-letsencrypt as soon as possible under my maintainership, as the port I have is fundamentally a new/different port than is currently proposed here, and much much simpler.
Created attachment 162821 [details] Shar for security/letsencrypt Working on an update for the shar-file * Update to 0.0.0dev20151104 * Follow rename of py-parsing to py-pyparsing * Fix paths for /etc and /var/lib Seems functional here
Well almost functional... `letsencrypt certonly` and `auth` work, letsencrypt plain fails on installer problems "No installers are available on your OS yet; try running "letsencrypt-auto certonly" to get a cert you can install manually" Should upstream some patch for that, needs investigation.
Created attachment 162828 [details] py-letsencrypt
Patches for the apache, nginx letshelp components need updating
Pending approval for the py-acme update in in bug 204303. That is a blocker.
Created attachment 162830 [details] py-letsencrypt w/ pkg-message
Created attachment 162831 [details] py-letsencrypt w/ pkg-message v2
Kubilay, I just tested ur latest patches for py-letsencrypt and py-acme. They build and work without any problems, was able to generate multiple certificates.
(In reply to Bas Vermin from comment #34) Thank you for testing and for reporting back Bas! :D
(In reply to Kubilay Kocak from comment #31) Please, go ahead, Kubilay :)
(In reply to Carlos J Puga Medina from comment #36) LETS ROCK N ROLL
A commit references this bug: Author: koobs Date: Fri Nov 6 08:38:35 UTC 2015 New revision: 400885 URL: https://svnweb.freebsd.org/changeset/ports/400885 Log: [NEW] security/py-letsencrypt: Welcome Let's Encrypt client! In short: getting and installing SSL/TLS certificates made easy. The Let's Encrypt Client is a tool to automatically receive and install X.509 certificates to enable TLS on servers. The client will interoperate with the Let's Encrypt CA which will be issuing browser-trusted certificates for free. It's all automated: The tool will prove domain control to the CA and submit a CSR (Certificate Signing Request). If domain control has been proven, a certificate will get issued and the tool will automatically install it. WWW: https://github.com/letsencrypt/letsencrypt PR: 203405 Changes: head/security/Makefile head/security/py-letsencrypt/ head/security/py-letsencrypt/Makefile head/security/py-letsencrypt/distinfo head/security/py-letsencrypt/files/ head/security/py-letsencrypt/files/patch-setup.py head/security/py-letsencrypt/pkg-descr head/security/py-letsencrypt/pkg-message
This issue needs patches for the two (apache/nginx) plugins to progress
Comment on attachment 162831 [details] py-letsencrypt w/ pkg-message v2 The base client (py-letsencrypt) is DONE
Re-open to the pool
letsencrypt is now in the tree, so this can be closed.
Update issue so that it's clear what the resolution was. * Original submission was for letsencrypt *and* nginx, apache plugins. * Update summary to reflect that only py-letsencrypt was committed/added. * Assign to myself as I committed the original security/py-letsencrypt port based on this issue.