cipherboy

Vault has had PKI since pre-v1; ACME was introduced in 2022 to modernize its APIs.

I'll bite ;-) Appreciate your replies as always tptacek!

It is a fair criticism. But I think two things give us an advantage here:

1. IBM started this fork and later bought HashiCorp, with the acquisition having fully completed. I've broached the subject with both sides post-acquisition but got only a negative response from the HashiCorp side and no response from IBM. We are very much a known entity to the teams that matter inside IBM. And I'd posit within HashiCorp as well given I came out of their Vault Crypto team. ;-)

Whether IBM wishes to cooperate is a different matter. Mentioning again, publicly, doesn't hurt and hopefully raises awareness to researchers (such as yourself!).

2. The Linux Foundation's OpenSSF (our umbrella foundation) has a reputation which we try our best to uphold. Obviously they'd be rightfully upset if we shared pre-disclosure vulnerabilities widely. So we won't and don't. Certainly the broader Linux distribution security list is a positive model in this regard.

If this were J. Doe's pet fork of $CRITICAL_SOFTWARE, 100% agree. But the fork is neither new nor lacking in reputation of its component/parent entities, so I'd hope researchers give us the same consideration they would any other of LF's forks (Valkey, OpenSearch, OpenTofu, ...).

But that said, I've personally disclosed vulnerabilities post-fork to HashiCorp and have mentioned to them that I have stopped future disclosures without a further agreement. This just leads to a two-party zero-day vulnerability race, which is not in anyone's best interest.

Yes and https://discuss.hashicorp.com/t/hcsec-2024-05-vault-cert-aut... was an earlier authN+authZ bypass in the same code block.

So maybe one step down in severity, though I do not know the details of what HCSEC-2024-05 was fixed with as that was after the fork point. OpenBao moved to full cert pinning (constant-time cert.Raw comparisons) when remediating that one, which meant we were not affected by this variant.

Since HashiCorp and OP did not opt to disclose to OpenBao, the most authoritative source right now is HashiCorp's security tracker, linked down-thread: https://news.ycombinator.com/item?id=44821779

https://discuss.hashicorp.com/tag/security-vault is the aggregate link, with HCSEC-2025-[13..22] being the relevant topics.

I will be working shortly to acquire additional CVE numbers for OpenBao for the 8 affected issues.

HCSEC-2025-18 / CVE-2025-6037 (core user confusion bug) does not affect OpenBao.

In general, our release notes detail fixed security issues: https://openbao.org/docs/release-notes/2-3-0/ per policy https://github.com/openbao/.github/blob/main/SECURITY.md. This also has contact information if anyone wishes to discuss additional new security issues.

To quote a movie, only a Sith deals in absolutes ;-)

The OpenBao community call is in 10 minutes if you want to talk more about it live: https://calendar.google.com/calendar/embed?src=s63voefhp5i9p... (OpenSSF community calendar link).

But, the short answer why I say _reasonably_ sure is because HashiCorp and the OP haven't released a lot of details about exactly what case(s) are affected, so there's only so much we can do except look at our own code and infer what we can and make an educated guess.

So, barring some structural problem I'm not immediately aware of, I have reasonably high confidence based on discussions amongst the community members.

OpenBao, under the Linux Foundation's OpenSSF, is making meaningful improvements to the code. I'd love to have high-quality reports, if you're willing to re-visit these. :-)

I do not speak for HashiCorp, but they have published information on this CVE here: https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enu...

OpenBao is reasonably confident in our fix: https://github.com/openbao/openbao/pull/1628

We had earlier pulled support for pre-Vault-1.0 userpass pre-bcrypt hashing (so there's no longer a timing difference there that could be used for enumeration) and using cache busting on lookup should also ensure consistency across storage layers. Plus, normalizing the remaining error messages through when the user's credential is fully validated as correct.

For anyone interested in CVE-2025-6010: https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enu...

On behalf of the OpenBao project, I welcome collaboration with future researchers. We were not informed of these vulnerabilities before HashiCorp posted their usual CVE bulletins, which is disappointing. (Especially as HashiCorp's Vault no longer has an Open Source edition ;-)

We've triaged as being affected by 8 of the 9 CVEs (in fixing an earlier Cert Auth vulnerability, we correctly remediated this one) and have merged patches for most of them.

Happily, the community has done some great work on remediating these and I'm very appreciative of them.

I'm most excited about the audit changes: this was the impetus needed to make them be configuration driven in the next release series. Leaving audit device (which, as a reminder, have a socket mode which can make arbitrary TCP calls!) open to API callers is rather unsafe, even with prefix being limited.

(Edit: And of course it goes without saying, but we're more than happy to accept contributions to the community -- code, docs, technical, or otherwise!)

Dupe of https://news.ycombinator.com/item?id=44276916

While I'm sure Vault contracts run more than what I'd care to know, the project is set up under the Linux Foundation and I've been told in the past that we as a project are capable of receiving direct donations.

If you're so inclined, please do!

We'd of course be appreciative of it, but that said, the OpenBao TSC had tabled conversations about just what we'd spend any funds on until after we moved into the OpenSSF... Which just concluded which means it might be time to get things moving again. But just to say, we may not immediately know what we'd spend any donations on. :-)

(Alternatively, hiring and retaining a maintainer or a firm working on it would also be good options. Part of the growth requirements of OpenSSF projects is to have more than a handful of companies on project leadership so increasing diversity is a key goal.)

Not without community involvement :-)

Horizontal scalability and disaster recovery is one of the next larger features on our mind. We won't use the architecture of Performance Secondaries, and likely will transparently upgrade (existing) Standby nodes to become read-scalable. Local storage is interesting, but brings with it additional complexity that few need. Better to use namespaces with distinct storage backends (distributing active across all nodes in a cluster) to scale writes horizontally across different namespaces before looking at horizontal scalability of a single mount (which is all that local storage gives you -- it doesn't give you write scalability across namespaces).

Also on that list is external key support, similar to managed keys from Vault Enterprise, but with different configuration semantics: https://github.com/openbao/openbao/pull/1320

We currently have no plans for implementing some of the enterprise secrets bcakends (KMIP, Transform/Tokenization, KMSE, ...) though of course would be welcoming to these as well. Sync is another area that is not in the cards for the short-term.

In terms of differentiation, we have a lot of unique RFCs in-flight that I presume are not on Vault Enterprise's immediate roadmap:

- https://github.com/openbao/openbao/pull/1365 -- starting plans for a UI rewrite and high-level feature requirements

- https://github.com/openbao/openbao/pull/1357 -- per-namespace seal mechanisms

- https://github.com/openbao/openbao/issues/769 -- Restrict LIST+SCAN (recursive) to only accessible entries

- https://github.com/openbao/openbao/pull/1304 -- static key auto-unseal, to aid chaining in trusted environments

- https://github.com/openbao/openbao/pull/1341 -- declarative one-time self-initialization to aid setup

- https://github.com/openbao/openbao/pull/1302 -- inline authentication rather than existing ahead-of-time token-based authentication

and probably more I'm missing.

Feel free to reach out if you want to discuss more or contribute in any way -- we welcome more than just code contributions, there's many ways one can help. :-)

Yes, implemented from scratch by the community but (mostly--barring one reported issue) the same functionality and behavior. Not storage-level compatible, we (likely?) made different storage layout decisions that I'm rather hopeful will set us up nicely for future technical improvements above and beyond Vault Enterprise.

You should read this RFC: https://github.com/openbao/openbao/issues/1340

If you use that with a PostgreSQL backend (which doesn't require raft and has faster leader changes), it might be possible.

Feel free to drop me a mail as well, email is in my profile.

It is a secrets manager; I think it's a fair question.

Very few individuals will want to run them, the reality is they're mostly for businesses to consume. Businesses need maintenance reliability and continuity plans and that's why I've been pushing on the project's governance aspects for a while.

We're not the next TikTok or JS framework so there'll be no flash point of popularity. Just have to put in the work and see where it goes. :-)

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.

You can see maintainer process here: https://github.com/openbao/openbao/blob/main/MAINTAINERS.md

And TSC processes here: https://github.com/openbao/openbao/blob/main/GOVERNANCE.md

Earlier this month, we moved from LF Edge to OpenSSF to better align with our umbrella foundation and hopefully reach more people.

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 :-)

AWS plugins are released separately: https://github.com/openbao/openbao-plugins/releases

Yes, a big thank you to you, Jan, in particular!

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

If you have reproducers for behavioral differences, happy to take issues and PRs!

(Entities was discussed here: https://github.com/openbao/openbao/issues/1110#issuecomment-...)

Right, check out our vision post as well: https://openbao.org/blog/vision-for-namespaces/

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.

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.

https://insights.linuxfoundation.org/project/openbao-2/repos... is a more accurate view.

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.

The combination of paginated list (last release) and transactions (this release) are a wonderful improvement over HashiCorp Vault. They're already paying dividends with the potential to implement much-requested improvements to Vault like recursive keys (https://github.com/openbao/openbao/issues/549 -- in https://github.com/hashicorp/vault/issues/5275, the first-most upvoted issue), list filtering (https://github.com/openbao/openbao/issues/769 -- in https://github.com/hashicorp/vault/issues/5362, the fourth-most upvoted issue), and more.

Which reference AES implementation? My memory is that the one from the spec has terrible timing side channel attacks... e.g. https://www.redhat.com/en/blog/its-all-question-time-aes-tim... seems to corroborate my memory.

I seem to recall this was remotely exploitable, and exploiting timing side channels has only gotten better since 2014.

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.

[0] https://github.com/openbao/openbao/releases/tag/v2.0.0-alpha...

And OpenBao's fork of Vault. There are non-IBM companies on the TSC.

That looks like a(n unofficial) fork, not contributions to the official upstream repository.

Citation needed? https://github.com/facebook/zstd/commits/dev/?author=jiaT75

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.

As an example, an offline PKI root backed by a picohsm would be fast enough, given intermediates aren't typically minted that frequently.

https://csrc.nist.gov/pubs/sp/1800/37/2prd

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).