diff mbox

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

Message ID f1649dd9aafe811c930ddaca825dbffe82e20818.1472827750.git.leo@famulari.name
State New
Headers show

Commit Message

Leo Famulari Sept. 2, 2016, 2:49 p.m. UTC
* gnu/packages/tls.scm (acme-client): New variable.
---
 gnu/packages/tls.scm | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

Comments

Hartmut Goebel Sept. 2, 2016, 6:01 p.m. UTC | #1
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?
Leo Famulari Sept. 2, 2016, 6:50 p.m. UTC | #2
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/
Leo Famulari Sept. 2, 2016, 6:58 p.m. UTC | #3
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.
Hartmut Goebel Sept. 3, 2016, 7:43 a.m. UTC | #4
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.
Andreas Enge Sept. 3, 2016, 10:04 a.m. UTC | #5
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
Marius Bakke Sept. 3, 2016, 10:32 a.m. UTC | #6
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
Leo Famulari Sept. 4, 2016, 2:29 a.m. UTC | #7
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.
Leo Famulari Sept. 4, 2016, 2:43 a.m. UTC | #8
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
Marius Bakke Sept. 4, 2016, 5:12 a.m. UTC | #9
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
Andreas Enge Sept. 11, 2016, 12:42 p.m. UTC | #10
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
Hartmut Goebel Sept. 11, 2016, 12:57 p.m. UTC | #11
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.
Leo Famulari Sept. 12, 2016, 5:06 p.m. UTC | #12
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.
diff mbox

Patch

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))))