search

sludin / Protocol-ACME

A perl library that provides a simple interface to writing scripts for cert provisioning with Let's Encrypt.
24 stars 7 forks source link

Client module #34

Closed melmothx closed 8 years ago

melmothx commented 8 years ago

Hello there.

I've written this module for my project: https://github.com/melmothx/amusewiki/blob/master/lib/AmuseWikiFarm/Utils/LetsEncrypt.pm

It uses the logic of https://github.com/oetiker/AcmeFetch, supporting only local files challenges, but with additionally a self-check (so we avoid spamming requests to the acme server if we know in advance that the request would fail).

I'm wondering if you want it included in Protocol::ACME (in a slightly modified form + documentation), or if you are fine with me crushing in the cpan namespace like Protocol::ACME::SimpleClient, or should I just keep it for myself. I'm fine with all the 3 solutions.

oetiker commented 8 years ago

How about providing patches for AcmeFetch ?

melmothx commented 8 years ago

Hi @oetiker

Tobias Oetiker notifications@github.com writes:

How about providing patches for AcmeFetch ?

I would be glad to do so, but I see some problems in AcmeFetch (which led me to (re)writing the logic in a module:

I think it would be important to reach a kind of consensus how to proceed here to avoid duplicating the efforts and writing the same code over and over again.

Marco

oetiker commented 8 years ago

Since presently all functionality is in the script, it does not make all that much sense on CPAN, but if you were to factor out stuff into a module and turn the script into just a script, then I would be glad to put it on CPAN and also throw a Makefile.PL into the mix ... I'll be glad to integrate such a PR

The purpose of the automake build system is that this gives us the ability to setup AcmeFetch on a system with just perl 5.10+, openssl and a compiler ... all the dependent modules are included (try the download version https://github.com/oetiker/AcmeFetch/releases) ... hence it frees the whole thing from the perl niche and makes it universally useful.

melmothx commented 8 years ago

Tobias Oetiker notifications@github.com writes:

Since presently all functionality is in the script, it does not make all that much sense on CPAN, but if you were to factor out stuff into a module and turn the script into just a script, then I would be glad to put it on CPAN and also throw a Makefile.PL into the mix ... the purpose of the automake build system is that this gives us the ability to setup AcmeFetch on a system with just perl 5.10+, openssl and a compiler ... all the dependent modules are included (try the download version https://github.com/oetiker/AcmeFetch/releases) ... hence it frees the whole thing from the perl niche and makes it universally useful.

Ok, let's break down the problems here:

P.S: Tobias, this is totally unrelated, but while we're having this conversation, I'd like to thank you for the Not so short introduction to LaTeX.

Marco

oetiker commented 8 years ago

Hi Marco

no moo dependency please ... use mojolicious if you feel like it ... that make even be a good thing for acme, takeing care of the http tiny dependency.

cheers tobi

Tobias Oetiker tobi@oetiker.ch 062 775 9902

On 01.05.2016, at 13:25, Marco notifications@github.com wrote:

Tobias Oetiker notifications@github.com writes:

Since presently all functionality is in the script, it does not all that much sense on CPAN, but if you were to factor out stuff into a module and turn the script into just a script, then I would be glad to put it on CPAN and also throw a Makefile.PL into the mix ... the purpose of the automake build system is that this gives us the ability to setup AcmeFetch on a system with just perl 5.10+, openssl and a compiler ... all the dependent modules are included (try the download version https://github.com/oetiker/AcmeFetch/releases) ... hence it frees the whole thing from the perl niche and makes it universally useful.

Ok, let's break down the problems here:

  • the script should just parse the config and build a, say, Protocol::ACME::AcmeFetch object, which should pull out half of the logic from the script (account key creation, fetching, signing).
  • The self-check thing probably belongs to the Challenge classes, so if @sludin is fine, I'd hack that there and issue a PR.
  • Where Protocol::ACME::AcmeFetch should be maintained. In a new repo with independent upload to CPAN (then the AcmeFetch app would just pull that as dep), in the Protocol::ACME tree, or in the existent AcmeFetch repo (but we need to discuss how to integrate that in the existing building system, considering the it should go up independently on CPAN, or just prepare an empty module where I can hack, which would be ideal for me).
  • Dependencies: I used Path::Tiny and Moo, which make things much cleaner. Are you fine with that?

P.S: Tobias, this is totally unrelated, but while we're having this conversation, I'd like to thank you for the Not so short introduction to LaTeX.

Marco — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

melmothx commented 8 years ago

Tobias Oetiker notifications@github.com writes:

Hi Marco

no moo dependency please ... use mojolicious if you feel like it ... that make even be a good thing for acme, takeing care of the http tiny dependency.

Well, ok for skipping the Moo dependency, but the Mojolicious dependency feels totally wrong for a general purpose module.

The HTTP::Tiny is already pulled by Protocol::ACME (also in core recently, IIRC).

Marco

oetiker commented 8 years ago

ok no moo no mojo :) no problem

sludin commented 8 years ago

Sorry all, I somehow missed this whole discussion. Did this land anywhere?

melmothx commented 8 years ago

Stephen Ludin notifications@github.com writes:

Sorry all, I somehow missed this whole discussion. Did this land anywhere?

AFAIC, no. I asked some questions, got no answer, assumed that there is no interest and moved on.

Marco