user65k / async-acme Goto Github PK

Because async-rustls is currently on rustls 0.19, there are errors when building the example. I found an open issue on that repository, which links to another thread on another project where someone mentions that futures-rustls is preferred.

Should we change this project over, or should we wait on async-rustls to be updated?

The most recent update of this crate updated major dependencies from one version to another, which caused breakage in BonsaiDb due to trying to pass a CertifiedKey produced via this crate to another crate which was still using an older version of rustls.

I can fix this by enforcing that this crate is always hardcoded to a specific patch version, but that prevents users from getting bug fix updates without me releasing a new version.

Can this crate adopt a policy to not update major dependencies, such as rustls, without incrementing the minor version while in 0.x?

First off, thank you so much for this crate and for the quick merges on the pull requests I sent in last night.

I'm building a database which has its own encrypted-at-rest storage available, and I would like to be able to act as the account cache myself. I can manually manage the account and certificates if I drive the process by hand, but I can't use the rustls_helper::order function because that function returns a CertifiedKey which cannot be used to export the private key.

I propose changing the order function to take a trait implementation rather than a Path for the cache, with function calls to load and save accounts and certificates with their keys. The crate can continue to provide a filesystem implementation.

Would you be open to a pull request for this change?