cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: b592ffd4-0577-44b6-bd35-8c5ee81b5918.md

title: No Password Policy Enabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: b592ffd4-0577-44b6-bd35-8c5ee81b5918 Query name: No Password Policy Enabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: IAM password policies should be set through the password minimum length and reset password attributes<br> ```tf title="Positive test num. 1 - tf file" hl_lines="5 16 23 30 31" resource "awsiamuserloginprofile" "positive2" { user = awsiamuser.example.name pgpkey = "keybase:somepersonthatexists" passwordresetrequired = false password_length = 15 } resource "awsiamuserloginprofile" "positive3" { user = awsiamuser.example.name pgpkey = "keybase:somepersonthatexists" passwordresetrequired = true password_length = 13 } resource "awsiamuserloginprofile" "positive6" { user = awsiamuser.example.name pgpkey = "keybase:somepersonthatexists" password_length = 13 } resource "awsiamuserloginprofile" "positive7" { user = awsiamuser.example.name pgpkey = "keybase:somepersonthatexists" passwordresetrequired = false password_length = 13 } ``` ```tf title="Negative test num. 1 - tf file" resource "awsiamuserloginprofile" "negative1" { user = awsiamuser.example.name pgpkey = "keybase:somepersonthatexists" passwordresetrequired = true password_length = 15 } ```
Project: YugabyteDB (App Definition and Development / Database)
File: docs-checklist.md

title: Docs contribution checklist headerTitle: Docs checklist linkTitle: Docs checklist description: Review the steps to start contributing documentation menu: preview: identifier: docs-checklist parent: docs weight: 2911 type: docs . Internal users: file YugabyteDB Anywhere and YugabyteDB Managed issues in Jira. Docs are written in Markdown and built using the Hugo static site generator. For live previews as you work, install the command-line tools (macOS), Node.js, and Hugo. (See .) Pull requests: Open PRs against a fork of the yugabyte/yugabyte-db repository. Add tag "area/documentation". Internal users: add to project Documentation, and assign a member of the docs team as a reviewer. Regardless of the type of problem (such as errors, bad links, out-of-date content, or new features), if you don't intend to and make a pull request right away to fix the problem, please create an issue in GitHub or Jira (Yugabyte internal users only) to track the problem. Every YugabyteDB docs page has a Contribute button that lets you file an issue or make a suggestion, both of which help you to create a GitHub issue. You can also create an issue . The GitHub issue template starts your issue title with `[docs]` for faster scanning, and adds the `area/documentation` label. You can also add the section of the docs (for example, `[docs] [troubleshooting]`) for added context. Internal users, add a member of the docs team as a reviewer, in addition to any other technical reviewers, and add your ticket directly to the Documentation project. If you spot a problem on a page (typos, spelling and grammar, minor page updates, broken links, and so on) the Contribute button has an Edit this page option that takes you to the page in GitHub. If you are signed in, you can edit the page and propose the change. GitHub will automatically create a branch for you. For more complex changes, you'll need to build the docs and submit pull requests. Use the to help you find the page you want to edit, or the correct section for a new page you want to add. Follow the instructions in to fork the repository and get the docs site running on your local machine. Follow the instructions in to make your changes (read the , too!) and submit a pull request. Congratulations on the change! You should now for review and leave a message on the Slack channel. After it's reviewed and approved, your docs change will get merged in.
Project: Pachyderm (App Definition and Development / Streaming & Messaging)
File: CONTRIBUTING.md

We use to both manage dependencies and publish this package. You can find information about installing this software . Once both `poetry` is installed, you can use `poetry` to create your virtual environment for this project. The following command (run at the root of this project) will create a virtual environment within the `.venv` directory: ```bash poetry install source .venv/bin/activate ``` Code layout, as of Jun. 30, 2023: ``` . docs - Auto-generated API docs examples - The examples pachderm_sdk/ main.py - Location for package scripts (cli) api/ - Generated API code. `extension.py` files are hand-written. _additions.py - patches to generated proto objects. extension.py - Manually-written additions to the generated API stubs. client.py - The higher-level `Client` class. config.py - Config file parsing code. constants.py - Centralized location for constant values. datum_batching.py - Decorator for datum-batching code. errors.py - Centralized location for custom errors. interceptor.py - gRPC interceptor implementation. proto/ - Code generation of the protobuf files. tests/ - Pytests fixtures.py - Location for pytest fixtures used throughout tests. Dockerfile.datum-batching-test - Dockerfile used to build image for datum-batching test. poetry.lock - Lock file for this packages dependencies. pyproject.toml - Package specification file. ``` To execute the tests, run the following command: ```bash poetry run pytest -vvv tests ``` Setting the following environment variables is needed for all the tests to run properly: PACHPYTHONTEST_HOST - Hostname to your pachyderm cluster PACHPYTHONTEST_PORT - Port over which to connect to you pachyderm cluster PACHPYTHONTESTPORTENTERPRISE - Port over which to connect to your enterprise-enabled cluster PACHPYTHONAUTH_TOKEN - Auth token for your enterprise cluster (found in .pachyderm/config.json) This project uses the code formatter. Pytest will automatically check that your code changes pass the black formatter. To run the black formatter: ```bash black <file-or-directory> ``` To generate the documentation, it's easiest to use `poetry` to set up your environment: ```bash poetry install ``` then run the `make` command: ```bash make docs ``` This will generate the documentation under docs/pachyderm_sdk. To see the documentation within your browser, you can run the following: ```bash poetry run python -m http.server --directory docs/pachyderm_sdk ``` and navigate to http://localhost:8000. Releasing the package is done through CircleCI. In the event you need to cut a manual release, you need to set the proper package version in the pyproject.toml file and then run the following command: ```bash poetry publish --build ``` The above command will prompt the user for a PyPI username/password.
Project: secureCodeBox (Provisioning / Security & Compliance)
File: adr_0016.md

title: "ADR-0016: S3 As Backend for Persistent Data" sidebar_label: "ADR-0016" | <!-- --> | <!-- --> | | -- | | | Status: | ACCEPTED | | Date: | 2022-09-13 | | Author(s): | Jannik Hollenbach , Sven Strittmatter | :::info This ADR should have been written prior to implementation. But we started documenting ADR later. This ADR has therefore been written retrospectively to record the decision made at that time. ::: secureCodeBox needs to saves two things during the execution of a scan: the "raw results / output" of the scanner (e.g. the XML output of nmap) and the findings the parsers extract from it. In the v1 of the secureCodeBox these were stored in camunda variables which were in turn stored in the underlying database as blobs. As both the raw results and findings can get big (multiple megabytes) this requiered a lot of maintenance work to keep the database working correctly without overflowing. In v2 we decided to shift the storage to store the raw results and findings as separate files in an S3 bucket. S3 was chosen because: it can handle large files without much problems is relatively easy to use is well supported by (most) cloud supporters can be "substituted locally" by minio can be used with presigned urls to easily give individual components temporary read or write access to specific files in the s3 bucket The secureCodeBox requires a S3 bucket locally in the cluster. By default the operator sets up a local minio bucket unless access to an external bucket is configured.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: overview.md

id: overview title: Overview description: A high level overview of the Backstage permission framework covered the various authentication methods of Backstage, but Backstage can also authorize specific data, APIs, or interface actions - meaning that Backstage has the ability to enforce rules about what type of access is allowed for a given user of a system. By default, Backstage endpoints are not protected, and all actions are available to anyone. However, configuring which users can access which resources and actions is a common need for many organizations. The permission framework allows integrators to achieve this through the use of granular permissioning for those resources and actions. The permission framework was designed with a few key properties in mind: Flexibility: the framework allows integrators to configure many different authorization methods. This could include implementations like role-based access control (RBAC), attribute-based access control (ABAC), bespoke logic expressed in code, or integrations with external authorization providers. Usability: the permission framework allows integrators to focus on configuring what they care about (the permission policy) by providing all of its moving parts out of the box. It also allows plugin authors to integrate support for permissions in their plugins without having to make any changes in Backstage core. Plugin authors can add permission support in their plugins by declaring which resources from their plugins can be placed behind authorization and what types of actions users may take upon those resources. Contributors can implement and share authorization methods (such as RBAC). Integrators can author or configure policies that define which users can take certain actions upon which resources. The user triggers a request to perform some action. The request specifies the authorization details using the permission specified by the plugin (in this case, a resource read action). The action may be triggered by a user interacting with the UI, but it can also be a direct request to the plugin's backend. The plugin backend sends a request to the permission framework's backend with the authorization details. The permission framework's backend delegates the authorization decision to the permission policy, which is specified by the integrator using code, a provided authorization method (such as RBAC), or integrations with external authorization providers. An authorization decision is sent to the plugin from the permission backend. The user is either granted access or an error is shown. The plugin is responsible for implementing a response to the user. See the "" permission documentation for Backstage integrators. If you are a plugin author, see the permission on how to integrate permissions into your plugin.
Project: YugabyteDB (App Definition and Development / Database)
File: yba_storage-config_azure_update.md

Update an Azure YugabyteDB Anywhere storage configuration Update an Azure storage configuration in YugabyteDB Anywhere ``` yba storage-config azure update [flags] ``` ``` --sas-token string AZ SAS Token to be updated. Provide the token within double quotes. Can also be set using environment variable AZURESTORAGESAS_TOKEN. --new-name string [Optional] Update name of the storage configuration. -h, --help help for update ``` ``` -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: StarRocks (App Definition and Development / Database)
File: USE.md

displayed_sidebar: "English" Specifies the active database for your session. You can then perform operations, such as creating tables and executing queries. ```SQL USE [<catalogname>.]<dbname> ``` | Parameter | Required | Description | | - | | | | catalogname | No | The catalog name.<ul><li>If this parameter is not specified, a database in `defaultcatalog` is used by default.</li><li>You must specify this parameter when you use a database from an external catalog. For more information, see Example 2.</li><li>You must specify this parameter when you switch databases between different catalogs. For more information, see Example 3.</li></ul>For more information about catalogs, see . | | db_name | Yes | The database name. The database must exist. | Example 1: Use `exampledb` from `defaultcatalog` as the active database of your session. ```SQL USE defaultcatalog.exampledb; ``` Or ```SQL USE example_db; ``` Example 2: Use `exampledb` from `hivecatalog` as the active database of your session. ```SQL USE hivecatalog.exampledb; ``` Example 3: Switch the active database of your session from `hivecatalog.exampletable1` to `icebergcatalog.exampletable2`. ```SQL USE icebergcatalog.exampletable2; ```
Project: ShardingSphere (App Definition and Development / Database)
File: alter-shadow-rule.en.md

+++ title = "ALTER SHADOW RULE" weight = 2 +++ The `ALTER SHADOW RULE` syntax is used to alter shadow rule. {{< tabs >}} {{% tab name="Grammar" %}} ```sql AlterShadowRule ::= 'ALTER' 'SHADOW' 'RULE' shadowRuleDefinition (',' shadowRuleDefinition)* shadowRuleDefinition ::= ruleName '(' storageUnitMapping shadowTableRule (',' shadowTableRule)* ')' storageUnitMapping ::= 'SOURCE' '=' storageUnitName ',' 'SHADOW' '=' storageUnitName shadowTableRule ::= tableName '(' shadowAlgorithm ')' shadowAlgorithm ::= 'TYPE' '(' 'NAME' '=' shadowAlgorithmType ',' propertiesDefinition ')' ruleName ::= identifier storageUnitName ::= identifier tableName ::= identifier algorithmName ::= identifier shadowAlgorithmType ::= string propertiesDefinition ::= 'PROPERTIES' '(' key '=' value (',' key '=' value)* ')' key ::= string value ::= literal ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} `storageUnitMapping` specifies the mapping relationship between the `source` database and the shadow library. You need to use the storage unit managed by RDL, please refer to ; `shadowAlgorithm` can act on multiple `shadowTableRule` at the same time; If `algorithmName` is not specified, it will be automatically generated according to `ruleName`, `tableName` and `shadowAlgorithmType`; `shadowAlgorithmType` currently supports `VALUEMATCH`, `REGEXMATCH` and `SQL_HINT`. Create a shadow rule ```sql ALTER SHADOW RULE shadow_rule( SOURCE=demo_ds, SHADOW=demodsshadow, torder(TYPE(NAME="SQLHINT")), torderitem(TYPE(NAME="VALUEMATCH", PROPERTIES("operation"="insert","column"="userid", "value"='1'))) ); ``` `ALTER`, `SHADOW`, `RULE`, `SOURCE`, `SHADOW`, `TYPE`, `NAME`, `PROPERTIES`
Project: ThreatMapper (Provisioning / Security & Compliance)
File: COMMUNITY.md

Thank you for taking the time to look at Deepfence ThreatMapper. We sincerely hope it helps you to identify and prioritize vulnerable dependencies in your applications, and proves to be useful in protecting you and your users from breaches. You are welcome to show your support for the project in several ways: Please star ThreatMapper on GitHub - thank you! Get some great Deepfence SWAG by joining our Join the , and share and answer questions Share your experiences with the wider community by leaving a review on any of the following locations: * If you'd like to contribute to the project, then is the place to start. Please do! We have some that might be of help.
Project: StarRocks (App Definition and Development / Database)
File: DataGrip.md

displayed_sidebar: "English" DataGrip supports querying both internal data and external data in StarRocks. Create a data source in DataGrip. Note that you must select MySQL as the data source. The parameters that you need to configure are described as follows: Host: the FE host IP address of your StarRocks cluster. Port: the FE query port of your StarRocks cluster, for example, `9030`. Authentication: the authentication method that you want to use. Select Username & Password. User: the username that is used to log in to your StarRocks cluster, for example, `admin`. Password: the password that is used to log in to your StarRocks cluster. Database: the data source that you want to access in your StarRocks cluster. The value of this parameter is in the `<catalogname>.<databasename>` format. `catalog_name`: the name of the target catalog in your StarRocks cluster. Both internal and external catalogs are supported. `database_name`: the name of the target database in your StarRocks cluster. Both internal and external databases are supported.
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.8.16.md

RabbitMQ `3.8.16` is a maintenance release. It reintroduces `rabbitmqpeerdiscovery_aws` plugin that was unintentionally removed from `3.8.15` due to release pipeline changes. This is the first release to drop support for Erlang 22.3 and introduce support for the release. This release is distributed via GitHub, , and . This is the . explains what package repositories and tools can be used to provision a recent version of Erlang `23.3`. See upgrade and compatibility notes first if upgrading from an earlier release series (e.g. `3.7.x`). See the for general documentation on upgrades and for release notes of other releases. Any questions about this release, upgrades or RabbitMQ in general are welcome on the and . This release . Erlang 24 offers non-trivial real world throughput improvements for many RabbitMQ installations and workloads. It is expected to ship in May 2021. In the meantime, see to learn how to provision a recent version of Erlang `23.3`. GitHub issue: This plugin was unintentionally excluded from the distribution in `3.8.15` and has now been added back. GitHub issue: Messaging polling HTTP API endpoint leaked temporary connections it used in case of a polling timeout. Note that this endpoint is not recommended to be used outside of QA environments. Use a via one of the supported messaging protocols. Contributed by @luos. GitHub issue: Cuttlefish has been upgraded from Lager has been upgraded from To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.8.16.tar.xz` instead of the source tarball produced by GitHub.
Project: external-secrets (Provisioning / Security & Compliance)
File: cloak.md

Sync secrets from the to Kubernetes using the External Secrets Operator. Cloak uses the webhook provider built into the External Secrets Operator but also required a proxy service to handle decrypting secrets when they arrive into your cluster. From the Cloak user interface and store the private key on your file system. Now create a kubernetes secret in the same namespace as the External Secrets Operator. ```sh HISTIGNORE='kubectl' kubectl --namespace=external-secrets \ create secret generic cloak-key \ --from-file=ecdhprivatekey=$LOCATIONOFYOURPEMFILE ``` ```yaml {% include 'cloak-proxy-deployment.yaml' %} ``` And a Kubernetes Service so External Secrets Operator can access the proxy. ```yaml {% include 'cloak-proxy-service.yaml' %} ``` You can now place the configuration in any Kubernetes Namespace. ```yaml {% include 'cloak-secret-store.yaml' %} ``` Each `secretKey` reference in the yaml should point to the name of the secret as it is stored in Cloak. ```yaml {% include 'cloak-external-secret.yaml' %} ```
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.2.5.1.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Users are not allowed to view their own jobs, denied by JobACLsManager | Major | . | Yu Gao | Yu Gao | | | The globber will sometimes erroneously return a permission denied exception when there is a non-terminal wildcard | Blocker | . | Colin P. McCabe | Colin P. McCabe | | | Fix test-patch to work with the git repo | Blocker | scripts | Karthik Kambatla | Karthik Kambatla | | | Fix create-release script to include docs and necessary txt files | Blocker | scripts | Karthik Kambatla | Karthik Kambatla | | | Rat check should exclude \\/build/\\ | Blocker | . | Karthik Kambatla | Karthik Kambatla |
Project: SPIFFE (Provisioning / Key Management)
File: ELECTION_README_TEMPLATE.md

This subdirectory captures the nominees and results of the YYYY [H1,H2] SSC election. The timeline for this election is as follows: MONTH DAY, YEAR: Nominations open MONTH DAY, YEAR: Nominations close MONTH DAY, YEAR: Polls open MONTH DAY, YEAR: Polls close MONTH DAY, YEAR: Results announced For more information on how to participate, please see the relevant GitHub . To be announced. To be announced.
Project: KICS (Provisioning / Security & Compliance)
File: cb2f612b-ed42-4ff5-9fb9-255c73d39a18.md

title: Serverless Function Without Dead Letter Queue hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: cb2f612b-ed42-4ff5-9fb9-255c73d39a18 Query name: Serverless Function Without Dead Letter Queue Platform: CloudFormation Severity: <span style="color:#edd57e">Low</span> Category: Insecure Configurations URL: AWS Serverless Function should be configured for a Dead Letter Queue(DLQ)<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="7" AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: AWS SAM template with a simple API definition Resources: Function: Type: AWS::Serverless::Function Properties: PackageType: Image ImageUri: account-id.dkr.ecr.region.amazonaws.com/ecr-repo-name:image-name ImageConfig: Command: "app.lambda_handler" EntryPoint: "entrypoint1" WorkingDirectory: "workDir" Tags: Key: Type Value: AWS Serverless Function ``` ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: AWS SAM template with a simple API definition Resources: Function1: Type: AWS::Serverless::Function Properties: PackageType: Image ImageUri: account-id.dkr.ecr.region.amazonaws.com/ecr-repo-name:image-name ImageConfig: Command: "app.lambda_handler" EntryPoint: "entrypoint1" WorkingDirectory: "workDir" Tags: Key: Type Value: AWS Serverless Function DeadLetterConfig: TargetArn: arn:aws:sqs:us-east-1:2324243535:aaa Type: SQS ```