What does HackerNews think of clevis?

The threat vector mitigated by Clevis[1] is someone with physical access (e.g. an insider) removing the server from the data center and being able to access its data.

[1] https://github.com/latchset/clevis

Interesting question. I think so?

https://access.redhat.com/documentation/en-us/red_hat_enterp...

Looks like clevis is gpl3 - so I expect it's not packaged as standard for any of the bsds?

https://github.com/latchset/clevis

See also:

Ed: and: https://github.com/kmille/cryptboot

https://security.stackexchange.com/questions/194081/use-tpm2...

https://security.stackexchange.com/questions/39329/how-does-...

https://superuser.com/questions/619721/can-i-use-the-tpm-on-...

Thanks for the link; I hadn't heard of Mandos.

Another solution in the same space is Clevis[1]; last time I was researching this problem, I came across it via Red Hat's docs[2].

[1]: https://github.com/latchset/clevis

[2]: https://access.redhat.com/documentation/en-us/red_hat_enterp...

We are working on a solution to this problem in the Clevis project[0]. It is a basic FUSE filesystem that will transparently decrypt your secrets/configuration. It will evaluate your decryption policy on each open and log the attempt.

You can see the initial proof of concept[1]. It isn't secure yet, for a variety of reasons. But it is enough to play around with. Moving to a better encryption scheme will give us the ability to do locks and per-block validation.

[0]: https://github.com/latchset/clevis [1]: https://github.com/npmccallum/clevis/blob/fuse/src/clevis-fu...