Keygen.jl

[aminya]

Now we have Keygen.jl: https://github.com/aminya/Keygen.jl

Merge when Keygen.jl is registered.
JuliaRegistries/General#15941

Fixes #37
Closes #36 here
Removes Travis deprecation. Fixes #5

Deprecates genkeys in favor of Keygen.documenter_keygen

[mortenpi]

I don't think it really makes sense to split Documenter-specific stuff into a separate package. But if Keygen would provide a neat API for calling ssh-keygen, returning the private and public keys, then I would be happy to depend on it.

[aminya]

The goal is to provide those ssh-keygen APIs, but it is not supposed to be just a low-level package. OpenSSH_jil already provides a low-level API (although less convenient syntax, but essentially the same).

In addition, it plans to have an application layer. The goal is to provide a single package (rather many) that people can use for generating keys for all sorts of applications (e.g Documenter, GitHub secrets, etc). So one go-to package for people, rather many spread all over the globe 😄

PkgTemplates will also use this single Keygen package for generating the keys it needs for its plugins. There is nothing Documenter specific in the code (rather just the key name). The same code could be used for generating the keys needed for one repository.

Note that I will transfer this repo to JuliaCrypto soon.

[mortenpi]

The goal is to provide a single package (rather many) that people can use for generating keys for all sorts of applications (e.g Documenter, GitHub secrets, etc). So one go-to package for people, rather many spread all over the globe

I think that goal makes sense. But at this very moment it Keygen is identical to what we have here, so we'd be spreading out Documenter-related functionality. I feel that we can go in two directions here:

• DocumenterTools keeps providing genkeys, but would use a low-level API from Keygen to call ssh-keygen. Things like base64-encoding the private key etc. would still happen here. (Note: it would be perfectly fine for Keygen to also provide a high-level API to generate Documenter-compatible keys, although it would indeed duplicate the code.)

• Or, Keygen would define a clean generic API for generating SSH keys, with well-defined encoding etc. At that point we could just point Documenter docs to Keygen and just say "You need to upload Keygen-compatible keys to Travis."

Regarding the low-level API: as far as I can tell, OpenSSH_jll just provides the path to ssh-keygen. So the code for calling it, reading outputs and error handling is still quite a fair bit of code that would be good not to duplicate.

[aminya]

Yes, I don't expect this PR to be merged right now, but eventually, it will have the planned implementation. Once done, it will be up to you to use Keygen the way you like, but since I already asked in #37, I made this PR.