From 6a0f3401cb7d1ee0d3d10372d487bb3e189bafa0 Mon Sep 17 00:00:00 2001 From: Stephen Curran Date: Thu, 30 Jul 2026 10:43:52 -0700 Subject: [PATCH 1/2] Fix License to be Apache 2.0 and OWF-ize other governance documents Signed-off-by: Stephen Curran --- CODE_OF_CONDUCT.md | 167 +------------------------------------- CONTRIBUTING.md | 7 +- GOVERNANCE.md | 6 +- LICENSE-APACHE => LICENSE | 0 LICENSE-MIT | 23 ------ MAINTAINERS.md | 95 ++++++++-------------- README.md | 24 ++---- SECURITY.md | 138 +++++++++++++++++++++++++++---- 8 files changed, 174 insertions(+), 286 deletions(-) rename LICENSE-APACHE => LICENSE (100%) delete mode 100644 LICENSE-MIT diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 82defcd4..31c616d4 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,166 +1,7 @@ -# [Hyperledger Code of Conduct](https://wiki.hyperledger.org/community/hyperledger-project-code-of-conduct) +# Askar Code of Conduct Policy -Hyperledger is a collaborative project at The Linux Foundation. It is an open-source and open -community project where participants choose to work together, and in that process experience -differences in language, location, nationality, and experience. In such a diverse environment, -misunderstandings and disagreements happen, which in most cases can be resolved informally. In rare -cases, however, behavior can intimidate, harass, or otherwise disrupt one or more people in the -community, which Hyperledger will not tolerate. +The Askar project uses the [LF Europe Code of Conduct], which can be found by clicking "Code of Conduct" in the table of contents of the [LF Europe Policies] PDF document. -A **Code of Conduct** is useful to define accepted and acceptable behaviors and to promote high -standards of professional practice. It also provides a benchmark for self evaluation and acts as a -vehicle for better identity of the organization. +[LF Europe Policies]: https://www.linuxfoundation.org/hubfs/lfeu_policies_exhibitb_051024b.pdf?hsLang=en -This code (**CoC**) applies to any member of the Hyperledger community – developers, participants in -meetings, teleconferences, mailing lists, conferences or functions, etc. Note that this code -complements rather than replaces legal rights and obligations pertaining to any particular -situation. - -## Statement of Intent - -Hyperledger is committed to maintain a **positive** [work environment](#work-environment). This -commitment calls for a workplace where [participants](#participant) at all levels behave according -to the rules of the following code. A foundational concept of this code is that we all share -responsibility for our work environment. - -## Code - -1. Treat each other with [respect](#respect), professionalism, fairness, and sensitivity to our many - differences and strengths, including in situations of high pressure and urgency. - -2. Never [harass](#harassment) or [bully](#workplace-bullying) anyone verbally, physically or - [sexually](#sexual-harassment). - -3. Never [discriminate](#discrimination) on the basis of personal characteristics or group - membership. - -4. Communicate constructively and avoid [demeaning](#demeaning-behavior) or - [insulting](#insulting-behavior) behavior or language. - -5. Seek, accept, and offer objective work criticism, and [acknowledge](#acknowledgement) properly - the contributions of others. - -6. Be honest about your own qualifications, and about any circumstances that might lead to conflicts - of interest. - -7. Respect the privacy of others and the confidentiality of data you access. - -8. With respect to cultural differences, be conservative in what you do and liberal in what you - accept from others, but not to the point of accepting disrespectful, unprofessional or unfair or - [unwelcome behavior](#unwelcome-behavior) or [advances](#unwelcome-sexual-advance). - -9. Promote the rules of this Code and take action (especially if you are in a - [leadership position](#leadership-position)) to bring the discussion back to a more civil level - whenever inappropriate behaviors are observed. - -10. Stay on topic: Make sure that you are posting to the correct channel and avoid off-topic - discussions. Remember when you update an issue or respond to an email you are potentially - sending to a large number of people. - -11. Step down considerately: Members of every project come and go, and the Hyperledger is no - different. When you leave or disengage from the project, in whole or in part, we ask that you do - so in a way that minimizes disruption to the project. This means you should tell people you are - leaving and take the proper steps to ensure that others can pick up where you left off. - -## Glossary - -### Demeaning Behavior - -is acting in a way that reduces another person's dignity, sense of self-worth or respect within the -community. - -### Discrimination - -is the prejudicial treatment of an individual based on criteria such as: physical appearance, race, -ethnic origin, genetic differences, national or social origin, name, religion, gender, sexual -orientation, family or health situation, pregnancy, disability, age, education, wealth, domicile, -political view, morals, employment, or union activity. - -### Insulting Behavior - -is treating another person with scorn or disrespect. - -### Acknowledgement - -is a record of the origin(s) and author(s) of a contribution. - -### Harassment - -is any conduct, verbal or physical, that has the intent or effect of interfering with an individual, -or that creates an intimidating, hostile, or offensive environment. - -### Leadership Position - -includes group Chairs, project maintainers, staff members, and Board members. - -### Participant - -includes the following persons: - -- Developers -- Member representatives -- Staff members -- Anyone from the Public partaking in the Hyperledger work environment (e.g. contribute code, - comment on our code or specs, email us, attend our conferences, functions, etc) - -### Respect - -is the genuine consideration you have for someone (if only because of their status as participant in -Hyperledger, like yourself), and that you show by treating them in a polite and kind way. - -### Sexual Harassment - -includes visual displays of degrading sexual images, sexually suggestive conduct, offensive remarks -of a sexual nature, requests for sexual favors, unwelcome physical contact, and sexual assault. - -### Unwelcome Behavior - -Hard to define? Some questions to ask yourself are: - -- how would I feel if I were in the position of the recipient? -- would my spouse, parent, child, sibling or friend like to be treated this way? -- would I like an account of my behavior published in the organization's newsletter? -- could my behavior offend or hurt other members of the work group? -- could someone misinterpret my behavior as intentionally harmful or harassing? -- would I treat my boss or a person I admire at work like that ? -- Summary: if you are unsure whether something might be welcome or unwelcome, don't do it. - -### Unwelcome Sexual Advance - -includes requests for sexual favors, and other verbal or physical conduct of a sexual nature, where: - -- submission to such conduct is made either explicitly or implicitly a term or condition of an - individual's employment, -- submission to or rejection of such conduct by an individual is used as a basis for employment - decisions affecting the individual, -- such conduct has the purpose or effect of unreasonably interfering with an individual's work - performance or creating an intimidating hostile or offensive working environment. - -### Workplace Bullying - -is a tendency of individuals or groups to use persistent aggressive or unreasonable behavior (e.g. -verbal or written abuse, offensive conduct or any interference which undermines or impedes work) -against a co-worker or any professional relations. - -### Work Environment - -is the set of all available means of collaboration, including, but not limited to messages to -mailing lists, private correspondence, Web pages, chat channels, phone and video teleconferences, -and any kind of face-to-face meetings or discussions. - -## Incident Procedure - -To report incidents or to appeal reports of incidents, send email to Mike Dolan -(mdolan@linuxfoundation.org) or Angela Brown (angela@linuxfoundation.org). Please include any -available relevant information, including links to any publicly accessible material relating to the -matter. Every effort will be taken to ensure a safe and collegial environment in which to -collaborate on matters relating to the Project. In order to protect the community, the Project -reserves the right to take appropriate action, potentially including the removal of an individual -from any and all participation in the project. The Project will work towards an equitable resolution -in the event of a misunderstanding. - -## Credits - -This code is based on the -[W3C’s Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc) with some -additions from the [Cloud Foundry](https://www.cloudfoundry.org/)‘s Code of Conduct. \ No newline at end of file +Let's all be good to one another! diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ba21f22c..2448f6b6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,4 @@ -## How to contribute +# How to contribute You are encouraged to contribute to the repository by **forking and submitting a pull request**. @@ -6,8 +6,9 @@ For significant changes, please open an issue first to discuss the proposed chan (If you are new to GitHub, you might start with a [basic tutorial](https://help.github.com/articles/set-up-git) and check out a more detailed guide to [pull requests](https://help.github.com/articles/using-pull-requests/).) -Pull requests will be evaluated by the repository guardians on a schedule and if deemed beneficial will be committed to the main branch. Pull requests should have a descriptive name and include an summary of all changes made in the pull request description. +Pull requests will be evaluated by the repository guardians on a schedule and if deemed beneficial will be committed to the `main` branch. Pull requests should have a descriptive name, include a summary of all changes made in the pull request description, and include unit tests that provide good coverage of the feature or fix. A Continuous Integration (CI) pipeline is executed on all PRs before review and contributors are expected to address all CI issues identified. Where appropriate, PRs that impact the +end-user and developer demos in the repo should include updates or extensions to those demos to cover the new capabilities. If you would like to propose a significant change, please open an issue first to discuss the work with the community. -Contributions are made pursuant to the Developer's Certificate of Origin, available at [https://developercertificate.org](https://developercertificate.org), and licensed under the Apache License, version 2.0 (Apache-2.0). +Contributions are made pursuant to the Developer's Certificate of Origin, available at [https://developercertificate.org](https://developercertificate.org), and licensed under the [Apache License, version 2.0](LICENSE) (Apache-2.0). diff --git a/GOVERNANCE.md b/GOVERNANCE.md index ebd34b7e..3d4adac0 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -6,8 +6,6 @@ Anywhere you would like to make a change, please add a comment **in the google d Once the maintainers provide comments and approve, LF Project Formation will finalize the document. We can then update GOVERNANCE.md with the PDF of the charter. -Per the Linux Foundation, +Per the Linux Foundation, -*A technical charter is created for all new projects to define both the project operations and the IP policy. -We have proposed technical oversight for the project that falls to a “Technical Steering Committee” made up of the project’s committers. -At a later date the TSC is free to evolve how membership on the TSC is determined to accommodate project growth and the evolution of its governance.* +*A technical charter is created for all new projects to define both the project operations and the IP policy. We have proposed technical oversight for the project that falls to a “Technical Steering Committee” made up of the project’s maintainers. At a later date the TSC is free to evolve how membership on the TSC is determined to accommodate project growth and the evolution of its governance.* diff --git a/LICENSE-APACHE b/LICENSE similarity index 100% rename from LICENSE-APACHE rename to LICENSE diff --git a/LICENSE-MIT b/LICENSE-MIT deleted file mode 100644 index 31aa7938..00000000 --- a/LICENSE-MIT +++ /dev/null @@ -1,23 +0,0 @@ -Permission is hereby granted, free of charge, to any -person obtaining a copy of this software and associated -documentation files (the "Software"), to deal in the -Software without restriction, including without -limitation the rights to use, copy, modify, merge, -publish, distribute, sublicense, and/or sell copies of -the Software, and to permit persons to whom the Software -is furnished to do so, subject to the following -conditions: - -The above copyright notice and this permission notice -shall be included in all copies or substantial portions -of the Software. - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF -ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED -TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A -PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT -SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY -CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION -OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR -IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER -DEALINGS IN THE SOFTWARE. diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 3a49d58f..01411279 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -2,42 +2,14 @@ ## Maintainer Scopes, GitHub Roles and GitHub Teams -Maintainers are assigned the following scopes in this repository: - -| Scope | Definition | GitHub Role | GitHub Team | -| ---------- | ------------------------ | ----------- | ----------------------------------- | -| Admin | | Admin | [aries-admins] | -| Maintainer | The GitHub Maintain role | Maintain | [aries-askar committers] | -| Maintainer | The GitHub Maintain role | Maintain | [aries committers] | -| Read | The GitHub Read role | Read | [Aries Contributors] | -| Read | The GitHub Read role | Read | [TOC] | - -[aries-admins]: https://github.com/orgs/hyperledger/teams/aries-admins -[aries-cloudagent-python committers]: https://github.com/orgs/hyperledger/teams/aries-cloudagent-python-committers -[aries-askar committers]: https://github.com/orgs/hyperledger/teams/aries-askar-committers -[Aries Contributors]: https://github.com/orgs/hyperledger/teams/aries-contributors -[TOC]: https://github.com/orgs/hyperledger/teams/toc - -## Active Maintainers - - - -| GitHub ID | Name | Scope | LFID | Discord ID | Email | Company Affiliation | -| --------------- | ----------------- | ---------- | ---- | ---------- | ------------------------ | ------------------- | -| andrewwhitehead | Andrew Whitehead | Admin | | | cywolf@gmail.com | BC Gov | -| dbluhm | Daniel Bluhm | Admin | | | daniel@indicio.tech | Indicio PBC | -| blu3beri | Berend Sliedrecht | Maintainer | | | berend@animo.id | Animo Solutions | -| dhh1128 | Daniel Hardman | Admin | | | daniel.hardman@gmail.com | Provident | -| ianco | Ian Costanzo | Maintainer | | | iancostanzo@gmail.com | Anon Solutions | -| nage | Nathan George | Maintainer | | | nathang@kiva.org | Kiva | -| swcurran | Stephen Curran | Admin | | | swcurran@cloudcompass.ca | BC Gov | -| WadeBarnes | Wade Barnes | Admin | | | wade@neoterictech.ca | BC Gov | - -## Emeritus Maintainers - -| Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation | -|----- | --------- | ----- | ---- | ---------- | ----- | ------------------- | -| | | | | | | | +The Maintainers of this repo, defined as GitHub users with escalated privileges +in the repo, are managed in the OpenWallet Foundation "governance" repo's [access-control.yaml](https://github.com/openwallet-foundation/governance/blob/main/config.yaml) file. Consult that to see: + +- What teams have escalated privileges to this repository. +- What GitHub roles those teams have in the repository. +- Who are the members of each of those teams. + +The actions covered below for [becoming](#becoming-a-maintainer) and [removing](#removing-maintainers) are made manifest through PRs to that file. ## The Duties of a Maintainer @@ -57,10 +29,10 @@ Maintainers are expected to perform the following duties for this repository. Th - Maintain the repository CONTRIBUTING.md file and getting started documents to give guidance and encouragement to those wanting to contribute to the product, and those wanting to become maintainers. - Contribute to the product via GitHub Pull Requests. -- Monitor requests from the Hyperledger Technical Oversight Committee about the -contents and management of Hyperledger repositories, such as branch handling, +- Monitor requests from the OpenWallet Foundation Technical Advisory Council about the +contents and management of [OpenWallet Foundation](https://github.com/openwallet-foundation) repositories, such as branch handling, required files in repositories and so on. -- Contribute to the Hyperledger Project's Quarterly Report. +- Contribute to the Askar Project's Annual Reports to the OpenWallet Foundation Technical Advisory Council. ## Becoming a Maintainer @@ -71,18 +43,18 @@ occur, roughly in order. - The proposed maintainer establishes their reputation in the community, including authoring five (5) significant merged pull requests, and expresses an interest in becoming a maintainer for the repository. -- A PR is created to update this file to add the proposed maintainer to the list of active maintainers. -- The PR is authored by an existing maintainer or has a comment on the PR from an existing maintainer supporting the proposal. -- The PR is authored by the proposed maintainer or has a comment on the PR from the proposed maintainer confirming their interest in being a maintainer. - - The PR or comment from the proposed maintainer must include their +- An issue is created to add the proposed maintainer to the list of active maintainers. +- The issue is authored by an existing maintainer or has a comment on the PR from an existing maintainer supporting the proposal. +- The issue is authored by the proposed maintainer or has a comment on the issue from the proposed maintainer confirming their interest in being a maintainer. + - The issue or comment from the proposed maintainer must include their willingness to be a long-term (more than 6 month) maintainer. -- Once the PR and necessary comments have been received, an approval timeframe begins. -- The PR **MUST** be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome. -- The PR is merged and the proposed maintainer becomes a maintainer if either: - - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR - - An absolute majority of maintainers have approved the PR. -- If the PR does not get the requisite PR approvals, it may be closed. -- Once the add maintainer PR has been merged, any necessary updates to the GitHub Teams are made. +- Once the issue and necessary comments have been received, an approval timeframe begins. +- The issue **MUST** be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome. +- The issue is approved and the proposed maintainer becomes a maintainer if either: + - Two weeks have passed since at least three (3) Maintainer issue approvals have been recorded, OR + - An absolute majority of maintainers have approved the issue. +- If the issue does not get the requisite approvals, it may be closed. +- Once the add maintainer issue has been approved, the necessary updates to the GitHub Teams are made via a PR to the OpenWallet Foundation "governance" repo's [access-control.yaml](https://github.com/openwallet-foundation/governance/blob/main/config.yaml) file. ## Removing Maintainers @@ -101,17 +73,18 @@ maintainer to emeritus status. This can occur in the following situations: - Other circumstances at the discretion of the other Maintainers. The process to move a maintainer from active to emeritus status is comparable to the process for adding a maintainer, outlined above. In the case of voluntary -resignation, the Pull Request can be merged following a maintainer PR approval. If the removal is for any other reason, the following steps **SHOULD** be followed: - -- A PR is created to update this file to move the maintainer to the list of emeritus maintainers. -- The PR is authored by, or has a comment supporting the proposal from, an existing maintainer or Hyperledger GitHub organization administrator. -- Once the PR and necessary comments have been received, the approval timeframe begins. -- The PR **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists. -- The PR is merged and the maintainer transitions to maintainer emeritus if: - - The PR is approved by the maintainer to be transitioned, OR - - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR - - An absolute majority of maintainers have approved the PR. -- If the PR does not get the requisite PR approvals, it may be closed. +resignation, the Pull Request can be merged following a maintainer issue approval. If the removal is for any other reason, the following steps **SHOULD** be followed: + +- An issue is created to move the maintainer to the list of emeritus maintainers. +- The issue is authored by, or has a comment supporting the proposal from, an existing maintainer or OpenWallet Foundation GitHub organization administrator. +- Once the issue and necessary comments have been received, the approval timeframe begins. +- The issue **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists. +- The issue is approved and the maintainer transitions to maintainer emeritus if: + - The issue is approved by the maintainer to be transitioned, OR + - Two weeks have passed since at least three (3) Maintainer issue approvals have been recorded, OR + - An absolute majority of maintainers have approved the issue. +- If the issue does not get the requisite approvals, it may be closed. +- Once the remove maintainer issue has been approved, the necessary updates to the GitHub Teams are made via a PR to the OpenWallet Foundation "governance" repo's [access-control.yaml](https://github.com/openwallet-foundation/governance/blob/main/config.yaml) file. Returning to active status from emeritus status uses the same steps as adding a new maintainer. Note that the emeritus maintainer already has the 5 required diff --git a/README.md b/README.md index c69b1871..4a983905 100644 --- a/README.md +++ b/README.md @@ -26,13 +26,12 @@ The name Askar (from the Arabic askar, meaning "guard" or "soldier") is used because of the "guard" reference, and because it is an alternate name for the star [Hamal in the constellation of Aries], the 50th brightest star in our sky. -[Hyperledger Aries]: https://www.hyperledger.org/projects/aries -[indy-wallet]: https://github.com/hyperledger/indy-sdk/tree/main/libindy/indy-wallet -[Hyperledger Indy SDK]: https://github.com/hyperledger/indy-sdk +[Hyperledger Aries]: https://www.lfdecentralizedtrust.org/projects/aries +[indy-wallet]: https://github.com/hyperledger-indy/indy-sdk/tree/main/libindy/indy-wallet +[Hyperledger Indy SDK]: https://github.com/hyperledger-indy/indy-sdk [SQLite]: https://www.sqlite.org/index.html [PostgreSQL]: https://www.postgresql.org/ [storage]: /docs/storage.md -[Aries Framework JavaScript]: https://github.com/hyperledger/aries-framework-javascript [ACA-Py]: https://github.com/openwallet-foundation/acapy [Credo]: https://github.com/openwallet-foundation/credo-ts [Hamal in the constellation of Aries]: https://www.star-facts.com/hamal/ @@ -44,9 +43,9 @@ As noted above, Askar is a re-implementation (with lessons learned!) of the concept documents written about [indy-wallet] apply similarly to Askar. These are linked here: -- [Encryption and storage passphrases](https://github.com/hyperledger/indy-sdk/blob/main/docs/concepts/default-wallet.md) -- [Object Storage](https://github.com/hyperledger/indy-sdk/blob/main/docs/design/003-wallet-storage/README.md) -- [Storage Import/Export](https://github.com/hyperledger/indy-sdk/blob/main/docs/design/009-wallet-export-import/README.md) +- [Encryption and storage passphrases](https://github.com/hyperledger-indy/indy-sdk/blob/main/docs/concepts/default-wallet.md) +- [Object Storage](https://github.com/hyperledger-indy/indy-sdk/blob/main/docs/design/003-wallet-storage/README.md) +- [Storage Import/Export](https://github.com/hyperledger-indy/indy-sdk/blob/main/docs/design/009-wallet-export-import/README.md) > **To Do**: These documents should be copied to this repository and updated > specifically for the Askar implementation. @@ -76,13 +75,4 @@ We also welcome issues submitted about problems you encounter in using `askar`. ## License -Licensed under either of - -- Apache License, Version 2.0 - ([LICENSE-APACHE](https://github.com/openwallet-foundation/askar/blob/main/LICENSE-APACHE) - or http://www.apache.org/licenses/LICENSE-2.0) -- MIT license - ([LICENSE-MIT](https://github.com/openwallet-foundation/askar/blob/main/LICENSE-MIT) - or [https://opensource.org/licenses/MIT](https://opensource.org/licenses/MIT)) - -at your option. +[Apache License Version 2.0](LICENSE) diff --git a/SECURITY.md b/SECURITY.md index 576db5ab..61b2c19c 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,19 +1,127 @@ -# Hyperledger Security Policy +# Askar Security Policy -## Reporting a Security Bug +## About this Document -If you think you have discovered a security issue in any of the Hyperledger projects, we'd love to -hear from you. We will take all security bugs seriously and if confirmed upon investigation we will -patch it within a reasonable amount of time and release a public security bulletin discussing the -impact and credit the discoverer. +This document document defines how security vulnerability reporting is handled +in this project. The approach aligns with the [OpenWallet Foundation's security vulnerability disclosure policy]. +Please review that document to understand +the basis of the security reporting for this project -If you have found what you think is a vulnerability in the code in this -repository, please email a description of the flaw and any related information -(e.g. reproduction steps, version) to -[security@hyperledger.org](mailto:security@hyperledger.org). If we agree with -your assessment, we'll open a GitHub security issue in the reposioty, and invite -you to collaborate towards resolving the issue. +This policy borrows heavily from the recommendations of the OpenSSF +Vulnerability Disclosure working group. For up-to-date information on the latest +recommendations related to vulnerability disclosures, please visit the [GitHub +of that working group](https://github.com/ossf/wg-vulnerability-disclosures). -The process by which the Hyperledger Security Team handles security bugs is documented further in -our [Defect Response page](https://wiki.hyperledger.org/display/SEC/Defect+Response) on our -[wiki](https://wiki.hyperledger.org). +If you are already familiar with what a security vulnerability disclosure policy +is and are ready to report a vulnerability, please jump to [Report +Intakes](#report-intakes). + +[OpenWallet Foundation's security vulnerability disclosure policy]: https://tac.openwallet.foundation/governance/security/ + +## What Is a Vulnerability Disclosure Policy? + +No piece of software is perfect. All software (at least, all software of a +certain size and complexity) has bugs. In open source development, members of +the community or the public find bugs and report them to the project. A +vulnerability disclosure policy explains how this process functions from the +perspective of the project. + +This vulnerability disclosure policy explains the rules and guidelines for +this project. It is intended to act as both a reference for +outsiders–including both bug reporters and those looking for information on the +project’s security practices–as well as a set of rules that maintainers and +contributors have agreed to follow. + +## Report Intakes + +This project uses the following mechanism to submit security +vulnerabilities. While the security team members will do their best to +respond to bugs disclosed in all possible ways, it is encouraged for bug +finders to report through the following approved channel: + +- Open a [GitHub security vulnerability report]: Open a new draft security + advisory from the [Security + Advisories](https://github.com/openwallet-foundation/askar/security/advisories) + of the Askar repository. See [GitHub Security + Advisories](#github-security-advisories) to learn more about the security + infrastructure in GitHub. + +[GitHub security vulnerability report]: https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability + +## Security Team + +The current security team is: + +| Name | Email ID | OWF Discord Chat ID | Area/Specialty | +| ---------------- | ------------------------ | ------------------- | ------------------ | +| Stephen Curran | swcurran@cloudcompass.ca | swcurran | Generalist | +| Andrew Whitehead | cywolf@gmail.com | andrewwhitehead | Rust | +| Wade Barnes | wade@neoterictech.ca | wadebarnes | GHA and Deployment | + +The security team for this project must include at least three project +Maintainers that agree to carry out the following duties and responsibilities. +Members are added and removed from the team via approved Pull Requests to this +repository. For additional background into the role of the security team, see +the [People Infrastructure] section of the [OpenWallet Foundation's security vulnerability disclosure policy]. + +[People Infrastructure]: https://tac.openwallet.foundation/governance/security#people-infrastructure + +**Responsibilities**: + +1. Acknowledge receipt of the issue (see [Report Intakes](#report-intakes)) to the reporter within 2 business days. + +2. Assess the issue. Engage with the reporter to ask any outstanding questions about the report and how to reproduce it. If the report is not considered a vulnerability, then the reporter should be informed and this process can be halted. If the report is still a regular bug (just not a security vulnerability), the reporter should be informed (if necessary) of the regular process for reporting bugs. + +3. Some issues may require more time and resources to correct. If a +particular report is more complex, discuss an embargo period with the reporter. +The embargo period should be negotiated with the reporter and must not be +longer than 90 days. + +1. Create a patch for the issue (see [Private Patch Deployment +Infrastructure](#private-patch-deployment-infrastructure)). + +1. Request a CVE for the issue (see [CNA/CVE Reporting](#cnacve-reporting)). + +2. Decide the date of public release. + +3. If applicable, notify members of the embargo list of the upcoming patch +and release, as described above. + +1. Cut a new (software) release in which the bug is fixed. + +2. Publicly disclose the issue within 48 hours after the release (see [GitHub Security Advisories](#github-security-advisories)). + +## Discussion Forum + +Discussions about each reported vulnerability are carried out in the +private GitHub security advisory about the vulnerability. +If necessary, a private channel specific to the issue may be created on the +OpenWallet Foundation's Discord server with invited participants added to the +discussion. + +## CNA/CVE Reporting + +This project maintains a list of **Common Vulnerabilities and Exposures +(CVE)** and uses GitHub as its **CVE numbering authority (CNA)** for issuing +CVEs. + +## Embargo List + +This project maintains a private embargo list. If you wish to be added to the +embargo list for a project, please email the members of the Security team +(emails [above](#security-team)), including the project name and reason for +being added to the embargo list. Requests will be assessed by the security team +in conjunction with the appropriate OpenWallet Foundation staff, and a decision +will be made whether to accommodate the request. + +## GitHub Security Advisories + +This project uses [GitHub security advisories and the GitHub security process](https://docs.github.com/en/code-security/security-advisories) for handling security vulnerabilities. + +## Private Patch Deployment Infrastructure + +In creating patches and new releases that address security vulnerabilities, +this project uses the private development features of GitHub for security +vulnerabilities. GitHub has [extensive +documentation](https://docs.github.com/en/code-security/security-advisories/repository-security-advisories) +about these features. From 12ec5700cb70845f07b7ac1d43c073c2cc11a5cb Mon Sep 17 00:00:00 2001 From: Stephen Curran Date: Thu, 30 Jul 2026 15:32:47 -0700 Subject: [PATCH 2/2] Updates to documents per feedback from LF Signed-off-by: Stephen Curran --- CODE_OF_CONDUCT.md | 4 ++-- SECURITY.md | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 31c616d4..311c8cb9 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,7 +1,7 @@ # Askar Code of Conduct Policy -The Askar project uses the [LF Europe Code of Conduct], which can be found by clicking "Code of Conduct" in the table of contents of the [LF Europe Policies] PDF document. +The Askar project uses the [LF Europe Code of Conduct]. -[LF Europe Policies]: https://www.linuxfoundation.org/hubfs/lfeu_policies_exhibitb_051024b.pdf?hsLang=en +[LF Europe Code of Conduct]: https://linuxfoundation.eu/policies/code-of-conduct Let's all be good to one another! diff --git a/SECURITY.md b/SECURITY.md index 61b2c19c..576bb66c 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -52,11 +52,11 @@ finders to report through the following approved channel: The current security team is: -| Name | Email ID | OWF Discord Chat ID | Area/Specialty | -| ---------------- | ------------------------ | ------------------- | ------------------ | -| Stephen Curran | swcurran@cloudcompass.ca | swcurran | Generalist | -| Andrew Whitehead | cywolf@gmail.com | andrewwhitehead | Rust | -| Wade Barnes | wade@neoterictech.ca | wadebarnes | GHA and Deployment | +| Name | OWF Discord Chat ID | Area/Specialty | +| ---------------- | ------------------- | ------------------ | +| Stephen Curran | swcurran | Generalist | +| Andrew Whitehead | andrewwhitehead | Rust | +| Wade Barnes | wadebarnes | GHA and Deployment | The security team for this project must include at least three project Maintainers that agree to carry out the following duties and responsibilities.