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).
I don't think anybody would argue that the BUSL is an open source license. OSI has investigated and released a report last year about the business practices similar to what the BUSL uses: https://opensource.org/delayed-open-source-publication
Happy to answer technical questions about OpenBao as people have, though some might be best directed at the Technical Steering Committee, which I do not represent. :-)
Thank you for the RFE! Looking at the X-Forwarded-For handling might be good, I wasn't able to add tests for that easily, though maybe the existing test could be used as a template if you get time. I think we depend on nginx or Caddy elsewhere, but the pkiext tests might also serve as a good reference. :-)
I hoped that I could move from vault to openbao , but it looks like that is not the case.
I can understand the removal of secrets engines and stuff but the storage plugins should’ve been kept at least for the first few releases and than dropped a few of them while giving people a way to migrate them to supported options.
I have a few improvements I'd have liked to have see upstream, but couldn't land due to the vast storage plugin base. You're left writing to the lowest common denominator of 20 storage engines which isn't maintainable when HashiCorp only supports Raft and Consul.
Take paginated lists which I've proposed as a PR. If your backend engine of choice doesn't support efficient pagination aligning with the designated semantics, you're stuck implementing it from scratch. Now do that with transactional storage, which is another upstream requested feature... And so forth.
Additionally, the current contributor base is too small to support much more. Personally, I'd like to see Postgres as the only external storage engine. But I don't presently feel we have enough maintainers to justify multiple storage engines. Raft is easiest to support as it is what upstream is actively developing. It also eases migration for upstream-aligned users.
My 2c. But happy to take suggestions and contributions!
Edit to add: ideally I'd have liked to add an external storage plugin interface, but this would be a bit of a perf hit over native support and wouldn't be a stable target (as I'd like to see some of these things land).
Well with these changes before the first version I would not consider openbao a fork of vault. More like a different product.
Yeah some of these proposed changes are nice. But they shouldn’t be done in the first release if you wanted to take over vault customers.
I will probably never migrate to openbao.
Especially if raft is the only storage option.
And don’t get me wrong you can do that stuff. You do the work, so you guys can do whatever you like.
I think there's many counter examples to this: Jenkins & Hudson, Illumos & Solaris, LibreSSL & OpenSSL & BoringSSL, LibreOffice & OpenOffice, Spongy Castle & Bouncy Castle, and Webkit & KHTML to name a few.
A fork need not necessarily be 1:1, bug for bug, compatible.
But as noted here: https://developer.hashicorp.com/vault/docs/configuration/sto... -- upstream only supports the Raft backend. The other backends may have issues and don't see many commits as upstream has not delegated maintenance to external community members. Frequently, commentators (both employees and community members) suggest moving away from custom storage backends to Raft.
A storage migration only impacts one small category of users -- the operator -- but remains transparent to the consumers of secrets (whether humans or applications). This only occurs once. Yes, it requires planning. Yes, it is a lot of work to execute successfully. But it is also an approach upstream uses e.g., in FIPS 140-2 migrations: https://developer.hashicorp.com/vault/docs/enterprise/fips/f... -- as we get time, we'd like to make this type of cross-instance migration more automated if we can.
But our goal is to remain API compatible, so the vast majority of use cases require no changes to operate with the forked code. And we wish to remain as drop-in compatible with consumers using Raft as we can. So yes, I think OpenBao can still be called a fork of Vault. And IMO, even a 1:1 bug compatible fork is still a separate product, and that isn't necessarily a bad thing. :-)
OpenTofu has much the same approach, where they don't guarantee a 1:1 drop-in, bug-for-bug fork of upstream, but instead gives themselves some room to make changes for the best of their community: https://opentofu.org/docs/language/v1-compatibility-promises...
I think that every project needs to find their own balance, and this is what the OpenBao community has chosen. :-)
My 2c, views my own. But feel free to contact me via email if you have additional technical concerns to discuss.
We had some discussions about this before removing all storage plugins except Raft, In-Memory and File storage as cipherboy pointed out in the sibling comment. If you're currently not using Raft, this should not stop you from adopting OpenBao if you first migrate to the Raft storage backend. Hashicorp has a tutorial on this which you can follow: