From 03adf4dbdf5919b739586ccb9ebc65357559640c Mon Sep 17 00:00:00 2001 From: Josh Romero Date: Sun, 26 Feb 2023 16:01:23 -0800 Subject: [PATCH 1/6] [Docs] Update README to baseline to project standards (#382) - Add ADMINS.md - Update DEVELOPER_GUIDE.md - move running instructions from README.md, remove doc site links - Add RESPONSIBILITIES.md - Add SECURITY.md Signed-off-by: Josh Romero Co-authored-by: Sean Neumann <1413295+seanneumann@users.noreply.github.com> --- ADMINS.md | 41 ++++++++++++ DEVELOPER_GUIDE.md | 54 ++++++++++++++-- README.md | 110 ++++++++++++++------------------- RESPONSIBILITIES.md | 147 ++++++++++++++++++++++++++++++++++++++++++++ SECURITY.md | 90 +++++++++++++++++++++++++++ 5 files changed, 373 insertions(+), 69 deletions(-) create mode 100644 ADMINS.md create mode 100644 RESPONSIBILITIES.md create mode 100644 SECURITY.md diff --git a/ADMINS.md b/ADMINS.md new file mode 100644 index 0000000000..2deaffa513 --- /dev/null +++ b/ADMINS.md @@ -0,0 +1,41 @@ +- [Overview](#overview) +- [Current Admins](#current-admins) +- [Admin Responsibilities](#admin-responsibilities) + - [Prioritize Security](#prioritize-security) + - [Enforce Code of Conduct](#enforce-code-of-conduct) + - [Add/Remove Maintainers](#addremove-maintainers) + - [Adopt Organizational Best Practices](#adopt-organizational-best-practices) + +## Overview + +This document explains who the admins are (see below), what they do in this repo, and how they should be doing it. If you're interested in becoming a maintainer, see [MAINTAINERS](MAINTAINERS.md). If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md). + +## Current Admins + +| Admin | GitHub ID | Affiliation | +| ------------------ | --------------------------------------- | ----------- | +| Charlotte Henkle | [CEHENKLE](https://github.com/CEHENKLE) | Amazon | +| Daniel Doubrovkine | [dblock](https://github.com/dblock) | Amazon | +| Henri Yandell | [hyandell](https://github.com/hyandell) | Amazon | + +## Admin Responsibilities + +As an admin you own stewardship of the repository and its settings. Admins have [admin-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and protect the repository as follows. + +### Prioritize Security + +Security is your number one priority. Manage security keys and safeguard access to the repository. + +Note that this repository is monitored and supported 24/7 by Amazon Security, see [Reporting a Vulnerability](SECURITY.md) for details. + +### Enforce Code of Conduct + +Act on [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md) violations by revoking access, and blocking malicious actors. + +### Add/Remove Maintainers + +Perform administrative tasks, such as [adding](MAINTAINERS.md#adding-a-new-maintainer) and [removing maintainers](MAINTAINERS.md#removing-a-maintainer). + +### Adopt Organizational Best Practices + +Adopt organizational best practices, work in the open, and collaborate with other admins by opening issues before making process changes. Prefer consistency, and avoid diverging from practices in the opensearch-project organization. diff --git a/DEVELOPER_GUIDE.md b/DEVELOPER_GUIDE.md index a5d427734c..1f5cb18b75 100644 --- a/DEVELOPER_GUIDE.md +++ b/DEVELOPER_GUIDE.md @@ -1,6 +1,52 @@ +

OUI Developer Guide

-This guide applies to all development within the OUI project. While this guide is a work-in-progress, the following developer guides may be helpful: -- [Getting stared developer guide (EUI Docs)](https://elastic.github.io/eui/#/guidelines/getting-started) -- [Accessibility developer guide (EUI Docs)](https://elastic.github.io/eui/#/guidelines/accessibility) -- [SASS developer guide (EUI Docs)](https://elastic.github.io/eui/#/guidelines/sass) +This guide applies to all development within the OpenSearch Dashboards project and is recommended for the development of all OpenSearch Dashboards plugins. + +- [Running locally](#running-locally) + - [Node](#node) + - [Start documentation server](#start-documentation-server) +- [Maintenance and contributing](#maintenance-and-contributing) + +## Running locally + +### Node + +We depend upon the version of node defined in [.nvmrc](.nvmrc). + +You will probably want to install a node version manager. [nvm](https://github.com/creationix/nvm) is recommended. + +To install and use the correct node version with `nvm`: + +``` +nvm install +``` + +### Start documentation server + +You can run the documentation locally at [http://localhost:8030/](http://localhost:8030/) by running the following. + +``` +yarn +yarn start +``` + +If another process is already listening on port 8030, the next free port will be used. Alternatively, you can specify a port: + +``` +yarn start --port 9000 +``` +## Maintenance and contributing + +[CONTRIBUTING.md](CONTRIBUTING.md) + +* [Component design](wiki/component-design.md) +* [Component development](wiki/component-development.md) + * [Creating components manually](wiki/creating-components-manually.md) + * [Creating components with Yeoman](wiki/creating-components-yeoman.md) +* [Creating icons](wiki/creating-icons.md) +* [Theming](wiki/theming.md) +* [Testing](wiki/testing.md) + * [Accessibility Testing](wiki/automated-accessibility-testing.md) +* [Documentation](wiki/documentation-guidelines.md) +* [Releasing versions](wiki/releasing-versions.md) diff --git a/README.md b/README.md index 8d87e5b446..197cba3dbc 100644 --- a/README.md +++ b/README.md @@ -1,90 +1,70 @@ -# OpenSearch UI Framework - -> The OpenSearch UI Framework is a collection of React UI components for quickly building user interfaces -> at OpenSearch Project. Not using React? No problem! You can still use the CSS behind each component. - -You should check out our [living style guide][docs], which contains many examples of components in the OUI framework aesthetic, and how to use them in your products. We also have a [FAQ][faq] that covers common usage questions. - -## Installation - -To install the OpenSearch UI Framework into an existing project, use the `yarn` CLI (`npm` is not supported). - -``` -yarn add @opensearch-project/oui -``` - -Note that OUI has [several `peerDependencies` requirements](package.json) that will also need to be installed if starting with a blank project. You can read more about other ways to [consume OUI][consuming]. - -``` -yarn add @opensearch-project/oui @elastic/datemath moment prop-types -``` - - -## Running Locally +![OpenSearch logo](OpenSearch.svg) -### Node +# OpenSearch UI Framework -We depend upon the version of node defined in [.nvmrc](.nvmrc). +- [Welcome!](#welcome) +- [Installation](#installation) +- [Project Resources](#project-resources) +- [Project Style Guidelines](#project-style-guidelines) +- [Code of Conduct](#code-of-conduct) +- [License](#license) +- [Copyright](#copyright) -You will probably want to install a node version manager. [nvm](https://github.com/creationix/nvm) is recommended. +## Welcome! -To install and use the correct node version with `nvm`: +> The OpenSearch UI (OUI) Framework is a collection of React UI components for quickly building user interfaces +> for the OpenSearch Project. -``` -nvm install -``` +You should check out our [living style guide][docs], which contains many examples of components in the OUI framework aesthetic, and how to use them in your products. We also have a [FAQ][FAQ.md] that covers common usage questions. -### Documentation +### Goals -You can run the documentation locally at [http://localhost:8030/](http://localhost:8030/) by running the following. +The primary goal of this library is to provide reusable UI components that can be used in any +OpenSearch project web project. As React components, they remove CSS from the process of building UIs. +As a single source of truth, the framework allows our designers to make changes to our aesthetic +directly in the code. And unit test coverage for the UI components allows us to deliver a stable +"API for user interfaces". -``` -yarn -yarn start -``` +## Installation -If another process is already listening on port 8030, the next free port will be used. Alternatively, you can specify a port: +To install the OpenSearch UI Framework into an existing project, use the `yarn` CLI (`npm` is not supported). ``` -yarn start --port 9000 +yarn add @opensearch-project/oui ``` -## Goals +Note that OUI has [several `peerDependencies` requirements](package.json) that will also need to be installed if starting with a blank project. You can read more about other ways to [consume OUI][consuming]. -The primary goal of this library is to provide reusable UI components that can be used throughout -Elastic's web products. As React components, they remove CSS from the process of building UIs. -As a single source of truth, the framework allows our designers to make changes to our aesthetic -directly in the code. And unit test coverage for the UI components allows us to deliver a stable -"API for user interfaces". +## Project Resources +* [FAQ](FAQ.md) +* [Project Website](https://opensearch.org/) +* [Downloads](https://opensearch.org/downloads.html) +* [Documentation](https://opensearch.org/docs/latest/) +* Need help? Try [Forums](https://forum.opensearch.org/) +* [Project Principles](https://opensearch.org/about.html#principles-for-development) +* [Contributing to OpenSearch](CONTRIBUTING.md) +* [Maintainer Responsibilities](RESPONSIBILITIES.md) +* [Release Management](RELEASING.md) +* [Organization Admins](ADMINS.md) +* [Repo Maintainers](MAINTAINERS.md) +* [Security](SECURITY.md) -## Wiki +## Project Style Guidelines -### Consumption +The [OpenSearch Project style guidelines](https://github.com/opensearch-project/documentation-website/blob/main/STYLE_GUIDE.md) and [OpenSearch terms](https://github.com/opensearch-project/documentation-website/blob/main/TERMS.md) documents provide style standards and terminology to be observed when creating OpenSearch Project content. -* [Consuming OUI][consuming] -* [Using OUI with react-router](wiki/react-router.md) +## Code of Conduct -### Maintenance / Contributing +This project has adopted the [Amazon Open Source Code of Conduct](CODE_OF_CONDUCT.md). For more information see the [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq), or contact [opensource-codeofconduct@amazon.com](mailto:opensource-codeofconduct@amazon.com) with any additional questions or comments. -[CONTRIBUTING.md](CONTRIBUTING.md) +## License -* [Component design](wiki/component-design.md) -* [Component development](wiki/component-development.md) - * [Creating components manually](wiki/creating-components-manually.md) - * [Creating components with Yeoman](wiki/creating-components-yeoman.md) -* [Creating icons](wiki/creating-icons.md) -* [Theming](wiki/theming.md) -* [Testing](wiki/testing.md) - * [Accessibility Testing](wiki/automated-accessibility-testing.md) -* [Documentation](wiki/documentation-guidelines.md) -* [Releasing versions](wiki/releasing-versions.md) +This project is licensed under the [Apache v2.0 License](LICENSE.txt). -## License +## Copyright -[Apache Licensed.][license] Read the [FAQ][faq] for details. +Copyright OpenSearch Contributors. See [NOTICE](NOTICE.txt) for details. -[license]: LICENSE -[faq]: FAQ.md [consuming]: wiki/consuming.md -[docs]: https://elastic.github.io/eui/ +[docs]: https://oui.opensearch.org diff --git a/RESPONSIBILITIES.md b/RESPONSIBILITIES.md new file mode 100644 index 0000000000..4e772ee3fe --- /dev/null +++ b/RESPONSIBILITIES.md @@ -0,0 +1,147 @@ +- [Overview](#overview) +- [Current Maintainers](#current-maintainers) +- [Maintainer Responsibilities](#maintainer-responsibilities) + - [Uphold Code of Conduct](#uphold-code-of-conduct) + - [Prioritize Security](#prioritize-security) + - [Review Pull Requests](#review-pull-requests) + - [Triage Open Issues](#triage-open-issues) + - [Automatically Label Issues](#automatically-label-issues) + - [Be Responsive](#be-responsive) + - [Maintain Overall Health of the Repo](#maintain-overall-health-of-the-repo) + - [Keep Dependencies up to Date](#keep-dependencies-up-to-date) + - [Manage Roadmap](#manage-roadmap) + - [Add Continuous Integration Checks](#add-continuous-integration-checks) + - [Use Semver](#use-semver) + - [Release Frequently](#release-frequently) + - [Promote Other Maintainers](#promote-other-maintainers) + - [Describe the Repo](#describe-the-repo) +- [Becoming a Maintainer](#becoming-a-maintainer) + - [Nomination](#nomination) + - [Interest](#interest) + - [Addition](#addition) +- [Removing a Maintainer](#removing-a-maintainer) + - [Moving On](#moving-on) + - [Inactivity](#inactivity) + - [Negative Impact on the Project](#negative-impact-on-the-project) + +## Overview + +This document explains who maintainers are, what they do in various repos of opensearch-project, and how they should be doing it. If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md). + +## Current Maintainers + +Each repo contains a [MAINTAINERS.md](MAINTAINERS.md) file that lists current maintainers, and points to this document. + +## Maintainer Responsibilities + +Maintainers are active and visible members of the community, and have [maintain-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and evolve code as follows. + +### Uphold Code of Conduct + +Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers and admins. + +### Prioritize Security + +Security is your number one priority. Maintainer's Github keys must be password protected securely and any reported security vulnerabilities are addressed before features or bugs. + +Note that this repository is monitored and supported 24/7 by Amazon Security, see [Reporting a Vulnerability](SECURITY.md) for details. + +### Review Pull Requests + +Review pull requests regularly, comment, suggest, reject, merge and close. Accept only high quality pull-requests. Provide code reviews and guidance on incoming pull requests. Don't let PRs be stale and do your best to be helpful to contributors. + +### Triage Open Issues + +Manage labels, review issues regularly, and triage by labelling them. + +All repositories in this organization have a standard set of labels, including `bug`, `documentation`, `duplicate`, `enhancement`, `good first issue`, `help wanted`, `blocker`, `invalid`, `question`, `wontfix`, and `untriaged`, along with release labels, such as `v1.0.0`, `v1.1.0`, `v2.0.0`, `patch`, and `backport`. + +Use labels to target an issue or a PR for a given release, add `help wanted` to good issues for new community members, and `blocker` for issues that scare you or need immediate attention. Request for more information from a submitter if an issue is not clear. Create new labels as needed by the project. + +#### Automatically Label Issues + +There are many tools available in GitHub for controlling labels on issues and pull requests. Use standard issue templates in the [./.github/ISSUE_TEMPLATE](./.github/ISSUE_TEMPLATE) directory to apply appropriate labels such as `bug` and `untriaged`. Repositories can choose to use GitHub actions such as [add-untriaged.yml](./.github/workflows/add-untriaged.yml) to apply labels automatically. + +### Be Responsive + +Respond to enhancement requests, and forum posts. Allocate time to reviewing and commenting on issues and conversations as they come in. + +### Maintain Overall Health of the Repo + +Keep the `main` branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches. + +#### Keep Dependencies up to Date + +Maintaining up-to-date dependencies on third party projects reduces the risk of security vulnerabilities. The Open Source Security Foundation (OpenSSF) [recommends](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool) either [dependabot](https://docs.github.com/en/code-security/dependabot) or [renovatebot](https://docs.renovatebot.com/). Both of these applications generate Pull Requests for dependency version updates. + - Renovate is integrated as part of the Remediate app in [Mend for Github](https://github.com/apps/mend-for-github.aaakk.us.kg), which is enabled on all opensearch-project repositories. It can be enabled in the `.whitesource` configuration file as described in the [Mend Remediate and Renovate](https://docs.mend.io/bundle/integrations/page/mend_remediate_and_renovate.html#Integration-with-Mend-Renovate) documentation. The [Merge Confidence](https://docs.renovatebot.com/merge-confidence/) feature can be configured to provide maintainers more information on the age, adoption rate, and percent test passing rate of other repositories. Mend maintains a "Dependency Dashboard" Issue in the repository with centralized information on pending version update PRs. + - Dependabot is integrated with GitHub and can be enabled by adding a [`dependabot.yml`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates) file to the repo. Dependabot does not have any centralized management dashboard, so maintainers may use tags or other PR filters to track pending updates. + +### Manage Roadmap + +Ensure the repo highlights features that should be elevated to the project roadmap. Be clear about the feature’s status, priority, target version, and whether or not it should be elevated to the roadmap. Any feature that you want highlighted on the OpenSearch Roadmap should be tagged with "roadmap". The OpenSearch [project-meta maintainers](https://github.com/opensearch-project/project-meta/blob/main/MAINTAINERS.md) will highlight features tagged "roadmap" on the project wide [OpenSearch Roadmap](https://github.com/orgs/opensearch-project/projects/1). + +### Add Continuous Integration Checks + +Add integration checks that validate pull requests and pushes to ease the burden on Pull Request reviewers. + +### Use Semver + +Use and enforce [semantic versioning](https://semver.org/) and do not let breaking changes be made outside of major releases. + +### Release Frequently + +Make frequent project releases to the community. + +### Promote Other Maintainers + +Assist, add, and remove [MAINTAINERS](MAINTAINERS.md). Exercise good judgement, and propose high quality contributors to become co-maintainers. See [Becoming a Maintainer](#becoming-a-maintainer) for more information. + +### Describe the Repo + +Make sure the repo has a well-written, accurate, and complete description. See [opensearch-project/.github#38](https://github.com/opensearch-project/.github/issues/38) for some helpful tips to describe your repo. + +## Becoming a Maintainer + +You can become a maintainer by actively [contributing](CONTRIBUTING.md) to any project, and being nominated by an existing maintainer. + +### Nomination + +Any current maintainer starts a private e-mail thread (until we have a better mechanism, e-mail addresses can usually be found via MAINTAINERS.md + DCO) with all other maintainers on that repository to discuss nomination using the template below. In order to be approved, at least three positive (+1) maintainer votes are necessary, and no vetoes (-1). In rare cases when there are fewer than three maintainers, the positive (+1) votes from all maintainers are required. Any disagreements can be escalated to the repo admin. + +The nomination should clearly identify the person with their real name and a link to their GitHub profile, and the rationale for the nomination, with concrete example contributions. + +### Interest + +Upon receiving at least three positive (+1) maintainer votes, and no vetoes (-1), from existing maintainers after a one week period, the nominating maintainer asks the nominee whether they might be interested in becoming a maintainer on the repository via private e-mail message. + +> This is great work! Based on your valuable contribution and ongoing engagement with the project, the current maintainers invite you to become a co-maintainer for this project. Please respond and let us know if you accept the invitation to become maintainer. + +Individuals accept the nomination by replying, or commenting, for example _"Thank you! I would love to."_ + +### Addition + +Upon receiving three positive (+1) maintainer votes, and no vetoes (-1), from other maintainers, and after having privately confirmed interest with the nominee, the maintainer opens a pull request adding the proposed co-maintainer to MAINTAINERS.md. The pull request is approved and merged. + +> _Content from the above nomination._ +> +> The maintainers have voted and agreed to this nomination. + +The repo admin adjusts the new maintainer’s permissions accordingly, and merges the pull request. + +## Removing a Maintainer + +Removing a maintainer is a disruptive action that the community of maintainers should not undertake lightly. There are several reasons a maintainer will be removed from the project, such as violating the [code of conduct](https://github.com/opensearch-project/.github/blob/main/CODE_OF_CONDUCT.md), or taking other actions that negatively impact the project. + +### Moving On + +There are plenty of reasons that might cause someone to want to take a step back or even a hiatus from a project. Existing maintainers can choose to leave the project at any time, with or without reason, by making a pull request to move themselves to the "Emeritus" section of MAINTAINERS.md, and asking an admin to remove their permissions. + +### Inactivity + +Maintainer status never expires. If a maintainer becomes inactive for a time (usually several months), the repo admin may revoke maintainer level access to the repository for security reasons. A maintainer can reach out to the repo admin to get their permissions reinstated. + +If the repo is left without any maintainers, either by maintainer inactivity or moving on, the repo is considered unmaintained. The repo admin will seek out new maintainers and note the maintenance status in the repo README file. + +### Negative Impact on the Project + +Actions that negatively impact the project will be handled by the admins, in coordination with other maintainers, in balance with the urgency of the issue. Examples would be [Code of Conduct](CODE_OF_CONDUCT.md) violations, deliberate harmful or malicious actions, and security risks. diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..a7e6c51f97 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,90 @@ +# Security Issue Response Process + +## Introduction + +Security issues happen as part of the normal lifecycle of software development of OpenSearch. This document describes the process for reporting these issues, responding to these issues, and ensuring we treat them not only with the appropriate priority but also with respect for the discoverers, software providers and their users, and the OpenSearch community in general. + +If you discover a potential security issue in this project we ask that you notify the OpenSearch Security Team via email to opensearch-security@amazon.com. Please do **not** create a public GitHub issue. + +*Giving credit where credit is due, this policy is heavily influenced by the [Xen Project’s security response process](https://xenproject.org/developers/security-policy/), that was put to the test during the [embargo period for XSA-108 back in 2014](https://xenproject.org/2014/10/22/xen-project-security-policy-improvements-get-involved/) and improved its clarity around managing the pre-disclosure list and the deployment of fixes during embargo. We are standing on the shoulders of these battle-tested giants.* + +## The Security Team + +The OpenSearch Security Team is a subset of the project’s maintainers responsible for looking after the project’s security, including the security issue response process outlined below. Maintainers can be added to the Security Team by submitting a PR updating this document and adding their name to the list below (the process for becoming a maintaner can be found [here](https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md#becoming-a-maintainer)). + +The OpenSearch Security Team will address reported issues on a best effort basis, prioritizing them based on several factors, including severity. + +### Current Members + +| Security Team member | GitHub Alias | Affiliation | +| ------------------------ | --------------------------------------------- | ----------- | +| Dave Lago | [davidlago](https://github.com/davidlago) | Amazon | +| Charlotte Henkle | [CEHENKLE](https://github.com/CEHENKLE) | Amazon | +| Daniel (dB.) Doubrovkine | [dblock](https://github.com/dblock) | Amazon | +| Anirudha (Ani) Jadhav | [anirudha](https://github.com/anirudha) | Amazon | +| Sean Neumann | [seanneumann](https://github.com/seanneumann) | Amazon | +| Anan Zhuang | [ananzh](https://github.com/ananzh) | Amazon | +| Eli Fisher | [elfisher](https://github.com/elfisher) | Amazon | + +## Process + +Anyone finding an issue that is already publicly disclosed (for example, a CVE in one of the project’s dependencies) should feel free to create an issue and discuss openly on GitHub. The process below is only intended for issues that have not been publicly disclosed yet. + +1. We request that instead of opening a GitHub issue, it is reported via email at opensearch-security@amazon.com. Please include a description of the issue, and any other information that could help in the reproduction and creation of a fix (version numbers, configuration values, reproduction steps...) +2. The OpenSearch Security Team will negotiate the conditions for an embargo period and a disclosure timeline with the discoverer (see [Embargo schedule](#embargo-schedule)). +3. After the vulnerability is confirmed, if no CVE number is already reserved, the OpenSearch Security Team will reserve one, and communicate it to the discoverer and all parties in the pre-disclosure list (see [Pre-disclosure list](#pre-disclosure-list)). +4. As soon as our advisory is available, we will send it, including patches, to members of the pre-disclosure list. In the event that we do not have a patch available 2 working weeks before the disclosure date, we aim to send an advisory that reflects the current state of knowledge to the pre-disclosure list. An updated advisory will be published as soon as available. At this stage, the advisory will be clearly marked with the embargo date. +5. On the day the embargo is lifted, we will publish the advisory and release the new versions containing the fix. +6. If new information and/or better fixes become available, new advisory versions will be released. + +During an embargo period, the OpenSearch Security Team may be required to make potentially controversial decisions in private, since they cannot confer with the community without breaking the embargo. The team will attempt to make such decisions following the guidance of this document and, where necessary, their own best judgement. Following the embargo period, on a best effort basis, the Security Team will disclose any such decisions, including the reasoning behind them, in the interests of transparency and to help provide guidance should a similar decision be required in the future. + +## Embargo Schedule + +Embargo periods will be negotiated on a case-by-case basis depending on the severity of the issue and availability of the fix, where a general starting point is to release an advisory to the pre-disclosure list within 2 weeks of the initial notification, and publicly releasing the advisory within 4 weeks of the advisory pre-release. + +When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honor such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honor the date specified by the discoverer. +Naturally, if a vulnerability is being exploited in the wild, we will make immediately public release of the patch(es.) + +## Pre-disclosure List + +We maintain a pre-disclosure list of contributors, vendors and operators of OpenSearch for two main reasons: + +1. To apply the fixes to large user populations requiring a significant amount of work post-disclosure +2. To privately collaborate with those who can help write and test the fixes so we can release them as soon as possible and with high confidence in their quality + +If there is an embargo, the pre-disclosure list will receive copies of the advisory and patches, with a clearly marked embargo date, as soon as they are available. The pre-disclosure list will also receive copies of public advisories when they are first issued or updated. + +We expect list members to maintain the confidentiality of the vulnerability up to the embargo date. Specifically, prior to the embargo date, pre-disclosure list members should not make available, even to their own customers and partners: + +* The OpenSearch advisory +* Their own advisory +* The impact, scope, set of vulnerable systems or the nature of the vulnerability +* Revision control commits which are a fix for the problem +* Patched software (even in binary form) + +Without prior consultation with the OpenSearch Security Team, list members may make available to their users only: + +* The existence of an issue +* The assigned OpenSearch advisory number +* The planned disclosure date + +List members may, if (and only if) the OpenSearch Security Team grants permission, deploy fixed versions during the embargo. Permission for deployment, and any restrictions, will be stated in the embargoed advisory text. Where the list member is a service provider who intends to take disruptive action such as rebooting as part of deploying a fix: the list member’s communications to its users about the service disruption may mention that the disruption is to correct a security issue, and relate it to the public information about the issue (as listed above). This applies whether the deployment occurs during the embargo (with permission–see above) or is planned for after the end of the embargo. + +Pre-disclosure list members are allowed to share fixes to embargoed issues, analysis, etc., with the OpenSearch Security Team and security teams of other list members. Technical measures must be taken to prevent non-list-member organizations, or unauthorized staff in list-member organizations, from obtaining the embargoed materials. + +## Pre-disclosure list application process + +Organizations who meet the criteria above (i.e. significant work needed post-disclosure to remediate the issue and/or ability to help create or test the potential fixes) should contact the OpenSearch Security Team via email at opensearch-security@amazon.com if they wish to be added to the pre-disclosure list. In the email, you must include: + +* The name of your organization +* How you’re using OpenSearch +* A description of why you fit the criteria (number of users, amount of work needed to remediate, ability to collaborate on fixes...) +* Information about your handling of security problems + * Your invitation to members of the public, who discover security problems with your products/services, to report them in confidence to you + * Specifically, the contact information (email addresses or other contact instructions) which such a member of the public should use +* A statement to the effect that you have read this policy and agree to abide by the terms for inclusion in the list, specifically the requirements to regarding confidentiality during an embargo period +* The email(s) you wish added to the pre-disclosure list + + +The OpenSearch Security Team will review your application and get back to you with their decision. From ede2c707f1745e3e297736bd45f83f7d5a1f0f57 Mon Sep 17 00:00:00 2001 From: Abhishek Reddy <62020972+AbhishekReddy1127@users.noreply.github.com> Date: Mon, 27 Feb 2023 12:59:15 -0600 Subject: [PATCH 2/6] Removed GitHub column from all the tables (#371) Signed-off-by: AbhishekReddy1127 --- src-docs/src/views/tables/in_memory/in_memory.js | 16 +--------------- .../in_memory/in_memory_controlled_pagination.js | 16 +--------------- .../views/tables/in_memory/in_memory_search.js | 11 ----------- .../in_memory/in_memory_search_callback.js | 16 +--------------- .../in_memory/in_memory_search_external.js | 11 ----------- .../tables/in_memory/in_memory_selection.js | 11 ----------- 6 files changed, 3 insertions(+), 78 deletions(-) diff --git a/src-docs/src/views/tables/in_memory/in_memory.js b/src-docs/src/views/tables/in_memory/in_memory.js index 7c797d0d4c..92fb5031d1 100644 --- a/src-docs/src/views/tables/in_memory/in_memory.js +++ b/src-docs/src/views/tables/in_memory/in_memory.js @@ -12,11 +12,7 @@ import React from 'react'; import { formatDate } from '../../../../../src/services/format'; import { createDataStore } from '../data_store'; -import { - OuiInMemoryTable, - OuiLink, - OuiHealth, -} from '../../../../../src/components'; +import { OuiInMemoryTable, OuiHealth } from '../../../../../src/components'; /* Example user object: @@ -25,7 +21,6 @@ Example user object: id: '1', firstName: 'john', lastName: 'doe', - github: 'johndoe', dateOfBirth: Date.now(), nationality: 'NL', online: true @@ -55,15 +50,6 @@ export const Table = () => { name: 'Last Name', truncateText: true, }, - { - field: 'github', - name: 'Github', - render: (username) => ( - - {username} - - ), - }, { field: 'dateOfBirth', name: 'Date of Birth', diff --git a/src-docs/src/views/tables/in_memory/in_memory_controlled_pagination.js b/src-docs/src/views/tables/in_memory/in_memory_controlled_pagination.js index e537af36cc..bd009f9175 100644 --- a/src-docs/src/views/tables/in_memory/in_memory_controlled_pagination.js +++ b/src-docs/src/views/tables/in_memory/in_memory_controlled_pagination.js @@ -12,11 +12,7 @@ import React, { useEffect, useState } from 'react'; import { formatDate } from '../../../../../src/services/format'; import { createDataStore } from '../data_store'; -import { - OuiInMemoryTable, - OuiLink, - OuiHealth, -} from '../../../../../src/components'; +import { OuiInMemoryTable, OuiHealth } from '../../../../../src/components'; /* Example user object: @@ -25,7 +21,6 @@ Example user object: id: '1', firstName: 'john', lastName: 'doe', - github: 'johndoe', dateOfBirth: Date.now(), nationality: 'NL', online: true @@ -55,15 +50,6 @@ export const Table = () => { name: 'Last Name', truncateText: true, }, - { - field: 'github', - name: 'Github', - render: (username) => ( - - {username} - - ), - }, { field: 'dateOfBirth', name: 'Date of Birth', diff --git a/src-docs/src/views/tables/in_memory/in_memory_search.js b/src-docs/src/views/tables/in_memory/in_memory_search.js index 62f054b798..d45e0668e4 100644 --- a/src-docs/src/views/tables/in_memory/in_memory_search.js +++ b/src-docs/src/views/tables/in_memory/in_memory_search.js @@ -14,7 +14,6 @@ import { formatDate } from '../../../../../src/services/format'; import { createDataStore } from '../data_store'; import { OuiInMemoryTable, - OuiLink, OuiHealth, OuiSpacer, OuiSwitch, @@ -31,7 +30,6 @@ Example user object: id: '1', firstName: 'john', lastName: 'doe', - github: 'johndoe', dateOfBirth: Date.now(), nationality: 'NL', online: true @@ -65,15 +63,6 @@ export const Table = () => { name: 'Last Name', truncateText: true, }, - { - field: 'github', - name: 'Github', - render: (username) => ( - - {username} - - ), - }, { field: 'dateOfBirth', name: 'Date of Birth', diff --git a/src-docs/src/views/tables/in_memory/in_memory_search_callback.js b/src-docs/src/views/tables/in_memory/in_memory_search_callback.js index 34593ce768..72f999e2c9 100644 --- a/src-docs/src/views/tables/in_memory/in_memory_search_callback.js +++ b/src-docs/src/views/tables/in_memory/in_memory_search_callback.js @@ -12,11 +12,7 @@ import React, { useState } from 'react'; import { formatDate } from '../../../../../src/services/format'; import { createDataStore } from '../data_store'; -import { - OuiInMemoryTable, - OuiLink, - OuiHealth, -} from '../../../../../src/components'; +import { OuiInMemoryTable, OuiHealth } from '../../../../../src/components'; /* Example user object: @@ -25,7 +21,6 @@ Example user object: id: '1', firstName: 'john', lastName: 'doe', - github: 'johndoe', dateOfBirth: Date.now(), nationality: 'NL', online: true @@ -91,15 +86,6 @@ export const Table = () => { name: 'Last Name', truncateText: true, }, - { - field: 'github', - name: 'Github', - render: (username) => ( - - {username} - - ), - }, { field: 'dateOfBirth', name: 'Date of Birth', diff --git a/src-docs/src/views/tables/in_memory/in_memory_search_external.js b/src-docs/src/views/tables/in_memory/in_memory_search_external.js index bd393f2935..034066ce04 100644 --- a/src-docs/src/views/tables/in_memory/in_memory_search_external.js +++ b/src-docs/src/views/tables/in_memory/in_memory_search_external.js @@ -14,7 +14,6 @@ import { formatDate } from '../../../../../src/services/format'; import { createDataStore } from '../data_store'; import { OuiInMemoryTable, - OuiLink, OuiHealth, OuiFlexGroup, OuiFlexItem, @@ -29,7 +28,6 @@ Example user object: id: '1', firstName: 'john', lastName: 'doe', - github: 'johndoe', dateOfBirth: Date.now(), nationality: 'NL', online: true @@ -62,15 +60,6 @@ export const Table = () => { name: 'Last Name', truncateText: true, }, - { - field: 'github', - name: 'Github', - render: (username) => ( - - {username} - - ), - }, { field: 'dateOfBirth', name: 'Date of Birth', diff --git a/src-docs/src/views/tables/in_memory/in_memory_selection.js b/src-docs/src/views/tables/in_memory/in_memory_selection.js index 1dfa5b4b69..7b5b27de7d 100644 --- a/src-docs/src/views/tables/in_memory/in_memory_selection.js +++ b/src-docs/src/views/tables/in_memory/in_memory_selection.js @@ -13,7 +13,6 @@ import React, { useState, Fragment, useRef } from 'react'; import { formatDate } from '../../../../../src/services/format'; import { createDataStore } from '../data_store'; import { - OuiLink, OuiHealth, OuiButton, OuiInMemoryTable, @@ -31,7 +30,6 @@ Example user object: id: '1', firstName: 'john', lastName: 'doe', - github: 'johndoe', dateOfBirth: Date.now(), nationality: 'NL', online: true @@ -154,15 +152,6 @@ export const Table = () => { name: 'Last Name', truncateText: true, }, - { - field: 'github', - name: 'Github', - render: (username) => ( - - {username} - - ), - }, { field: 'dateOfBirth', name: 'Date of Birth', From 62197c9e394ed9481f51af3f1216c6977bf5fcaa Mon Sep 17 00:00:00 2001 From: Abhishek Reddy <62020972+AbhishekReddy1127@users.noreply.github.com> Date: Mon, 27 Feb 2023 12:59:58 -0600 Subject: [PATCH 3/6] [OUI Docs] Removed the Accessibiity guidelines page (#515) * Removed the Accessibiity guidleines page Signed-off-by: AbhishekReddy1127 * Updated the page Signed-off-by: AbhishekReddy1127 --------- Signed-off-by: AbhishekReddy1127 --- src-docs/src/routes.js | 3 - .../src/views/guidelines/accessibility.js | 841 ------------------ 2 files changed, 844 deletions(-) diff --git a/src-docs/src/routes.js b/src-docs/src/routes.js index f9ed1123f2..206e733835 100644 --- a/src-docs/src/routes.js +++ b/src-docs/src/routes.js @@ -23,8 +23,6 @@ import { playgroundCreator } from './services/playground'; // Guidelines // const GettingStarted = require('!!raw-loader!./views/guidelines/getting_started.md'); -import AccessibilityGuidelines from './views/guidelines/accessibility'; - import ColorGuidelines from './views/guidelines/colors'; import { SassGuidelines } from './views/guidelines/sass'; @@ -332,7 +330,6 @@ const navigation = [ items: [ // TODO uncomment when OuiMarkdownFormat has a better text formatting // createMarkdownExample(GettingStarted, 'Getting started'), - createExample(AccessibilityGuidelines, 'Accessibility'), { name: 'Colors', component: ColorGuidelines, diff --git a/src-docs/src/views/guidelines/accessibility.js b/src-docs/src/views/guidelines/accessibility.js index 6a7adaa2f7..e69de29bb2 100644 --- a/src-docs/src/views/guidelines/accessibility.js +++ b/src-docs/src/views/guidelines/accessibility.js @@ -1,841 +0,0 @@ -/* - * SPDX-License-Identifier: Apache-2.0 - * - * The OpenSearch Contributors require contributions made to - * this file be licensed under the Apache-2.0 license or a - * compatible open source license. - * - * Modifications Copyright OpenSearch Contributors. See - * GitHub history for details. - */ - -import React from 'react'; -import { Link } from 'react-router-dom'; - -import { GuideRule, GuideRuleExample } from '../../components'; - -import { - OuiText, - OuiLink, - OuiSpacer, - OuiCode, - OuiCallOut, - OuiCodeBlock, - OuiFlexGroup, - OuiFlexItem, - OuiTitle, - OuiAspectRatio, - OuiIcon, - OuiTextColor, -} from '../../../../src/components'; - -const codeBlockProps = { - language: 'html', - paddingSize: 'none', - fontSize: 'm', -}; - -export default { - title: 'Accessibility guidelines', - intro: ( - <> - -

- OUI provides a strong start to building accessibility into your apps. - The components provided strive to meet{' '} - WCAG 2.1{' '} - guidelines on semantics, keyboard functionality, color contrast, and - so on. How you stitch together these components in the overall page - structure also plays a large role in meeting accessibility goals. - Headings, landmarks, page titles, focus management, and accessible - names all work together to create accessible apps. -

-

- Building accessibility into your app is as important as code quality, - visual design, and performance, and it’s also important that you test - as you go. You can approach accessibility testing from three - dimensions: automated, manual, and empathetic thinking. Use automated - tests to quickly cover as much ground as possible, manual tests to - address more complicated scenarios, and empathy to fill in the gaps. -

- - - - -

For a technical intro to accessibility and how OUI tackles it

- - - - - -