cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: abdb29d4-5ca1-4e91-800b-b3569bbd788c.md

title: Config Rule For Encrypted Volumes Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: abdb29d4-5ca1-4e91-800b-b3569bbd788c Query name: Config Rule For Encrypted Volumes Disabled Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: Check if AWS config rules do not identify Encrypted Volumes as a source.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "awsconfigconfig_rule" "positive1" { name = "some_rule" source { owner = "AWS" sourceidentifier = "IAMPASSWORD_POLICY" } } resource "awsconfigconfig_rule" "positive2" { name = "another_rule" source { owner = "AWS" sourceidentifier = "IAMPASSWORD_POLICY" } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsconfigconfig_rule" "negative1" { name = "encryptedvolsrule" source { owner = "AWS" sourceidentifier = "ENCRYPTEDVOLUMES" } } resource "awsconfigconfig_rule" "negative2" { name = "another_rule" source { owner = "AWS" sourceidentifier = "IAMPASSWORD_POLICY" } } ```
Project: KICS (Provisioning / Security & Compliance)
File: 829ce3b8-065c-41a3-ad57-e0accfea82d2.md

title: Unknown Port Exposed To Internet hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 829ce3b8-065c-41a3-ad57-e0accfea82d2 Query name: Unknown Port Exposed To Internet Platform: CloudFormation Severity: <span style="color:#bb2124">High</span> Category: Networking and Firewall URL: AWS Security Group should not have an unknown port exposed to the entire Internet<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="9" Resources: InstanceSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Expose unknown port to client host VpcId: Ref: myVPC SecurityGroupIngress: IpProtocol: tcp FromPort: 23 ToPort: 25 CidrIp: 0.0.0.0/0 ``` ```json title="Positive test num. 2 - json file" hl_lines="12" { "Resources": { "InstanceSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Expose unknown port to client host", "VpcId": { "Ref": "myVPC" }, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 110, "ToPort": 119, "CidrIp": "0.0.0.0/0" } ] } } } } ``` ```yaml title="Negative test num. 1 - yaml file" Resources: InstanceSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Expose known ports to client host VpcId: Ref: myVPC SecurityGroupIngress: IpProtocol: tcp FromPort: 20 ToPort: 23 CidrIp: 0.0.0.0/0 ``` ```json title="Negative test num. 2 - json file" { "Resources": { "InstanceSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Expose known port to client host", "VpcId": { "Ref": "myVPC" }, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" } ] } } } } ```
Project: StarRocks (App Definition and Development / Database)
File: isnotnull.md

displayed_sidebar: "English" Checks whether the value is not `NULL`, returns `1` if it is not `NULL`, and returns `0` if it is `NULL`. ```Haskell ISNOTNULL(v) ``` `v`: the value to check. All date types is supported. Returns 1 if it is not `NULL`, and returns 0 if it is `NULL`. ```plain text MYSQL > SELECT c1, isnotnull(c1) FROM t1; ++--+ | c1 | `c1` IS NULL | ++--+ | NULL | 0 | | 1 | 1 | ++--+ ```
Project: StarRocks (App Definition and Development / Database)
File: schema_privileges.md

displayed_sidebar: "English" `schema_privileges` provides information about database privileges. The following fields are provided in `schema_privileges`: | Field | Description | | -- | | | GRANTEE | The name of the user to which the privilege is granted. | | TABLE_CATALOG | The name of the catalog to which the schema belongs. This value is always `def`. | | TABLE_SCHEMA | The name of the schema. | | PRIVILEGE_TYPE | The privilege granted. Each row lists a single privilege, so there is one row per schema privilege held by the grantee. | | ISGRANTABLE | `YES` if the user has the `GRANT OPTION` privilege, `NO` otherwise. The output does not list `GRANT OPTION` as a separate row with `PRIVILEGETYPE='GRANT OPTION'`. |
Project: OpenTofu (Provisioning / Automation & Configuration)
File: releasing-new-version.md

OpenTofu's plugin protocol is the contract between OpenTofu's plugins and OpenTofu, and as such releasing a new version requires some coordination between those pieces. This document is intended to be a checklist to consult when adding a new major version of the protocol (X in X.Y) to ensure that everything that needs to be is aware of it. The protocol is defined in protobuf files that live in the opentofu/opentofu repository. Adding a new version of the protocol involves creating a new `.proto` file in that directory. It is recommended that you copy the latest protocol file, and modify it accordingly. The repository serves as the foundation for OpenTofu's plugin ecosystem. It needs to know about the new major protocol version. Either open an issue in that repo to have the Plugin SDK team add the new package, or if you would like to contribute it yourself, open a PR. It is recommended that you copy the package for the latest protocol version and modify it accordingly. The OpenTofu Registry validates the protocol versions a provider advertises support for when ingesting providers. Providers will not be able to advertise support for the new protocol version until it is added to that list. OpenTofu only downloads providers that speak protocol versions it is compatible with from the Registry during `tofu init`. When adding support for a new protocol, you need to tell OpenTofu it knows that protocol version. Modify the `SupportedPluginProtocols` variable in opentofu/opentofu's `internal/getproviders/registry_client.go` file to include the new protocol. Use the provider test framework to test a provider written with the new protocol. This end-to-end test ensures that providers written with the new protocol work correctly with the test framework, especially in communicating the protocol version between the test framework and OpenTofu. Publish a provider, either to the public registry or to the staging registry, and test running `tofu init` and `tofu apply`, along with exercising any of the new functionality the protocol version introduces. This end-to-end test ensures that all the pieces needing to be updated before practitioners can use providers built with the new protocol have been updated.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: logos.md

id: logos title: Logos sidebar_label: Logo assets description: Guidelines for how to use the Backstage logos and icons Guidelines for how to use the Backstage logo and icon can be found . The assets below are all in `.svg` format. Other formats are available in the . <a href="https://backstage.io/logoassets/svg/LogoWhite.svg" aria-label='Link to Backstage White logo svg'> <img src="https://backstage.io/logoassets/svg/LogoWhite.svg" alt='Backstage White logo' width="600" /> </a> <a href="https://backstage.io/logoassets/svg/LogoTeal.svg" aria-label='Link to Backstage Teal logo svg'> <img src="https://backstage.io/logoassets/svg/LogoTeal.svg" alt='Backstage Teal logo' width="600" /> </a> <a href="https://backstage.io/logoassets/svg/LogoBlack.svg" aria-label='Link to Backstage Black logo svg'> <img src="https://backstage.io/logoassets/svg/LogoBlack.svg" alt='Backstage Black logo' width="600" className="logoWhite" class="logoWhite" /> </a> <div> <a href="https://backstage.io/logoassets/svg/IconWhite.svg" aria-label='Link to Backstage White icon'> <img src="https://backstage.io/logoassets/svg/IconWhite.svg" alt='Backstage White Icon' width="180" height="180" /> </a> <a href="https://backstage.io/logoassets/svg/IconTeal.svg" aria-label='Link to Backstage Teal icon'> <img src="https://backstage.io/logoassets/svg/IconTeal.svg" alt='Backstage Teal Icon' width="180" height="180" /> </a> <a href="https://backstage.io/logoassets/svg/IconGradient.svg" aria-label='Link to Backstage Gradient icon'> <img src="https://backstage.io/logoassets/svg/IconGradient.svg" alt='Backstage Gradient Icon' width="180" height="180" /> </a> <a href="https://backstage.io/logoassets/svg/IconBlack.svg" aria-label='Link to Backstage Black icon'> <img src="https://backstage.io/logoassets/svg/IconBlack.svg" alt='Backstage Black Icon' width="180" height="180" className="logoWhite" class="logoWhite" /> </a> </div>
Project: Crate.io (App Definition and Development / Database)
File: PULL_REQUEST_TEMPLATE.md

[ ] Added an entry in the latest `docs/appendices/release-notes/<x.y.0>.rst` for user facing changes [ ] Updated documentation & `sql_features` table for user facing changes [ ] Touched code is covered by tests is signed [ ] This does not contain breaking changes, or if it does: It is released within a major release It is recorded in the latest `docs/appendices/release-notes/<x.y.0>.rst` It was marked as deprecated in an earlier release if possible You've thought about the consequences and other components are adapted (E.g. AdminUI)
Project: KICS (Provisioning / Security & Compliance)
File: f509931b-bbb0-443c-bd9b-10e92ecf2193.md

title: IAM Group Without Users hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: f509931b-bbb0-443c-bd9b-10e92ecf2193 Query name: IAM Group Without Users Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: IAM Group should have at least one user associated<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="2" name: Group1 iam_group: name: testgroup1 state: present ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="2" name: Group2 iam_group: name: testgroup2 managed_policy: arn:aws:iam::aws:policy/AmazonSNSFullAccess users: state: present ``` ```yaml title="Negative test num. 1 - yaml file" name: Group3 iam_group: name: testgroup2 managed_policy: arn:aws:iam::aws:policy/AmazonSNSFullAccess users: test_user1 test_user2 state: present ```
Project: Meshery (Provisioning / Automation & Configuration)
File: accessing-meshery-ui.md

{% if page.display-title != "false" %} {% endif %} After successfully deploying Meshery, you can access Meshery's web-based user interface. Your default browser will be automatically opened and directed to Meshery UI (default location is ). You can use the following command to open Meshery UI in your default browser: {% capture code_content %} mesheryctl system dashboard {% endcapture %} {% include code.html code=code_content %} If you have installed Meshery on Kubernetes or a remote host, you can access Meshery UI by exposing it as a Kubernetes service or by port forwarding to Meshery UI. {% capture code_content %} mesheryctl system dashboard --port-forward {% endcapture %} {% include code.html code=code_content %} Depending upon how you have networking configured in Kubernetes, alternatively, you can use kubectl to port forward to Meshery UI. {% capture code_content %}kubectl port-forward svc/meshery 9081:9081 --namespace meshery{% endcapture %} {% include code.html code=code_content %} <details> <summary>Customizing Meshery Provider Callback URL</summary> Customize your Meshery Provider Callback URL. Meshery Server supports customizing authentication flow callback URL, which can be configured in the following way: {% capture codecontent %}$ MESHERYSERVERCALLBACKURL=https://custom-host mesheryctl system start{% endcapture %} {% include code.html code=code_content %} <br /> Meshery should now be running in your Kubernetes cluster and Meshery UI should be accessible at the `EXTERNAL IP` of `meshery` service. </details> Production deployments are recommended to access Meshery UI by setting up a reverse proxy or by using a LoadBalancer. Log into the of your choice.
Project: CyberArk Conjur (Provisioning / Key Management)
File: SECURITY.md

This document outlines security procedures and general policies for the CyberArk Conjur suite of tools and products. * The CyberArk Conjur team and community take all security bugs in the Conjur suite seriously. Thank you for improving the security of the Conjur suite. We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your contributions. Report security bugs by emailing the lead maintainers at security@conjur.org. The maintainers will acknowledge your email within 2 business days. Subsequently, we will send a more detailed response within 2 business days of our acknowledgement indicating the next steps in handling your report. After the initial reply to your report, the security team will endeavor to keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance. Report security bugs in third-party modules to the person or team maintaining the module. When the security team receives a security bug report, they will assign it to a primary handler. This person will coordinate the fix and release process, involving the following steps: Confirm the problem and determine the affected versions. Audit code to find any potential similar problems. Prepare fixes for all releases still under maintenance. These fixes will be released as fast as possible. If you have suggestions on how this process could be improved please submit a pull request.
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.2.7.7.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Make NetworkTopology#netLock fair | Major | net | Nanda kumar | Nanda kumar | | | Add checkOperation(WRITE) checks in FSNamesystem | Major | ha, namenode | Erik Krogen | Chao Sun | | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | TestFSImage fails without -Pnative | Major | test | Akira Ajisaka | Akira Ajisaka | | | MiniHadoopClusterManager doesn't respect lack of format option | Minor | . | Erik Krogen | Erik Krogen | | | Backport HDFS-11817 (A faulty node can cause a lease leak and NPE on accessing data) to branch-2.7 | Major | . | Wei-Chiu Chuang | Wei-Chiu Chuang | | | Configure serialFilter in KeyProvider to avoid UnrecoverableKeyException caused by JDK-8189997 | Critical | kms | Gabor Bota | Gabor Bota | | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Release Hadoop 2.7.7 | Major | build | Steve Loughran | Steve Loughran |
Project: KOTS (App Definition and Development / Application Definition & Image Build)
File: proxy_public_images.md

The goal is to reduce number of domains that need to be accessible through proxies from private networks. All images will be pulled through proxy.replicated.com or registry.replicated.com. None of the other registries need to be accessible through firewalls. There will be no magic anonymous access to registries via proxy.replicated.com: Vendors will still need to connect to external registry with valid credentials even if all images are public. `imagePullSecret` will be required in order to pull public images. Public images will not retain original public names on the private instance. All image names will begin with `proxy.replicated.com`. This change will not apply to airgap builds and installs. If instance has access to pubic registry, missing image from airgap bundle will still be pulled from the internet. An end customer may desire to keep access to public internet minimal from a KOTS managed cluster. Delivering public images to the cluster is the only part that requires access to domains other than replicated.com. This will be an opt-in feature, enabled by including the new `proxyPublicImages` flag in the `kots.io/Application` spec. A valid link to the external registry will need to be created by the vendor. Public image will be pulled using valid credentials as if it were a private image. The following field will be added to Application type: ``` type ApplicationSpec struct { ... ProxyPublicImages bool `json:"proxyPublicImages,omitempty"` ... } ``` The call to `IsPrivateImage` function will skipped when `ProxyPublicImages` is set to `true`. This will require modifying the following functions: `localImageName` `GetPrivateImages` `copyOneImage` `localImageName` (the template function used with `additionalImages` key) An alternative to this method is to push images to private repos. These can be hosted by any registry, including registry.replicated.com. The downside of this method is the requirement that vendors modify their CI process or make currently public repos private. There are no known impacts on security.
Project: Tetragon (Provisioning / Security & Compliance)
File: submitting-a-pull-request.md

title: "Submitting a pull request" weight: 5 description: "Learn how to submit a pull request to the project" Contributions must be submitted in the form of pull requests against the upstream GitHub repository at https://github.com/cilium/tetragon. Fork the Tetragon repository. Push your changes to the topic branch in your fork of the repository. Submit a pull request on https://github.com/cilium/tetragon. Before hitting the submit button, please make sure that the following requirements have been met: Each commit compiles and is functional on its own to allow for bisecting of commits. All code is covered by unit and/or runtime tests where feasible. All changes have been tested and checked for regressions by running the existing testsuite against your changes. All commits contain a well written commit description including a title, description and a `Fixes: #XXX` line if the commit addresses a particular GitHub issue identified by its number. Note that the GitHub issue will be automatically closed when the commit is merged. ``` doc: add contribution guideline and how to submit pull requests Tetragon Open Source project was just released and it does not include default contributing guidelines. This patch fixes this by adding: CONTRIBUTING.md file in the root directory as suggested by github documentation: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors Development guide under docs directory with a section on how to submit pull requests. Moves the DEVELOP.md file from root directory to the `docs/contributing/development/` one. Fixes: #33 Signed-off-by: Djalal Harouni <djalal@cilium.io> ``` Note: Make sure to include a blank line in between commit title and commit description. All commits are signed off. See the section [Developers Certificate of Origin]({{< ref "/docs/contribution-guide/developer-certificate-of-origin" >}}). All important steps in have been followed. You can run `make vendor` then add and commit your changes. You need to add a signed-off-by line to your commit messages. The easiest way to do this is with `git fetch origin/main && git rebase --signoff origin/main`. Then push your changes.
Project: ShardingSphere (App Definition and Development / Database)
File: preview-sql.en.md

+++ title = "PREVIEW SQL" weight = 3 +++ The `PREVIEW SQL` syntax is used to preview `SQL` execution plan. {{< tabs >}} {{% tab name="Grammar" %}} ```sql PreviewSql ::= 'PREVIEW' sqlStatement ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} | Column | Description | ||--| | datasourcename | storage unit name | | actual_sql | actual excute SQL statement | Preview `SQL` execution plan ```sql PREVIEW SELECT * FROM t_order; ``` ```sql mysql> PREVIEW SELECT * FROM t_order; ++--+ | datasourcename | actual_sql | ++--+ | su1 | SELECT * FROM torder | ++--+ 1 row in set (0.18 sec) ``` `PREVIEW`
Project: Cloudify (Provisioning / Automation & Configuration)
File: README.md

Cloudify Integration Tests ========================== Install cloudify-common, cloudify-cli, manager_rest, and the tests package. Make sure you have a manager docker image, `docker load` it if necessary. Run pytest, eg: ``` pytest -vxs integrationtests/tests/agentlesstests/testworkflow.py::BasicWorkflowsTest::testexecute_operation ``` We add several commandline arguments for pytest: `--tests-source-root` - points to a directory that contains repositories with Cloudify code (or symlinks to them). Those repositories will be mounted into the container and used for the tests. `--image-name` - name of the docker image to run (default: `cloudify-manager-aio:latest`). Can be from a docker repository. `--keep-container` - don't delete the container after the test is done. `--container-id` - use a pre-spawned container (might be from a separate test run that provided --keep-container) for this test. Use this to greatly increase iteration speed when working with the tests. `--k8s-namespace` - use the Kubernetes cluster (must be already spawned in that namespace) to run the test. `--lightweight` - run a container without optional services, making it lighter and faster Repositories from "tests-source-root" are going to be mounted into the in-container virtualenvs. The mount list is maintained on an as-needed basis, and is in `tests/conftest.py`. Feel free to add more entries to it, if there's some source mounting missing that you need.
Project: ClickHouse (App Definition and Development / Database)
File: v22.6.7.7-stable.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Fix TGZ packages. (). Backported in : Proxy resolver stop on first successful request to endpoint. (). Backported in : Fix potential dataloss due to a bug in AWS SDK (https://github.com/aws/aws-sdk-cpp/issues/658). Bug can be triggered only when clickhouse is used over S3. ().