Mikhail Zabaluev

Once #1665 is in, `rouille` will be the last obstacle to fixing #1478.

Somewhat ironically, keytar [calls](https://github.com/atom/node-keytar/blob/fd66226fb556a3333c9474b5e56e208724dd6dc7/src/keytar_posix.cc#L55) synchronous functions in libsecret under the hood. I must admit though that integrating asynchronous event loops of node and GLib is not for the faint of...

I think using `tar` from `$PATH` is non-workable in the long run. Not only you get all the problems associated with system-installed tar binaries: https://github.com/actions/virtual-environments/issues/2619, #301, #362, https://github.com/actions/toolkit/issues/479, to reference...

Any progress on this or #473?

I would favor #135 (immutable slots, but the key is computed on the save step, so it can hash resulting state) as a more efficient solution. Choice of the key...

Sorry for cross-posting from RustCrypto/traits#13, just noticed it has been closed: Could you post a brief recap of the serde-related discussion here as well? Is `Serialize` a good fit for...

I think now that a `serde::Serializer` impl tuned with "personality" traits could be an adequate solution, assuming that data type serialization impls do not leak machine-dependent value information into serialized...

Here's my attempt at it: https://github.com/mzabaluev/digest-hash-rs Not publishing on crates.io yet, so as to not spoil the namespace in case the Rust Crypto team finds the crate unsuitable. I'd like...

As I tried to explain in the README, a `Serializer` backend would force all kinds of opinionated data representation choices on the instance of the digest serializer, and these choices...

I have published my crate as [digest-hash](https://crates.io/crates/digest-hash).