Please note: We take OpenBao's security and our users' trust very seriously. If you believe you have found a security issue in OpenBao, please responsibly disclose by contacting us at openbao-security@lists.openssf.org.
First: if you're unsure or afraid of anything, just ask or submit the issue or pull request anyways. You won't be yelled at for giving it your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions, and don't want a wall of rules to get in the way of that.
That said, if you want to ensure that a pull request is likely to be merged, talk to us! You can find out our thoughts and ensure that your contribution won't clash or be obviated by OpenBao's normal direction. A great way to do this is via the GitHub Discussions.
To view community roles or who holds those roles, see MAINTAINERS.md.
This policy prohibits the utilization or copy from any source that is protected by a source-available license agreement including Business Source License 1.1. This specifically includes all source repository members under the Hashicorp GitHub organization. It is the intention of this policy that when developing for feature parity, bug fixes, CVEs, etc. in comparison to Hashicorp Vault that a clean room methodology be used and all deliverables made original.
OpenBao adheres to the Linux Foundation's DCO.
All contributors are required to confirm their legal rights to the source they
contribute. This is done through a "DCO Sign Off". Note that this is different from
commit signing, such as using PGP or gitsign.
Caution
Disable all generative AI agents while working on OpenBao!
(This includes GitHub Copilot, Cursor, Claude Code, and others.)
Note
By using generative AI agents, you cannot guarantee that you have the full legal rights required to submit the code generated by an AI. We require you use the DCO ownership sign-off, which you cannot do with generative AI agents trained on third-party code.
Use of AI in other capacity (search, discussion, &c) remains fine.
Please do not submit such pull-requests to this project. Thanks!
If you have met the above requirements, you can add your sign-off by including
the --signoff option in your git commit or git rebase commands:
# Sign off a commit
git commit --signoff -m"my commit"
# Add a signoff to the last commit you made
git commit --amend --signoff
# Sign off every commit in your branch
git rebase --signoff mainThis will add a line similar to the following at the end of your commit:
Signed-off-by: Alex Smith <alex@example.com>Signing off a commit signifies your agreement to the terms outlined at https://developercertificate.org/ for that specific contribution. Any contribution that lacks a sign-off to this agreement will not be accepted by the OpenBao project.
| Member | GitHub | Alternate | Company/Organization | TSC Position | |
|---|---|---|---|---|---|
| James Butcher | james@iotechsys.com | Brad Corrion (brad@iotechsys.com) | IOTech Systems | Member | |
| Julian Cassignol | jcassignol@wallix.com | Dan Ghita (dghita@wallix.com) | Wallix | Member | |
| Michael Hofer | michael.hofer@adfinis.com | @karras | Andrii Fedorchuk (andrii.fedorchuk@adfinis.com) | Adfinis | Chair |
| Maw Wildpaner | maw@gitlab.com | Mark Mishaev (mmishaev@gitlab.com) | GitLab | Member | |
| Klaus Kiefer | klaus.kiefer@sap.com | @klaus-sap | Jonas Köhnen (j.koehnen@reply.de) | SAP | Member |
| Alex Scheel | alex.scheel@control-plane.io | @cipherboy | Eugene Davis (eugene.davis@control-plane.io) | ControlPlane | Member |
To view the process for joining the TSC, see GOVERNANCE.md in the root of this repository. That document is considered part of this document.
| Working Group | Chair | Voting Members |
|---|---|---|
| Development Working Group | Alex Scheel | Alex Scheel, Andrii Fedorchuk, Dan Ghita, Dave Dykstra, Huy Dinh, Jan Martens, Jonas Köhnen, Pascal Reeb, Philipp Stehle, Wojciech Slabosz |
This section will cover what we're looking for in terms of reporting issues.
By addressing all the points we're looking for, it raises the chances we can quickly merge or address your contributions.
Caution
Please do not use generative AI to create issues against OpenBao; take the time to comment in your own words. Issues which are very clearly AI generated may be closed and/or locked with no response from the community.
This includes security reports sent to the security mailing list or submitted as GitHub security advisories.
-
Make sure you test against the latest released version. It is possible we already fixed the bug you're experiencing. Even better is if you can test against the
developmentbranch, as the bugs are regularly fixed but new versions are only released every few months. -
Provide steps to reproduce the issue, and if possible include the expected results as well as the actual results. Please provide text, not screen shots!
-
If you are seeing an internal OpenBao error (a status code of 5xx), please be sure to post relevant parts of (or the entire) OpenBao log, as often these errors are logged on the server but not reported to the user.
-
If you experienced a panic, please create a gist of the entire generated crash log for us to look at. Double check no sensitive items were in the log.
-
Respond as promptly as possible to any questions made by the OpenBao team to your issue.
-
Use of generative AI as an assistant in debugging or understanding issues remains okay, but please do not post AI generated text, especially without clearly identifying it as such.
-
Refer to our security policy for context on our responsible disclosure procedure.
-
The issue is reported.
-
The issue is verified and categorized by an OpenBao collaborator. Categorization is done via tags. For example, bugs are marked as "bugs".
-
Unless it is critical, the issue may be left for a period of time (sometimes many weeks), giving outside contributors -- maybe you!? -- a chance to address the issue.
-
The issue is addressed in a pull request or commit. The issue will be referenced in the commit message so that the code that fixes it is clearly linked.
-
The issue is closed.
-
Issues that are not reproducible and/or not gotten responses for a long time are stale issues. In order to provide faster responses and better engagement with the community, we strive to keep the issue tracker clean and the issue count low. In this regard, our current policy is to close stale issues after 30 days. Closed issues will still be indexed and available for future viewers. If users feel that the issue is still relevant, we encourage reopening them.
Caution
Pull requests which ignore our template especially from first-time contributors risk being rejected with no explanation. All pull requests from new and existing contributors should have the Acknowledgements section filled out.
In particular, see the note above (in DCO sign-off) about not using generative AI for code generation. This also includes the PR and/or issue description.
When submitting a PR you should reference an existing issue. If no issue already exists, please create one. This can be skipped for trivial PRs like fixing typos or for backports.
Creating an issue in advance of working on the PR can help to avoid duplication of effort, e.g. maybe we know of existing related work. Or it may be that we can provide guidance that will help with your approach.
Your pull request should have a description of what it accomplishes, how it does so, and why you chose the approach you did. PRs should include unit tests that validate correctness and the existing tests must pass. Follow-up work to fix tests does not need a fresh issue filed.
Someone will do a first pass review on your PR making sure it follows the guidelines in this document. If it doesn't we'll mark the PR incomplete and ask you to follow up on the missing requirements.
For original PRs slated for backport, ask or apply for the following labels:
backport-<version>targeting the desired backport branch; andneeds-backport, to indicate the backport has not yet been performed.
In the backport PR, please link the original pull request in the commit
title, which will in turn let us find the original issue. When possible,
backport the merged (squashed) commit rather than the source PR's
commits. This will automatically link it to the original pull request.
When all backport PRs are opened, remove the needs-backport label from
the original PR. Do not open backports before the original PR is merged.
The backport PRs should have all the other non-backport-related labels of
the original PR.
The milestone on the original PR should target the current main branch
milestone. The milestone on the backport PR should target the backport
branch's next milestone. The milestone on the issue (if applicable) should
target the oldest series's milestone.
Please include a file within your PR named changelog/#.txt, where # is your
pull request ID. There are many examples under changelog, but
the general format is
```release-note:CATEGORY
COMPONENT: summary of change
```CATEGORY is one of security, change, feature, improvement, or bug.
Your PR is almost certain to be one of bug or improvement, but don't
worry too much about getting it exactly right, we'll tell you if a change is
needed.
To determine the relevant component, consult CHANGELOG and pick whichever one you see that seems the closest match.
You do not need to include the link at the end of the summary that appears in CHANGELOG.md, those are generated automatically by the changelog-building process.
PRs might only be merged once all the following conditions are met:
- Codeowner rules must be satisfied (as defined in the repos
CODEOWNERSfile). See examples below. - At least one qualified review must be done by someone from a different organization than the PR author. "Qualified" means someone with write access to the repo (As of today, GitHub indicates this with a green check-mark next to the reviewer name as opposed to a gray check-mark for non-qualified reviews). Independent contributors are considered to be a one person organization here. If organization A pays organization B for contributing to OpenBao, they will be considered to be the same organization.
- All review comments are resolved.
The preferred person to actually hit the merge button is the author of the PR, if they have the required permissions to do so, as they are expected to be aware of any inter-PR dependencies (e.g. a feature PR depending on a bug-fix from a different PR).
Given the following CODEOWNERS file:
component-a/ @a-team @core-team
component-b/ @b-team @core-team
component-c/ @c-team @core-teamAnd a PR that touches files in component-a and component-b, the PR will need
a review from either:
- Two people, one member of the
a-teamand one member of theb-team - One person, who is a member of both the
a-teamand theb-team - One person, who is a member of the
core-team
Also, in the CODEOWNERS only the last matching pattern applies to a file. For example:
component-a/ @a-team
component-a/subcomponent-alpha @alpha-teamIn a PR that only changes component-a/subcomponent-alpha/, you will need a
review from the alpha-team, but not from the a-team.
This rules should reflect the documented behavior of GitHub.
How you contribute to the UI depends on what you want to contribute. If that is a new feature, please submit an informational issue first. That issue should include a short description of the proposed feature, the use case, the approach you're taking, and the tests that would be written. A mockup is optional but encouraged.
Bug fixes are welcome in PRs but existing tests must pass and updated logic should be handled in new tests. You needn't submit an issue first to fix bugs.
Keep in mind that the UI should be consistent with other areas of OpenBao. The UI should be user-centered, informative, and include edge cases and errors— including accommodations for users who may not have permissions to view or interact with your feature. If you are not comfortable with UI design, an OpenBao designer can take a look at your work— just be aware that this might mean it will add some time to the PR process.
Finally, in your code, try to avoid logic-heavy templates (when possible, calculate values in the .js file instead of .hbs) and Ember anti-patterns. And most of all, if you have any questions, please ask!
If you have never worked with Go before, you will have to complete the following steps listed in the README, under the section Developing OpenBao.