1 files changed, 95 insertions, 0 deletions
diff --git a/debian/control b/debian/control
new file mode 100644
index 0000000..3f8a096
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,95 @@
+Source: lacme
+Section: utils
+Priority: optional
+Maintainer: Guilhem Moulin <guilhem@debian.org>
+Build-Depends: debhelper-compat (= 13), jq, pandoc (>= 2.1~)
+Rules-Requires-Root: no
+Standards-Version: 4.6.2
+Homepage: https://git.guilhem.org/lacme/about/
+Vcs-Git: https://salsa.debian.org/debian/lacme.git -b debian/latest
+Vcs-Browser: https://salsa.debian.org/debian/lacme
+
+Package: lacme
+Architecture: all
+Depends: adduser,
+         libconfig-tiny-perl,
+         libjson-perl,
+         libnet-ssleay-perl,
+         libtimedate-perl,
+         libwww-perl,
+         openssl (>= 1.1.0~),
+         ${misc:Depends},
+         ${perl:Depends}
+Recommends: lacme-accountd (>= 0.8.0), liblwp-protocol-https-perl
+Description: ACME client written with process isolation and minimal privileges in mind
+ lacme is an ACME client which can be used to request X.509 certificates from
+ ACME service providers such as Let's Encrypt or ZeroSSL.  The architecture is
+ divided into four components, each with its own executable:
+ .
+  * A process to manage the account key and issue SHA-256 signatures needed for
+    each ACME command.  (This process binds to a UNIX-domain socket to reply to
+    signature requests from the ACME client.)  One can use the UNIX-domain
+    socket forwarding facility of OpenSSH 6.7 and later to run this process on
+    a different host.
+ .
+  * A "master" process, which runs as root and is the only component
+    with access to the private key material of the server keys.  It is used to
+    fork the ACME client (and optionally the ACME webserver) after dropping
+    root privileges.  For certificate issuances, it also generates Certificate
+    Signing Requests, then verifies the validity of the issued certificate, and
+    optionally reloads or restarts services.
+ .
+  * An actual ACME client, which builds ACME commands and dialogues with
+    the remote ACME server.  Since ACME commands need to be signed with the
+    account key, the "master" process passes the UNIX-domain socket of the
+    account key manager to the ACME client: data signatures are requested by
+    writing the data to be signed to the socket.
+ .
+  * For certificate issuances, an optional webserver, which is spawned
+    by the "master" process when no service is listening on the HTTP port.
+    (The only challenge type currently supported is "http-01", which requires a
+    webserver to answer challenges.)  That webserver only processes GET and
+    HEAD requests under the "/.well-known/acme-challenge/" URI.  By default
+    some iptables(8) rules are automatically installed to open the HTTP port,
+    and removed afterwards.
+
+Package: lacme-accountd
+Architecture: all
+Depends: libconfig-tiny-perl, libjson-perl, ${misc:Depends}, ${perl:Depends}
+Recommends: libcrypt-openssl-rsa-perl
+Suggests: gpg, openssl
+Multi-Arch: foreign
+Description: lacme account key manager
+ lacme is an ACME client which can be used to request X.509 certificates from
+ ACME service providers such as Let's Encrypt or ZeroSSL.  The architecture is
+ designed with process isolation and minimal privileges in mind, and is divided
+ into four components:
+ .
+  * A process to manage the account key and issue SHA-256 signatures needed for
+    each ACME command.  (This process binds to a UNIX-domain socket to reply to
+    signature requests from the ACME client.)  One can use the UNIX-domain
+    socket forwarding facility of OpenSSH 6.7 and later to run this process on
+    a different host.
+ .
+  * A "master" process, which runs as root and is the only component
+    with access to the private key material of the server keys.  It is used to
+    fork the ACME client (and optionally the ACME webserver) after dropping
+    root privileges.  For certificate issuances, it also generates Certificate
+    Signing Requests, then verifies the validity of the issued certificate, and
+    optionally reloads or restarts services.
+ .
+  * An actual ACME client, which builds ACME commands and dialogues with
+    the remote ACME server.  Since ACME commands need to be signed with the
+    account key, the "master" process passes the UNIX-domain socket of the
+    account key manager to the ACME client: data signatures are requested by
+    writing the data to be signed to the socket.
+ .
+  * For certificate issuances, an optional webserver, which is spawned
+    by the "master" process when no service is listening on the HTTP port.
+    (The only challenge type currently supported is "http-01", which requires a
+    webserver to answer challenges.)  That webserver only processes GET and
+    HEAD requests under the "/.well-known/acme-challenge/" URI.  iptables(8)
+    rules can optionally be installed to temporarily open the HTTP port.
+ .
+ lacme-accountd is the first (account key manager) component.  It is the only
+ component with access to the account key.