Re: acme-client -t switch?
>>> Since this came up.. what does anyone think about adding the original >>> version back to ports? (personally, I could do with moving things away >>> from the python version, but I need dns-01..) >> >> I'm planing on re-introducing the [-t switch] functinality. > > What direction are you planning on going with that? Using the model > that Kristaps is using in the git version where challenges are provided > on stdout to another program? Or using something closer to the original > implementation where acme-client executes an arbitrary program when > it needs to do the challenge? > > I think the stdout mechanism would be cleaner as that way an extension > only needs to integrate by calling acme-client, not integrating both > caller and callee. It would also reduce the differences between the > versions. Upstream and openbsd's version aren't that different beyond the configuration file. There are just more features upstream (OCSP, etc.), but nothing fundamental. I'll be pulling in the downstream config file, as already acme-client has a ridiculous number of flags. There are a few patches for user credentials I'm sitting on because I just don't want to add flags. As for [-t], I reckon I'll just have a config entry of challenge type and the program to execute. This'll then be invoked as a subprocess in the same way as currently documented. This will require more work, but nothing crazy.
Re: acme-client -t switch?
--On Thursday, March 09, 2017 06:13:38 PM +0100 Sebastian Benoit wrote: Stuart Henderson(s...@spacehopper.org) on 2017.03.07 21:56:56 +: Since this came up.. what does anyone think about adding the original version back to ports? (personally, I could do with moving things away from the python version, but I need dns-01..) I'm planing on re-introducing the [-t switch] functinality. What direction are you planning on going with that? Using the model that Kristaps is using in the git version where challenges are provided on stdout to another program? Or using something closer to the original implementation where acme-client executes an arbitrary program when it needs to do the challenge? I think the stdout mechanism would be cleaner as that way an extension only needs to integrate by calling acme-client, not integrating both caller and callee. It would also reduce the differences between the versions. Devin
Re: acme-client -t switch?
Stuart Henderson(s...@spacehopper.org) on 2017.03.07 21:56:56 +: > On 2017/03/07 13:24, Devin Reade wrote: > > Expanding on my previous email, it looks like the git version of > > acme-client has a different implementation than what was implemented > > in the version first committed (and later removed) from the OpenBSD > > CVS sources. The latter (CVS) version was calling "doas sh ..." > > whereas the former (git) version writes challenges to stdout which > > can then be processed by the invoking program. Looking at the logs, > > it appears the git version is a reworking of the functionality. > > > > For the record, I was asking about introducing the mechanism (stdout) > > currently used by the git version. > > > > Devin > > > > Both OpenBSD's version and the original have seen independent changes > after import, they have now diverged quite a lot. > > Since this came up.. what does anyone think about adding the original > version back to ports? (personally, I could do with moving things away > from the python version, but I need dns-01..) I'm planing on re-introducing the functinality.
Re: acme-client -t switch?
On 2017/03/07 13:24, Devin Reade wrote: > Expanding on my previous email, it looks like the git version of > acme-client has a different implementation than what was implemented > in the version first committed (and later removed) from the OpenBSD > CVS sources. The latter (CVS) version was calling "doas sh ..." > whereas the former (git) version writes challenges to stdout which > can then be processed by the invoking program. Looking at the logs, > it appears the git version is a reworking of the functionality. > > For the record, I was asking about introducing the mechanism (stdout) > currently used by the git version. > > Devin > Both OpenBSD's version and the original have seen independent changes after import, they have now diverged quite a lot. Since this came up.. what does anyone think about adding the original version back to ports? (personally, I could do with moving things away from the python version, but I need dns-01..)
Re: acme-client -t switch?
Expanding on my previous email, it looks like the git version of acme-client has a different implementation than what was implemented in the version first committed (and later removed) from the OpenBSD CVS sources. The latter (CVS) version was calling "doas sh ..." whereas the former (git) version writes challenges to stdout which can then be processed by the invoking program. Looking at the logs, it appears the git version is a reworking of the functionality. For the record, I was asking about introducing the mechanism (stdout) currently used by the git version. Devin
acme-client -t switch?
So I was looking to use acme-client's "-t" switch to orchestrate the creation of certificates for non-HTTPS use and off-machine use. However I see that it was removed in main.c version 1.15 in the OpenBSD source tree. (I'm currently testing acme-client via git on OpenBSD 6.0.) Would folks be amenable to patches that would allow re-introducing this switch? Although I'm open to suggestions/comments on the approach, my intent was to create a perl program / modules for CPAN that would use acme-client to support both the dns-01 challenge and shipping certificates to other machines (think of the IMAPS use case, as an example). Devin
