Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

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. [1]
> 
> And I just checked, putting post-hook = ... in there actually
> seems to work (renew -vvv says it won't run the post hook
> because nothing is to be renewed, but it won't print that
> message if I comment the line out). I do think you could also
> improve the documentation for the 'renew' command to mention
> that these hooks can be put in the central configuration file,
> and to recommend to people to do that instead of supplying
> them on the command line - that way people won't have the idea
> of modifying the cron job / systemd service for this kind of
> thing.

Defining hooks in cli.ini doesn't actually work in 0.9.3, but it sort of works
in git master, and will be properly solved for 0.10.0:

https://github.com/certbot/certbot/issues/3394
https://github.com/certbot/certbot/issues/3394#issuecomment-258579483

> 
> I've now created /etc/letsencrypt/cli.ini and removed my
> drop-in that modifies the systemd service. Thanks, this thread
> has already helped me make my setup saner. :)
> 
> Regards,
> Christian
> 
> [1] Probably should add openat,fstatat,faccessat to the list
> as well.
> 
> 

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

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 API no longer supports your client version, it is now essential
> for you to install certbot by (running apt-get upgrade | using
> $RELEASE_N-backports)"
> 
> To get the message exactly right, it would be useful if the certbot
> utility would actually check the apt catalog for both an SRU and
> backport and tell the user exactly which one is sufficient to get them
> going again.

We actually have some code that generates specific instructions of that exact 
sort;
it powers the Web application at https://certbot.eff.org/ ; the source code is
here:

https://github.com/certbot/website/tree/master/_scripts/instruction-widget

Unfortunately, it's written in the wrong language (JavaScript rather than Go)
for us to be able to easily have the boulder server return errors that send
these instructions to old copies of Certbot. So what we'd probably do is
tell people, "please install a copy of Cerbot greater than X; you can go
to https://certbot.eff.org/ if you need advice on how to do that on your OS"

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

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 policy removes what might have
been the simplest option, and seems to mean that we'll want to work hard on a 
plan
where Certbot is in Stretch in a way that works both for us upstream and for
the Debian release team.

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Paul Wise]

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 of support,
terminating in 2021.

https://people.canonical.com/~ubuntu-archive/madison.cgi?package=letsencrypt+certbot
https://wiki.ubuntu.com/Releases

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Harlan Lieberman-Berg]

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-backports experience as (at least historically)
>unreliable.

Hi Jim,

Dropping the lists here to get some more specifics.

The fix we put in place took about ten days to hit. It shouldn't have been 
broken longer than that; we didn't close the bug immediately, because we wanted 
the dependency to fix their versioning. 

It's possible the workaround didn't actually correct the problem fully; it 
should have, but I only tested it briefly. (It was simply adding in a 
downstream dependency with a versioning restriction).

Do you happen to remember when the problem was? I'd like to make sure I 
understand, since I agree completely; a fix taking weeks is not acceptable, and 
I am upset and embarrassed to learn one of my packages took that long.

-- 
Harlan Lieberman-Berg
~hlieberman

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[James Cloos]

> "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 glibc maintainer broke sid, stretch
and later on openvz and after it was reported refused to fix it.)

But even after I was able to 'apt-get install certbot' on some of my
jessie-backports machines, it was later impossible to do so on others.

So there was a window where it worked followed by a long spot where it
did not.

HL> If you're referring to #825619, that was a bug in a dependency, not in
HL> certbot, which we worked around by specifying a child version dependency
HL> in python-acme.

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-backports experience as (at least historically)
unreliable.

Anything which takes weeks to fix is unreliable.

The points I made at the end of my last note about methods which might
avoid such things in the future remain on point.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Harlan Lieberman-Berg]

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 ever been in stable-bpo, stretch, and sid.

> And there was quite a long time when apt-get install certbot failed on
> jessie-backports systems due to version incompatibilities.

If you're referring to #825619, that was a bug in a dependency, not in
certbot, which we worked around by specifying a child version dependency
in python-acme.

Either way, I don't see the relevance for the larger discussion.  I'm
happy to discuss the breakage off-list, if you have concerns.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman


signature.asc
Description: PGP signature
___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[James Cloos]

> "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
HL> please provide me a link to the tickets you filed when you found it
HL> unusable?

There have been many threads on the vaious debian lists, so I didn't
need to.

And there was quite a long time when apt-get install certbot failed on
jessie-backports systems due to version incompatibilities.

So my main warning is that jessie-backports has failed atomically to
upgrade all of the necessary components on a consistant basis, so why
should we expect stretch-backports to do so?

Maybe the knowledge of the issues jessie-backports has faced will be
enough to ensure stretch-backports does better.  Maybe.

But there needs to be a pre-negotiated assurance that backports'
standard procedures won't get in the way.

(I understand part of the issue was update vs new for some fraction of
the dependencies.  Perhaps also the effect that new versions of the
dependencies would have on their other reverse-dependencies?)

Guaranteeing that certbot and python-acme updates will not require new
dependencies probably would help on that front.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Harlan Lieberman-Berg]

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 also haven't gotten any tickets about it being unusable. Can you please 
provide me a link to the tickets you filed when you found it unusable?

-- 
Harlan Lieberman-Berg
~hlieberman

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[James Cloos]

> "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 releases of certbot have not, in
general, been usable.  There have been usable windows, but it has not
been continuous.

Forcing stretch uses into a similar situation would be counter-productive.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

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 them
> is not quite automated or hassle-free if you need to upgrade certbot several
> times during the projected lifetime of the server.
> 
> Is it really necessary to have such, in my opinion, really short API
> lifetimes?
> Surely you want to extend and develop it, but this can be done while keeping
> compatibility with existing clients in the field.

I think this is a pretty profound strategic and philosophical question :)

What I hear from the boulder development team is that supporting old versions
of the protocol on the server side will greatly complicate their work: they'll
either have to maintain many more code paths within a given application (to
support different call semantics in different versions of the protocol) or
support multiple instances of the CA application talking to the same back-end
databases. In one case they'd have to stick with an old version of the Go
language, because Go 1.7's standard library implemented better CSR checking,
which exposed a Certbot CSR formatting bug.

The boulder team's philosophy is to deal with these engineering difficulties
by being fairly agressive in pushing clients to take regular updates. They're
willing to maintain support for prior protocol versions, but only for a
limited amount of time. I think that "get everyone to run the latest and
most-correct code" approach is a fairly common attitude especially amongst
security-focussed projects.

But there are of course drawbacks: it makes life harder for projects that (in
relative terms) place a higher priority on stability vs security. And that's a
legitimate choice for many purposes.

So Let's Encrypt definitely wants to get to a place where we have some very
stable APIs for other people to code against. We're trying to do that with the
Certbot command line itself, working hard to ensure that if people upgrade, it
doesn't break scripts they might have written around the client. And in the
long run, I suspect ACME will mature and stabilise too.  But it's especially
tricky to expect long-run-future-compatibility from a service that's only been
online for a year.

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Thijs Kinkhorst]

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. This is really useful indeed.

> 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/letsencrypt/boulder) is
> currently working with an ACME backwards compatibilty window of 6-12
> months, but probably not longer than that.

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 them
is not quite automated or hassle-free if you need to upgrade certbot several
times during the projected lifetime of the server.

Is it really necessary to have such, in my opinion, really short API
lifetimes?
Surely you want to extend and develop it, but this can be done while keeping
compatibility with existing clients in the field.


Cheers,
Thijs

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel

Re: [Letsencrypt-devel] Certbot in Debian Stretch

[Peter Colberg]

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/letsencrypt/boulder) is 
> currently working with an ACME backwards compatibilty window of 6-12 months,
> but probably not longer than that.

This issue affects many more clients in Debian besides certbot:

https://wiki.debian.org/LetsEncrypt

Peter

___
Letsencrypt-devel mailing list
Letsencrypt-devel@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel