Since it is planned to add a "standalone" feature that will replace
OpenSSL by crates not linking to any external library, it is required to
abstract all the OpenSSL specific types. This is a huge work and
therefore is divided in several steps. This first one is dedicated to
public and private keys.
rel #2
Sometimes, grep is used to find the TODO comments. Without the proper
explanation, it is hard to know what it refers to (-C / --context may
produce a too large output).
There is use-cases where a command's standard input should be filled
with a file's content. In order to stay consistent with the names of the
other fields, `stdin` is now the field which accepts such a path.
`stdin_str` has been created in order to also support the use of a raw
string.
Cleaning hooks after the certificate has been retrieved is a mistake
since a failure somewhere in the process will prevent all called hook to
be cleaned. With the current implementation, only the currently failed
hook is left without being cleaned.
Sometimes, you want hooks to use different parameters depending on the
certificate. In order to achieve this, it is now now possible to
configure environment variables at certificate scope.
Thanks to this, the default hooks have been rewrote in order to use
cover more use cases.
Orders and authorization can both contain an error which can, for
example, help an user to fix a broken hook. It is therefore very useful
to display it.
Plus, when pooling one of those objects, having an error does not mean
we should stop pooling since the error may be temporary.
At some point, someone may add new domains to an existing certificate.
In such case, this certificate should be renewed as soon as possible
instead of upon expiration.
If a configuration field has a typo in its name, the configuration
should show an error message instead of silently ignoring this field,
which could create unwanted behavior.
If someone used the example the way it was defined, file-access issues
may arise. This new example add two new hooks to fix it. The example
should now work in most environment although the path may need to be
adapted.
Documentation is a crucial point for every project, and the most
effective and traditional way to document a program is to write man
page. Here, the mdoc is used because it is simple.
Because the documentation is quite different from the project itself,
the man pages and others helpful files are distributed under a different
license. For this usage, the GNU All-Permissive License is adequate.
https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html
man 7 groff_mdoc