minica
minica copied to clipboard
jsha
Name conflict with paultag/minica
Hello,
Currently, running apt install minica under Ubuntu installs a similar binary using the same name: https://github.com/paultag/minica
This was somewhat unexpected. It might be a good idea to include a note about the difference between the two projects in the README.md for others running into this issue.
Thanks! I'd definitely take a PR to the README changing that.
BTW I've seen an increased level of interest in the project recently - out of curiosity, was it posted somewhere?
Good to know! I don't know if I have enough context to provide a PR but I'll see what I can do.
Maybe because it's way less work than using openssl directly? :rofl: Honestly, I'm not sure about the increase. I landed here because another developer used brew install minica in a project and I was trying to get it to work under Linux.
On that note, it would be super helpful to provide an official Docker image. There are a good number of public images on Dockerhub (e.g. https://hub.docker.com/r/ryantk/minica) but without a Dockerfile in this repo, those images are rather questionable.
Sadly, I don't know enough about Go to put one together without digging my heels in. :facepalm:
So, excitingly, Debian packages the (unmaintained upstream) paultag version. I think the major user-facing differences are that that version accepts CN/SNI names as unflagged arguments.
@jsha Would you be open to a patch that made it possible to do minica example.com www.example.com for compatibility, and @tianon is it at all possible to make this version the new maintained upstream of the existing package? (One is MIT and one is Apache, unfortunately.)
Hah, i wasn't tracking this, nor that the other minica was unmaintained. Happy to consolidate given scarce namespace.
Also happy to consolidate, and I think the change you propose, to take hostnames as args rather than flags, should probably be fine. There's another piece of functionality that's probably different: my minica reads its root from minica.pem and minica-key.pem in the current directory, or generates them if they don't exist. I don't know how @paultag's minica does it.
I'm also totally happy to relicense if it makes things easier. I don't have a preference between MIT and Apache.
I'm also happy to relicense between MIT/Expat and Apache 2.0, those are both fine to me. Maybe a fallback if they privkey is missing? We can also try and ship a migration script in the package and suggest using it as long as nothing will get damaged by running it in place. After this is done, I'm happy to archive my repo.
"BTW I've seen an increased level of interest in the project recently - out of curiosity, was it posted somewhere?"
For my part, I came straight here from a link on let's encrypt referencing your project https://letsencrypt.org/docs/certificates-for-localhost/
Oh sweet. I got analysis paralysis trying to make a patch to one of the two libraries in order to provide something resembling compatibility with the other.
Out of curiosity, which one do you use, and how do you invoke it? (manually, script, etc.)
Phil
On Mar 19, 2021, at 09:00, bennydubois @.***> wrote:
"BTW I've seen an increased level of interest in the project recently - out of curiosity, was it posted somewhere?"
For my part, I came straight here from a link on let's encrypt referencing your project https://letsencrypt.org/docs/certificates-for-localhost/
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.