PowerShell Module for ACMESharpCore
glatzert opened this issue · comments
I think the availability of ACMESharpCore would be a good Point to also move to PowershellStandard.
I was Looking into the ACME.POSH last week and started using it more or less successfully.
I'd like to contribute some changes, which would make the Cmdlets more "normalized" - but I have to admit, that would be Breaking changes.
What I mean by normalized:
The Get-ACMEIdentifier Cmdlet for example returns different types for Get-ACMEIdentifier or Get-ACMEIdentifier -IdenRef xxx.
Also Get Outputs should be pipe-able into update Methods and such.
Since I'm not the guy to only complain About that things, I'd happily provide my time to contribute.
Great -- contributions are more than welcome!
Yes, I agree - I would like to move to using PowerShell Standard with the migration of the PowerShell Module to use ACMESharp Core.
Actually, one change I've been contemplating is moving the Core version of the PowerShell module to be implemented as a PowerShell script module instead of a binary module. My thinking is that, the majority of users of the PS module are not necessarily developers and are pby not as comfortable with C# code as they are with authoring PS cmdlets, and doing so would open up the code for more contributions and involvement from the community.
I also agree, there are a few inconsistencies and it would be nice to clean up the API. I'm actually interested in getting feedback from all as to how they would like to see the PS API and workflow improved. The original model worked for my original situation, but perhaps it's not intuitive -- so this is an opportunity to rewrite the whole thing based on feedback.
Probably you are right. My experience with PS-Binary-Modules is that they tend to be harder to write than PS-"native"-Cmdlets as well.
Nevertheless the ACMESharp Core-Classes probably can be used without problems from both.
Since i'm currently programming with acmesharp posh, I see some other things which could be improved:
- complete challenge takes a lot of parameters, which handle the challenge, but the extension model seems "complicated" compared to just providing the values neccessary and calling something like Handle-ACMEChallengeHTTP.
I think it would be nice to assume "manual" handling always and provide a lean and nice way to access all neccessary informations.
It would then be easy to call a handler script.
Same goes for installers, I think.
If you pick a name for the module and provide the psd1, we could write some tasks as "issues" and I'd fetch and implement some of them.
I like your ideas, let's explore those further here. You can start adding tasks and ideas to the issues in the new repo.
I started pushing some module layout into a branch in that new repository, but I did not have time to fill in anything useful. The module loader btw is taken from dbatools. I'm not sure, if i like another subfolder in the module to place the files and have a top level like you did, but I also have not enough issues with it to just follow your decision on that.
The module does need a build script, which consolidates all files from the modules into a single one. Which makes module loading much faster.
I think the module needs some local state, but I did not yet understand how the former ACMEVault is to be replaced. This probably needs to be a starting point, since we need someplace to store the local state.
After that, I'm ready to port the ProtocolClient over to the ACME-PSH-Core.
I think for all the state which is generated, we should go for single files, since we can allow "multi-threading" then.
Sorry for just writing some thought in an unsorted manner...
No problem, I'm going to close this ticket and you can start exploring ideas in a ticket (or tickets) in that other repo.