On Wed, Nov 30, 2016 at 10:34:11PM +0100, Christian Seiler wrote:
> Ah, and I ran my strace earlier with -e open,access, but after
> rechecking it, it does in fact check for the file's existence
> via stat(). I should remember to use -e open,access,stat when
> checking for file access with strace
On Tue, Nov 29, 2016 at 09:59:06AM +0100, Daniel Pocock wrote:
> This would probably mean making sure the client is checking the network
> API version and giving the user helpful, distro-specific instructions if
> there is a mismatch, e.g. a Debian user would see a message "The Let's
> Encrypt AP
On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
> Peter, there's one more question embedded within what you have already
> asked:
>
> - would new versions of python-certbot and python-acme require new python
> libraries? If yes (or maybe), then the answer would be: go with
> stretch-
On Fri, Nov 25, 2016 at 12:48:35PM +0100, Christian Seiler wrote:
> Note that per backports rules, $RELEASE_N-backports must track
> $RELEASE_N_PLUS_1, so if you remove certbot from Stretch, you'll
> also have to remove it from jessie-backports.
Thank you for pointing this out Christian. This po
On Sat, Nov 26, 2016 at 09:35:46AM +0800, Paul Wise wrote:
> On Tue, Nov 22, 2016 at 9:40 AM, Peter Eckersley wrote:
>
> > currently working with an ACME backwards compatibilty window of 6-12 months,
> > but probably not longer than that.
>
> I note that letsencrypt 0.4.1-1 (before the rename to
Just to be clear, my only point was, if using backports, to make certain
ahead of time that whenever any changes to the packaging, including new
or changed dependencies or the like, occur to always be able atomically
to get the new version into backports.
If conflicts are avoided then backports is
On Tue, Nov 22, 2016 at 9:40 AM, Peter Eckersley wrote:
> currently working with an ACME backwards compatibilty window of 6-12 months,
> but probably not longer than that.
I note that letsencrypt 0.4.1-1 (before the rename to certbot) is
available in Ubuntu xenial, which is scheduled for 5 years
> "HL" == Harlan Lieberman-Berg writes:
HL> The fix we put in place took about ten days to hit. It shouldn't have
HL> been broken longer than that; we didn't close the bug immediately,
HL> because we wanted the dependency to fix their versioning.
I do recall a long wait before an upload was
On November 25, 2016 4:05:30 PM EST, James Cloos wrote:
>It may have been; in any case it took *weeks* for the bug I saw to get
>fixed. And it doesn't matter where the bug was, it still made it
>impossible to apt-get install the certbot package. Which still defines
>the certbot in jessie-backpor
> "HL" == Harlan Lieberman-Berg writes:
HL> In fact, letsencrypt was never in jessie either. Both certbot and
HL> letsencrypt have only ever been in stable-bpo, stretch, and sid.
Ok. That must have been before I was forced to switch my openvz systems
from sid to jessie-backports. (The gli
James Cloos writes:
> HL> Certbot has never been in jessie, so I imagine it wouldn't have been
> usable.
>
> Certbot, letsencrypt, python-acme, et cetera; the package name doesn't
> matter for this purpose.
In fact, letsencrypt was never in jessie either. Both certbot and
letsencrypt have only e
> "HL" == Harlan Lieberman-Berg writes:
HL> Certbot has never been in jessie, so I imagine it wouldn't have been
usable.
Certbot, letsencrypt, python-acme, et cetera; the package name doesn't
matter for this purpose.
HL> I'm also haven't gotten any tickets about it being unusable. Can you
H
On 11/22/2016 02:40 AM, Peter Eckersley wrote:
> 1. Leave Certbot out of the Debian Stretch release, and rely on
> backports as the recommended way to run Certbot on Debian. That's what we
> currently do with Jessie:
Note that per backports rules, $RELEASE_N-backports must track
$RELEASE_N_PLUS_1,
On November 24, 2016 11:59:46 AM EST, James Cloos wrote:
>The jessie and jessie-backports releases of certbot have not, in
>general, been usable. There have been usable windows, but it has not
>been continuous.
Certbot has never been in jessie, so I imagine it wouldn't have been usable.
I'm als
> "PE" == Peter Eckersley writes:
PE> 1. Leave Certbot out of the Debian Stretch release, and rely on
PE> backports as the recommended way to run Certbot on Debian. That's what we
PE> currently do with Jessie:
PE> https://certbot.eff.org/#debianjessie-apache
The jessie and jessie-backports
On Wed, Nov 23, 2016 at 09:57:19AM +0100, Thijs Kinkhorst wrote:
> I'm a bit surprised by this policy. To my knowledge, concepts like automation
> and "hassle-free" are central to the Let's Encrypt concept. Obviously are
> online for more than a year, so installing Let's Encrypt certificates on t
Hi Peter,
On Tue, November 22, 2016 02:40, Peter Eckersley wrote:
> I'm an upstream developer for Certbot, previously known as the Let's
> Encrypt client (https://certbot.eff.org). Certbot is a flexible and very
popular
> way to get certificates from Let's Encrypt;
Thanks a lot for your efforts.
On Mon, Nov 21, 2016 at 05:40:22PM -0800, Peter Eckersley wrote:
> The ACME protocol that it uses to talk to Let's
> Encrypt is also rapidly evolving through an IETF working group
> (https://datatracker.ietf.org/wg/acme/charter/), and the Let's Encrypt
> server-side codebase (https://github.com/let
Hi!
I'm an upstream developer for Certbot, previously known as the Let's Encrypt
client (https://certbot.eff.org). Certbot is a flexible and very popular way
to get certificates from Let's Encrypt; it's issued about 300,000 currently
active TLS certs to Debian servers (and a lot more to Ubuntu ser
Hi!
I'm an upstream developer for Certbot, previously known as the Let's Encrypt
client (https://certbot.eff.org). Certbot is a flexible and very popular way
to get certificates from Let's Encrypt; it's issued about 300,000 currently
active TLS certs to Debian servers (and a lot more to Ubuntu ser
20 matches
Mail list logo
