The organization has been slowly building trust in more committers and maintainers and so he's had to personally review many a pull request of mine in the interim. :-D
By restructuring storage--which, may, yes, lead to some operational differences--we can add per-namespace seal mechanisms in our next release (v2.4.0 -- design doc https://github.com/openbao/openbao/issues/1170), giving encryption key separation. Layer that with per-namespace storage engines (or light partitions -- separate tables) and true horizontal _write_ scalability becomes a possibility.
Yep, I have been just reading that for unrelated reasons before happening on the HN post :)
At $DAYJOB I am currently dealing with rather huge Vault Enterprise install with lots and lots of namespaces.
Honestly my biggest question is how compatible using things like kubernetes operators for Vault with OpenBao instead is - it's my main hosting platform across all projects, so very interested in integration stories there
Nice! The biggest gap with Vault Enterprise that I'm hoping we'll get to next release will be horizontal scalability of read requests.
We should be fairly compatible otherwise! Our helm chart just got a few more maintainers (I confess I lack the skills to maintain it, JanMa has been doing a great job there) though we've been relying on the pre-BUSL operator and CSI from upstream due to lack of resources.
Things like ESO and Cert-Manager should just continue to work :-)
If I wasn't virulently anti-helm I'd probably help maintain it, as it is I treat Helm as necessary evil but never write any charts ^^;
Another idea I just had yesterday, and which I've seen partially executed by others, was serverless Vault/OpenBao - the tricks I've seen used various FUSE filesystems, but I wonder if an S3-compatible backend couldn't be added one day :)
We've made an effort to keep API compatibility with Vault wherever possible, also with the new namespaces implementation. Most of the tooling which works with Vault today will also work with OpenBao
GitHub's charts are inaccurate and a quick glance at the commit list would tell you that: https://github.com/openbao/openbao/commits/main/ -- you have to cross some threshhold number of commits across all time in the repository to even appear in that dashboard.
Yes, I contribute a lot, but in the last three months, we've seen substantial interest from other groups (thank you SAP, Reply, Adfinis, and G-Research OSS to name a few!) and have recently promoted a fresh group of committers.
Having worked at HashiCorp, I'm rather proud of what the community has built and proud of our ability to promote external maintainers. Open governance isn't easy for corporate contributions, but it is possible and I thank my employer for letting me try. :-)
Just look at the (narrowing) feature gap and critical improvements we've landed--transactions to name one--to see why I'm optimistic.
I realise GitHub’s graph isn’t necessarily fully representative, but one personal concern is that I don’t know yet how long-term many of these new contributors will be.
That said, I also do applaud the efforts to build a community-driven fork in a similar vein to OpenTofu (which does seem to have critical mass now), and from the sounds of what you’re saying OpenBao is heading in the right direction too.
What's annoying is the one man band projects get popular and then suddenly deciding to throw it away by archiving it on github without giving the chance of others to step in.
Definitely. It's why I've been pushing for open governance and slowly building community's trust in additional maintainers to avoid burnout and ensure continuity.
It's the safe thing to do. If you endorse a fork, and the new maintainer goes rogue, it's on you. Or, let a prevailing fork naturally emerge, and hopefully that vets them a bit in the process.
But the only versions mentioned in [1] that should compile out of the box into Wasm, are the ones that say they use "the Rijndaal reference implementation."
I don't think compiling OpenSSL into Wasm is tenable. But some wrappers around the Go AES implementation should work.
FWIW, most of the code and docs contributions have come from non-IBMers [0]. That said, IBM has done a lot of great work building the foundation and initial community and without them, OpenBao wouldn't be here. :-)
Speaking for myself, but I do not get any monetary compensation from IBM and I suspect this is true for all of the other non-IBM contributors.
Sure, but in general the expected value of a HSM is that (especially in FIPS mode) it prevents extraction and accidental leakage of the keys (and maybe at appliance levels has explicit logging).
If you're sure you never do a plaintext backup or anything else that might leak the key, then it may not matter. But it is a decent defense in depth measure for high assurance operations.
I heard a story once about a CA (public? private? not sure!) that had an airgapped root CA in a basement lab, only for an enterprising admin to run an Ethernet cable between their desk and the basement lab to save themselves a few trips... An online HSM may allow effective leakage (by allowing arbitrary signing operations), but hopefully would prohibit export by a crypto user and retain audit logs of all operations to identify scope of the compromise.
At some point, you end up reinventing an HSM from first principals. :-) My 2c.
It seems to be intentional exfiltration of key material (either bounded DH keypairs rather than ephemeral or, more likely, exfil of the symmetric channel key).
The organization has been slowly building trust in more committers and maintainers and so he's had to personally review many a pull request of mine in the interim. :-D