cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: c8ae9ba9-c2f7-4e5c-b32e-a4b7712d4d22.md

title: Secrets Manager Should Specify KmsKeyId hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: c8ae9ba9-c2f7-4e5c-b32e-a4b7712d4d22 Query name: Secrets Manager Should Specify KmsKeyId Platform: CloudFormation Severity: <span style="color:#edd57e">Low</span> Category: Secret Management URL: Secrets Manager Secret should explicitly specify KmsKeyId, this will allow the secret to be shared cross-account<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="6" AWSTemplateFormatVersion: 2010-09-09 Description: A sample template Resources: SecretsManagerSecret: Type: AWS::SecretsManager::Secret Properties: Description: String GenerateSecretString: GenerateSecretString Name: String SecretString: String Tags: Tag ``` ```json title="Positive test num. 2 - json file" hl_lines="7" { "AWSTemplateFormatVersion": "2010-09-09T00:00:00Z", "Description": "A sample template", "Resources": { "SecretsManagerSecret": { "Type": "AWS::SecretsManager::Secret", "Properties": { "Name": "String", "SecretString": "String", "Tags": [ "Tag" ], "Description": "String", "GenerateSecretString": "GenerateSecretString" } } } } ``` ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: 2010-09-09 Description: A sample template Resources: SecretsManagerSecret: Type: AWS::SecretsManager::Secret Properties: Description: String GenerateSecretString: GenerateSecretString KmsKeyId: String Name: String SecretString: String Tags: Tag ``` ```json title="Negative test num. 2 - json file" { "AWSTemplateFormatVersion": "2010-09-09T00:00:00Z", "Description": "A sample template", "Resources": { "SecretsManagerSecret": { "Type": "AWS::SecretsManager::Secret", "Properties": { "Description": "String", "GenerateSecretString": "GenerateSecretString", "KmsKeyId": "String", "Name": "String", "SecretString": "String", "Tags": [ "Tag" ] } } } } ```
Project: KICS (Provisioning / Security & Compliance)
File: ae9c56a6-3ed1-4ac0-9b54-31267f51151d.md

title: Apk Add Using Local Cache Path hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: ae9c56a6-3ed1-4ac0-9b54-31267f51151d Query name: Apk Add Using Local Cache Path Platform: Dockerfile Severity: <span style="color:#5bc0de">Info</span> Category: Supply-Chain URL: When installing packages, use the '--no-cache' switch to avoid the need to use '--update' and remove '/var/cache/apk/*'<br> ```dockerfile title="Positive test num. 1 - dockerfile file" hl_lines="2" FROM gliderlabs/alpine:3.3 RUN apk add --update-cache python WORKDIR /app ONBUILD COPY . /app ONBUILD RUN virtualenv /env && /env/bin/pip install -r /app/requirements.txt EXPOSE 8080 CMD ["/env/bin/python", "main.py"] ``` ```dockerfile title="Positive test num. 2 - dockerfile file" hl_lines="2" FROM gliderlabs/alpine:3.3 RUN apk add --update-cache python WORKDIR /app ONBUILD COPY . /app ONBUILD RUN virtualenv /env; \ /env/bin/pip install -r /app/requirements.txt EXPOSE 8080 CMD ["/env/bin/python", "main.py"] ``` ```dockerfile title="Negative test num. 1 - dockerfile file" FROM gliderlabs/alpine:3.3 RUN apk add --no-cache python WORKDIR /app ONBUILD COPY . /app ONBUILD RUN virtualenv /env && /env/bin/pip install -r /app/requirements.txt EXPOSE 8080 CMD ["/env/bin/python", "main.py"] ``` ```dockerfile title="Negative test num. 2 - dockerfile file" FROM gliderlabs/alpine:3.3 RUN apk add --no-cache python WORKDIR /app ONBUILD COPY . /app ONBUILD RUN virtualenv /env; \ /env/bin/pip install -r /app/requirements.txt EXPOSE 8080 CMD ["/env/bin/python", "main.py"] ```
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.2.6.6.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Upgrade Tomcat to 6.0.48 | Blocker | kms | John Zhuge | John Zhuge | | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Improve quota initialization performance | Major | . | Kihwal Lee | Kihwal Lee | | | Improve container-executor validation check | Major | security, yarn | Eric Yang | Eric Yang | | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | ForkJoin thread pool leaks | Major | . | Kihwal Lee | Kihwal Lee | | | Findbugs warning in resourcemanager in branch-2.7 and branch-2.6 | Minor | resourcemanager | Varun Saxena | Akira Ajisaka | | | Intermittent deadlock in NameNode when failover happens. | Blocker | namenode | Abhishek Modi | Akira Ajisaka | | | Potential deadlock in NN when failing over | Critical | namenode | Erik Krogen | Erik Krogen | | | Race in UGI.reloginFromKeytab | Major | security | Duo Zhang | Duo Zhang | | | Yarn NM using LCE shows a failure when trying to delete a non-existing dir | Major | yarn | Wilfred Spiegelenburg | Wilfred Spiegelenburg | | | AmIpFilter drops query parameters on redirect | Major | . | Wilfred Spiegelenburg | Wilfred Spiegelenburg | | | Use OpenJDK 7 instead of Oracle JDK 7 to avoid oracle-java7-installer failures | Major | build | Akira Ajisaka | Akira Ajisaka | | | NPE due to Invalid KerberosTicket in UGI | Major | . | Jitendra Nath Pandey | Mukul Kumar Singh | | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | TestFSNameSystemMBean should wait until JMX cache is cleared | Major | test | Akira Ajisaka | Erik Krogen |
Project: Checkov (Provisioning / Security & Compliance)
File: noise_issue.md

name: Noise Issue about: Create an issue regarding checkov's output and noise it generates. title: '' labels: 'noise' assignees: '' Describe the issue Please explain the use case that leads to this noise being generated. Examples Please share an example code sample (in the IaC of your choice) + the expected outcomes. Version (please complete the following information): Checkov Version [e.g. 22] Additional context Add any other context about the problem here.
Project: ArangoDB (App Definition and Development / Database)
File: result_operator_out.md

+++ title = "`std::ostream &operator<<(std::ostream &, const basic_result<T, E, NoValuePolicy> &)`" description = "Serialises a `basic_result` to a `std::ostream`." +++ Serialises a `basic_result` to a `std::ostream`. Serialisation format is: ``` <unsigned int flags><space><valuetype if set and not void><errortype if set and not void> ``` This is the wrong function to use if you wish to print human readable output. Use {{% api "std::string print(const basic_result<T, E, NoValuePolicy> &)" %}} instead. Overridable: Not overridable. Requires: That `operator<<` is a valid expression for `std::ostream` and `T` and `E`. Namespace: `BOOSTOUTCOMEV2_NAMESPACE` Header: `<boost/outcome/iostream_support.hpp>` (must be explicitly included manually).
Project: Memphis (App Definition and Development / Streaming & Messaging)
File: CONTRIBUTING.md

That's amazing that you reached this section! Memphis is and always will be open-source and community-driven. Our community is our power. "Working on Memphis helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!" Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. Whether its coding, user interface design, graphic design, writing, or organizing, if youre looking for practice, theres a task for you on an open-source project. &#x20; 0\. Join to Memphis channel &#x20; 1\. Install &#x20; 2\. Fork &#x20; 3\. Clone the forked repo to your local station &#x20; 4\. Run a local memphis-metadata db using docker ``` curl -s https://memphisdev.github.io/memphis-docker/docker-compose-dev-env.yml -o docker-compose-dev-env.yml && docker compose -f docker-compose-dev-env.yml -p memphis up ``` &#x20; 5\. Install Memphis dependencies - enter the cloned directory and run ``` go get -d -v . ``` &#x20; 6\. Run Memphis in debug mode (If you're using vscode, click F5) or run via terminal via: ``` USERPASSBASEDAUTH="true" DEVENV="true" DOCKER_ENV="true" go run main.go ``` &#x20; 1\. The source files of the UI can be found in a directory called &#x20; 2\. Navigate to "ui\_src" dir &#x20; 3\. Install dependencies by running `npm install` &#x20; 4\. Run the UI locally by running `npm start` &#x20; 5\. Start coding! Here are some &#x20; 6\. Once done - push your code and create a pull request to merge your updates with memphis main repo Once you have established, you can start coding. Memphis backend opportunities are -&#x20; Memphis Broker SDKs: , , , or Grab a , and once done - push your changes and open a "pull request" As a data engineer, it would be great to get your feedback, potential use cases, QA, and push memphis to the limit in terms of data workloads would be an amazing contribution, as at the end of the day, you are our champion! As a DevOps engineer, you can find multiple paths of contribution &#x20; DevOps
Project: StarRocks (App Definition and Development / Database)
File: NOTICE-aircompressor.md

Snappy Copyright Notices ========================= Copyright 2011 Dain Sundstrom <dain@iq80.com> Copyright 2011, Google Inc.<opensource@google.com> Snappy License =============== Copyright 2011, Google Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Google Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: GITHUB_LABELS.md

The InSpec teams' intent is that issue/PR labelling be a low-stakes operation. We created many of the labels, after looking over the labelling system used by the Habitat project. They have an and a simple . The inspec labels are a smaller list. The goal for people is for the labeling system to be useful and practical: Able to discover patterns (for example, clusters of issues around a certain aspect, such as UX) Easy to find related issues when starting a batch of work ("I want to work on the website. What are all of ouor current issues with the website?") Enable interested parties to search for issue / PR counts by their desired platform The colors don't mean anything at this point; we've generally just accepted the default. Currently, we have one anti-goal: Do not indicate priority or timeline information via labelling. That's high-stakes, and quickly becomes out of date. The InSpec team internally tracks its Chef, Inc. priorities; all other issues may be addressed on an as-needed, FOSS basis. Several machines are interested in our labels, including: the expeditor configuration uses labels to bump minor versions, and construct changelogs, sorting PRs by Type. the GitHub search facility looks for certain labels to list opportunities to participate in FOSS projects Whether you are a community member or a team member, just go ahead and apply what you think is sensible. It's low stakes. If they need to be tweaked a bit, a team member will do it, and it's not a big deal. We just appreciate the effort! Only InSpec team members can manage labels. If you're a member of the community who has a suggestion, you can let us know on Community Slack, or by opening an issue. Have a look at the existing list, and add something if it's clearly missing. If it's not clear, talk it over in the team channel. Err on the side of boldness; it's easy to merge them later if needed. It's easier to merge things that are too finely distinguished than too separate things that were lumped together. A team member can edit the text, color or description of a label at anytime. It's low stakes and non-destructive. That is destructive. If we're retiring a label, we should talk about it. These labels reflect the aspects of the project as used by people: for example, Performance, Security, or UX. Directly indicates that the issue concerns an problem / feature request with the `inspec` executable. Labels here refer to the specific subcommands. This is a refinement of the `Component` group just for the CLI. Refers to the major subsystems of Inspec. Refers to a problem specific to a particular platform. Indicates that the issue is slated for a particular release, or to be backported. Refers to the fate of the issue. Note that Github handles Open/Closed for us; so we use this label group for things like marking a duplicate, or marking something "wontfix" (which we gently call "No Action"). Refers to the nature of the issue or PR: is it a Bug? A request for a new Feature? This can be subjective in some cases. Everything else. Not everything has been ported over from the prior scheme.
Project: StarRocks (App Definition and Development / Database)
File: bitmap_and.md

displayed_sidebar: "English" Calculates the intersection of two input bitmaps and returns the new bitmap. ```Haskell BITMAP BITMAP_AND(BITMAP lhs, BITMAP rhs) ``` ```plain text MySQL > select bitmapcount(bitmapand(tobitmap(1), tobitmap(2))) cnt; ++ | cnt | ++ | 0 | ++ MySQL > select bitmapcount(bitmapand(tobitmap(1), tobitmap(1))) cnt; ++ | cnt | ++ | 1 | ++ ``` BITMAP_AND,BITMAP
Project: SPIFFE (Provisioning / Key Management)
File: CONTRIBUTING.md

The change management process for the SPIFFE Project is designed to be transparent, fair, and efficient. Anyone may contribute to a project in the SPIFFE repositories that they have read access to, provided they: Abide by the CNCF Can certify the clauses in the (DCO) To get started: First, to become familiar with how the SPIFFE Project is managed Make sure you're familiar with our when appropriate If you're new to the SPIFFE Project, we recommend that you join us on the mailing lists and Slack to discuss any potential changes you'd like to see made. If your proposal comes under the purview of a SIG, reach out to the SIG lead and seek their feedback first (bugfixes and changes with minor impact don't need this). The SIG lead may refer you to the broader group. Fork the repo Commit changes to your fork Update the docs, if necessary Ensure your branch is based on the latest commit in `main` Ensure all tests pass (see project docs for more information) Make sure your commit messages contain a `Signed-off-by: <your-email-address>` line (see `git-commit --signoff`) to certify the Open a against the upstream `main` branch All changes to SPIFFE projects must be code reviewed in a pull request (this goes for everyone, even those who have merge rights). Pull requests are approved according to the process described in our [governance policies](/GOVERNANCE.md). At least one maintainer must approve the pull request, and for large changes, another independent reviewer must approve it too. Once your pull request is submitted, it's your responsibility to: Respond to reviewer's feedback Keep it merge-ready at all times until it has been approved and actually merged Following approval, the pull request will be merged by the last maintainer to approve the request. Generally, these are the coding conventions SPIFFE projects should follow. Maintainers will consider these conventions when reviewing pull requests. General* Command-line flags should use dashes, not underscores Plugin and API protobuf comments are expected to be accompanied with markdowns generated with All documentation and code must conform to the All filenames should be lowercase Source filenames and directories should use underscores, no dashes (snake case) Document filenames and directories should use dashes rather than underscores (kebab case) Most significant functionality must come with unit tests Significant features should have integration and/or end-to-end tests Unit tests should be fully hermetic. Only access resources in the test binary Concurrent unit test runs must pass Go* * Bash* Python* When third-party code must be included, all licenses must be preserved. This includes modified third-party code and excerpts, as well. All repositories under this project should include: A detailed `README.md` which includes a link back to this file A `LICENSE` file with the Apache 2.0 license A file listing the maintainers All code projects should use the [Apache License version 2.0](https://www.apache.org/licenses/LICENSE-2.0), and all documentation repositories should use the .
Project: ShardingSphere (App Definition and Development / Database)
File: OpenSource.en.md

+++ title = "Getting started with Apache ShardingSphere" weight = 2 chapter = true +++ Apache ShardingSphere is the only database middleware project of Apache software foundation. It is mainly used in distributed database related scenarios such as data fragmentation, distributed transaction and distributed governance. This live broadcast will share why we want to participate in open source; the Apache software foundation, the core principles of Apache ShardingSphere and how to embark on the road of open source. {{< bilibili BV16K4y1b7CZ >}}
Project: Shifu (Provisioning / Automation & Configuration)
File: README.md

``` make kube-builder-init ``` ``` kind delete cluster && kind create cluster ``` ``` make install ``` ``` make uninstall ``` ``` make kube-builder-create-api-edgedevice ``` ``` make docker-buildx-load IMG=edgehub/shifu-controller:v0.0.1 ``` ``` make deploy IMG=edgehub/shifu-controller:v0.0.1 ``` ``` kubectl apply -f config/samples/shifuv1alpha1edgedevice.yaml ``` ``` make generate-controller-yaml IMG=edgehub/shifu-controller:v0.0.1 generate-install-yaml ```
Project: YugabyteDB (App Definition and Development / Database)
File: yba_storage-config_azure_describe.md

Describe an Azure YugabyteDB Anywhere storage configuration Describe an Azure storage configuration in YugabyteDB Anywhere ``` yba storage-config azure describe [flags] ``` ``` -h, --help help for describe ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -n, --name string [Optional] The name of the storage configuration for the operation. Required for create, delete, describe, update. -o, --output string Select the desired output format. Allowed values: table, json, pretty. (default "table") --timeout duration Wait command timeout, example: 5m, 1h. (default 168h0m0s) --wait Wait until the task is completed, otherwise it will exit immediately. (default true) ``` - Manage a YugabyteDB Anywhere Azure storage configuration
Project: EJBCA Community (Provisioning / Security & Compliance)
File: CONTRIBUTING.md

Thank you for contributing to EJBCA! In this guide, you get an overview of the contribution workflow from starting a discussion or opening an issue, to creating, reviewing, and merging a pull request. For an overview of the project, see . If you have a question or problem, you can , if someone has already found a solution to your problem. Or you can and ask your question. If you find a problem with EJBCA, . If a related discussion or issue doesn't exist, you can . An issue can be converted into a discussion if regarded as one. You are welcome to send patches, under the LGPLv2.1+ license, as pull requests. For more information, see . For minor updates, you can instead choose to create an issue with short snippets of code. See above. Create a JUnit test case for your change, it may be a simple addition to an existing test. If you do not know how to do this, ask us and we will help you. If you run into any merge issues, check out this to help you resolve merge conflicts and other issues. For more information, refer to the EJBCA documentation on . Don't forget to self-review. Please follow these simple guidelines: Keep the patch limited, only change the parts related to your patch. Do not change other lines, such as whitespace, adding line breaks to Java doc, etc. It will make it very hard for us to review the patch. For acceptance, pull requests need to meet specific quality criteria, including tests for anything substantial. Someone on the EJBCA core team will review the pull request when there is time, and let you know if something is missing or suggest improvements. If it is a useful and generic feature it will be integrated in EJBCA to be available in a later release. For substantial, non-trivial contributions, you will be asked to sign a contributor assignment agreement. Optionally, you can also have your name and contact information listed on the page.
Project: Cloud Custodian (Provisioning / Automation & Configuration)
File: cli.md

`zerodark metrics load-app` Query CMDB for all application resources, then query cloudwatch metrics for those resources. `zerodark metrics load-account` Query CMDB for all resources in the account. `zerodark metrics server` `zerodark cmdb load-resources` `zerodark cmdb show-app-resources` `zerodark cmdb server` `zerodark flows load-account` `zerodark flows load-app` `zerodark flows ingest-enriched` Load enriched flow log records from s3 `zerodark flows enrich-account` Ingest flows and output enriched flows to s3 `zerodark flows enrich-app` `zerodark flows server-enrich` SQS Worker for flow log enrichment `zerodark flows server-account` SQS Worker for flow log loading for an account