[PATCH 0/1] Another Let's Encrypt client

[PATCH 0/1] Another Let's Encrypt client

[Leo Famulari]

I have been looking at this Let's Encrypt client for a little while. It
was just merged into the OpenBSD base system, and had its name changed
from 'letskencrypt' to the generic 'acme-client'. The name might be too 
generic; I found at least 4 different programs with this name.

https://kristaps.bsd.lv/acme-client/

Some attempt has been made to reduce the risks inherent to running the 
program as root, as described on the home page.

And, I did a minimal test: I was able to get a new certificate.

Leo Famulari (1):
  gnu: Add acme-client.

 gnu/packages/tls.scm | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

-- 
2.9.3

[PATCH 1/1] gnu: Add acme-client.

[Leo Famulari]

* gnu/packages/tls.scm (acme-client): New variable.
---
 gnu/packages/tls.scm | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 4b87150..eeb15ca 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -34,6 +34,7 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages)
   #:use-module (gnu packages guile)
+  #:use-module (gnu packages libbsd)
   #:use-module (gnu packages libffi)
   #:use-module (gnu packages libidn)
   #:use-module (gnu packages linux)
@@ -619,3 +620,37 @@ arithmetic in Perl.")
   (description "Crypt::OpenSSL::Random is a OpenSSL/LibreSSL pseudo-random
 number generator")
   (license (package-license perl))))
+
+(define-public acme-client
+  (package
+    (name "acme-client")
+    (version "0.1.11")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "https://kristaps.bsd.lv/" name "/"
+                                  "snapshots/" name "-portable-"
+                                  version ".tgz"))
+              (sha256
+               (base32
+                "09pipyfk448gxqr7ci56gsq5la8wlydv7wwn9wk0zgjxmlh7h6fb"))))
+    (build-system gnu-build-system)
+    (arguments
+     '(#:tests? #f ; no test suite
+       #:make-flags
+       (list "CC=gcc"
+             (string-append "PREFIX=" (assoc-ref %outputs "out")))
+       #:phases
+       (modify-phases %standard-phases
+         (delete 'configure)))) ; no './configure' script
+    (inputs
+     `(("libbsd" ,libbsd)
+       ("libressl" ,libressl)))
+    (synopsis "Let's Encrypt client")
+    (description "acme-client is a Let's Encrypt client implemented in C.  It
+uses a modular design, and attempts to secure itself by dropping privileges and
+operating in a chroot where possible.  acme-client is developed on OpenBSD and
+then ported to the GNU / Linux environment.")
+    (home-page "https://kristaps.bsd.lv/acme-client/")
+    ;; acme-client is distributed under the ISC license, but the files 'jsmn.h'
+    ;; and 'jsmn.c' are distributed under the Expat license.
+    (license (list license:isc license:expat))))
-- 
2.9.3

Re: [PATCH 1/1] gnu: Add acme-client.

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]

Am 02.09.2016 um 16:49 schrieb Leo Famulari:
> +    (name "acme-client")

I strongly suggest using a different name, as this is *one* of many
implementations and it is not the "official" one.

> +    (synopsis "Let's Encrypt client")

The synopsis should already state, this is *one* of the acme-clients.
Something like "Let's Encrypt client  used as standard at OpenBSD" is
more meaningful.
> +    (description "acme-client is a Let's Encrypt client implemented in C.  It
> +uses a modular design, and attempts to secure itself by dropping privileges and

*shiver* Why would one implement this in an language like C, which is
prone to buffer overflows, if there are implementations available in
more secure languages?


-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/filmgesprach-zu-201ecitizenfour201c-in-herrsching

Kolumne: http://www.cissp-gefluester.de/2010-06-adobe-und-der-maiszunsler


[-- Attachment #1.2: Type: text/html, Size: 2740 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2430 bytes --]

Re: [PATCH 1/1] gnu: Add acme-client.

[Leo Famulari]

On Fri, Sep 02, 2016 at 08:01:55PM +0200, Hartmut Goebel wrote:
> Am 02.09.2016 um 16:49 schrieb Leo Famulari:
> > +    (name "acme-client")
> 
> I strongly suggest using a different name, as this is *one* of many
> implementations and it is not the "official" one.

Suggestions?

> *shiver* Why would one implement this in an language like C, which is
> prone to buffer overflows, if there are implementations available in
> more secure languages?

I wouldn't propose this package if it wasn't part of OpenBSD's base
system:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/acme-client/

Re: [PATCH 1/1] gnu: Add acme-client.

[Leo Famulari]

On Fri, Sep 02, 2016 at 02:50:28PM -0400, Leo Famulari wrote:
> > *shiver* Why would one implement this in an language like C, which is
> > prone to buffer overflows, if there are implementations available in
> > more secure languages?
> 
> I wouldn't propose this package if it wasn't part of OpenBSD's base
> system:
> 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/acme-client/

To clarify my statement, I think the OpenBSD project has a reputation
for writing good C. Also they design software to fail safely, by
designing privilege separation into their tools, inventing and using
pledge(2), etc.

This portable version of the software only gets some of those benefits,
but it does get some of them.

That's I didn't propose this package until I saw that it had been
reviewed and adopted by OpenBSD.

Re: [PATCH 1/1] gnu: Add acme-client.

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 1684 bytes --]

Am 02.09.2016 um 20:50 schrieb Leo Famulari:
> On Fri, Sep 02, 2016 at 08:01:55PM +0200, Hartmut Goebel wrote:
>> Am 02.09.2016 um 16:49 schrieb Leo Famulari:
>>> +    (name "acme-client")
>>>
> Suggestions?

acme-client-openbsd? But given that this is a stupid name, and given
that
https://www.metachris.com/2015/12/comparison-of-10-acme-lets-encrypt-clients/
does not list a program with this name, may we should stick with the
official name.


>
>> *shiver* Why would one implement this in an language like C, which is
>> prone to buffer overflows, if there are implementations available in
>> more secure languages?
> I wouldn't propose this package if it wasn't part of OpenBSD's base
> system:

I'm sorry, no offence meant! I only wanted do express my doubt about
using C if other implementations are available. (I just had a look at
the source, which did not make me more confident in this piece of
software; as far as can see they implement a  a http-client from stretch
and include a json-parse instead of linking one.) I also know, OpenBSD
delivers good software.

It's not our job to decide what software a sysadmin should install. It's
the sysadmin's responsibility. Our job as distribution-builders is to 
provide software to the sysadmin.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: http://www.goebel-consult.de/blog/verschlusselte-mailingslisten
Kolumne: http://www.cissp-gefluester.de/2010-07-passwoerter-lieben-lernen


[-- Attachment #1.2: Type: text/html, Size: 3389 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2430 bytes --]

Re: [PATCH 1/1] gnu: Add acme-client.

[Andreas Enge]

On Fri, Sep 02, 2016 at 02:50:28PM -0400, Leo Famulari wrote:
> On Fri, Sep 02, 2016 at 08:01:55PM +0200, Hartmut Goebel wrote:
> > Am 02.09.2016 um 16:49 schrieb Leo Famulari:
> > > +    (name "acme-client")
> > I strongly suggest using a different name, as this is *one* of many
> > implementations and it is not the "official" one.
> Suggestions?

Is there other reasonably widely used software with this name? Our package
guidelines say to use the upstream name.

Andreas

Re: [PATCH 1/1] gnu: Add acme-client.

[Marius Bakke]

Andreas Enge <andreas@enge.fr> writes:

> On Fri, Sep 02, 2016 at 02:50:28PM -0400, Leo Famulari wrote:
>> On Fri, Sep 02, 2016 at 08:01:55PM +0200, Hartmut Goebel wrote:
>> > Am 02.09.2016 um 16:49 schrieb Leo Famulari:
>> > > +    (name "acme-client")
>> > I strongly suggest using a different name, as this is *one* of many
>> > implementations and it is not the "official" one.
>> Suggestions?
>
> Is there other reasonably widely used software with this name? Our package
> guidelines say to use the upstream name.

I don't know about widely used, but searching "acme-client" on github
shows four projects with this name, neither of which is this package.

Many distros prefix OpenBSD projects with ambigous names with
"openbsd-". E.g. "openbsd-netcat", "openbsd-ntpd" etc. We don't appear
to have that problem yet, but I think this could be a good precedent.

-marius

Re: [PATCH 1/1] gnu: Add acme-client.

[Leo Famulari]

On Sat, Sep 03, 2016 at 11:32:20AM +0100, Marius Bakke wrote:
> Many distros prefix OpenBSD projects with ambigous names with
> "openbsd-". E.g. "openbsd-netcat", "openbsd-ntpd" etc. We don't appear
> to have that problem yet, but I think this could be a good precedent.

Is "openbsd-ntpd" the same thing as OpenNTPD? [0]

As for openbsd-netcat, this was discussed on guix-devel recently, and we
learned that OpenBSD does not provide a portable release of their netcat
client. I don't think it would be appropriate for us to re-package
Debian's unmaintained port of this software. [1]

I looked at `apt-cache search openbsd`, which searches my Debian package
cache for packages related to OpenBSD. I *think* that there isn't
anything packaged with an "openbsd-" name that OpenBSD offers a portable
release of, but I'm not sure about openbsd-inetd.

On the other hand, they explicitly provide portable releases of things
like OpenNTPD, OpenSSH, LibreSSL, and now acme-client.

They really pushed the issue with this "acme-client". Maybe they should
have kept the old name, letskencrypt, for the sake of all the GNU /
Linux distros :)

[0]
http://www.openntpd.org/

[1]
http://lists.gnu.org/archive/html/guix-devel/2016-07/msg00084.html

Re: [PATCH 1/1] gnu: Add acme-client.

[Marius Bakke]

Leo Famulari <leo@famulari.name> writes:

> On Sat, Sep 03, 2016 at 11:32:20AM +0100, Marius Bakke wrote:
>> Many distros prefix OpenBSD projects with ambigous names with
>> "openbsd-". E.g. "openbsd-netcat", "openbsd-ntpd" etc. We don't appear
>> to have that problem yet, but I think this could be a good precedent.
>
> Is "openbsd-ntpd" the same thing as OpenNTPD? [0]
>
> As for openbsd-netcat, this was discussed on guix-devel recently, and we
> learned that OpenBSD does not provide a portable release of their netcat
> client. I don't think it would be appropriate for us to re-package
> Debian's unmaintained port of this software. [1]
>
> I looked at `apt-cache search openbsd`, which searches my Debian package
> cache for packages related to OpenBSD. I *think* that there isn't
> anything packaged with an "openbsd-" name that OpenBSD offers a portable
> release of, but I'm not sure about openbsd-inetd.
>
> On the other hand, they explicitly provide portable releases of things
> like OpenNTPD, OpenSSH, LibreSSL, and now acme-client.

You are right, of course. I could have sworn there were more. And I even
use OpenNTPD on many systems..

The other acme-client projects seems to be mostly library
implementations with a CLI frontend and are likely to end up as
"ruby-acme-client" or similar in the tree. So "acme-client" should be
perfectly fine. If anything we'll get to have a new bikeshedding round
if another popular client with the same name comes around. :)

~marius

Re: [PATCH 1/1] gnu: Add acme-client.

[Leo Famulari]

On Sat, Sep 03, 2016 at 12:04:13PM +0200, Andreas Enge wrote:
> Is there other reasonably widely used software with this name? Our package
> guidelines say to use the upstream name.

Here is what I found:

https://github.com/kristapsdz/acme-client
The program I have proposed to package.

https://github.com/unixcharles/acme-client
Written in Ruby. Appears active.

https://github.com/kelunik/acme-client
Written in PHP. Appears active.

https://github.com/zero11it/acme-client
Written in Java. No recent activity and only 8 commits to the Git repo.

Re: [PATCH 1/1] gnu: Add acme-client.

[Andreas Enge]

On Sat, Sep 03, 2016 at 10:29:12PM -0400, Leo Famulari wrote:
> On Sat, Sep 03, 2016 at 12:04:13PM +0200, Andreas Enge wrote:
> > Is there other reasonably widely used software with this name? Our package
> > guidelines say to use the upstream name.
> 
> Here is what I found:
> 
> https://github.com/kristapsdz/acme-client
> The program I have proposed to package.
> 
> https://github.com/unixcharles/acme-client
> Written in Ruby. Appears active.
> 
> https://github.com/kelunik/acme-client
> Written in PHP. Appears active.
> 
> https://github.com/zero11it/acme-client
> Written in Java. No recent activity and only 8 commits to the Git repo.

Maybe one solution would be to call the first program "acme-client",
and, if it ever gets packaged, the second one "ruby-acme-client" and so on?

Andreas

Re: [PATCH 1/1] gnu: Add acme-client.

[Hartmut Goebel]

Am 11.09.2016 um 14:42 schrieb Andreas Enge:
> Maybe one solution would be to call the first program "acme-client",
> and, if it ever gets packaged, the second one "ruby-acme-client" and so on?

This sound good to me.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH 1/1] gnu: Add acme-client.

[Leo Famulari]

On Fri, Sep 02, 2016 at 10:49:38AM -0400, Leo Famulari wrote:
> * gnu/packages/tls.scm (acme-client): New variable.

Thanks for the feedback, everyone. Pushed as
0581c273a4d5171a477d89f109c46d7ab3691429, with a followup commit that
adds some detail to certbot's synopsis.