cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: 0b76d993-ee52-43e0-8b39-3787d2ddabf1.md

title: Global Responses Definition Not Being Used hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 0b76d993-ee52-43e0-8b39-3787d2ddabf1 Query name: Global Responses Definition Not Being Used Platform: OpenAPI Severity: <span style="color:#5bc0de">Info</span> Category: Best Practices URL: All global responses definitions should be in use<br> ```json title="Positive test num. 1 - json file" hl_lines="41 38" { "swagger": "2.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "$ref": "#/responses/Success" } }, "parameters": [ { "name": "limit2", "in": "body", "description": "max records to return", "required": true, "schema": { "type": "string" }, "desc": { "type": "string" } } ] } } }, "responses": { "Success": { "description": "200 response" }, "IllegalInput": { "description": "Illegal input for operation." }, "GeneralError": { "description": "General Error" } } } ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="25 27" swagger: "2.0" info: title: Simple API Overview version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": $ref: "#/responses/Success" parameters: name: limit2 in: body description: max records to return required: true schema: type: string desc: type: string responses: Success: description: "200 response" IllegalInput: description: Illegal input for operation. GeneralError: description: General Error ``` ```json title="Negative test num. 1 - json file" { "swagger": "2.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "$ref": "#/responses/Success" } }, "parameters": [ { "name": "limit2", "in": "body", "description": "max records to return", "required": true, "schema": { "type": "string" }, "desc": { "type": "string" } } ] } } }, "responses": { "Success": { "description": "200 response" } } } ``` ```yaml title="Negative test num. 2 - yaml file" swagger: "2.0" info: title: Simple API Overview version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": $ref: "#/responses/Success" parameters: name: limit2 in: body description: max records to return required: true schema: type: string desc: type: string responses: Success: description: "200 response" ```
Project: KICS (Provisioning / Security & Compliance)
File: 8d22ae91-6ac1-459f-95be-d37bd373f244.md

title: Insecure Relative Path Resolution hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 8d22ae91-6ac1-459f-95be-d37bd373f244 Query name: Insecure Relative Path Resolution Platform: Ansible Severity: <span style="color:#edd57e">Low</span> Category: Best Practices URL: Using relative paths can lead to unexpected behavior as the path is resolved relative to the current working directory, which can change.<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="12 7" name: Positive Example hosts: localhost tasks: name: One ansible.builtin.template: src: ../templates/foo.j2 dest: /etc/file.conf mode: "0644" name: Two ansible.builtin.copy: src: ../files/foo.conf dest: /etc/foo.conf mode: "0644" ``` ```yaml title="Negative test num. 1 - yaml file" name: Negative Example hosts: localhost tasks: name: One ansible.builtin.copy: content: dest: /etc/mine.conf mode: "0644" name: Two ansible.builtin.copy: src: /home/example/files/foo.conf dest: /etc/foo.conf mode: "0644" name: Negative Example 2 hosts: localhost tasks: name: One ansible.builtin.template: src: ../example/foo.j2 dest: /etc/file.conf mode: "0644" name: Two ansible.builtin.copy: src: ../example/foo.conf dest: /etc/foo.conf mode: "0644" name: Three win_template: src: ../example/foo2.j2 dest: /etc/file.conf mode: "0644" ```
Project: KUDO (App Definition and Development / Application Definition & Image Build)
File: 0002-dynamic-instances.md

kep-number: 2 title: Dynamic Instances authors: "@gerred" owners: "@gerred" editor: TBD creation-date: 2019-02-14 last-updated: 2019-05-10 status: implementable - - - - This KEP aims to make the end user experience for operators more specific to the business domain they represent. By implementing dynamic instances, operators will be able to represent their components in a declarative way, specific to their operator. Additionally, it enables operator developers to provide day 2 operations tasks as CRDs, complete with their own plans and tasks. Currently, the interface for using operators in KUDO is generic. Users create an `Instance` CRD with specs. Operator developers and users expect to be able to use contextual business objects for their operators instead of generic objects. This enables a more focused experience for users of KEP. The goal of this KEP is to improve the end user UX through dynamic instances. Other than the ability to specfiy CRDs, and adjusting existing operator development instances to accomodate this change, it is not the goal of this KEP to change the operator development UX. Create a mechanism for operator developers to specify an instance CRD Enable management for custom resources based on dynamic instances. Deploying an operator specific custom resource should deploy a plan as `Instance` was able to before. Change the operator developer UX for templates, parameters, tasks, and plans. Currently, there are issues with CRD storage in Kubernetes that lead to watches not cancelling when a CRD is uninstalled. The related fix for this in Kubernetes will be part of https://github.com/kubernetes/kubernetes/issues/68508. Implementing this KEP will be divided into 5 steps, based on the state of and https://github.com/kubernetes/kubernetes/issues/68508: Continue using Instance CRD Change the Instance CRD to a struct that does not change when migrating between Instance and CRD. This struct would be similar to: ```go type Instance struct{ metadata metav1.ObjectMeta apiVersion string spec struct{ operator *string Version string Arguments map[string]string } } ``` Add a package for the CLI to use that abstracts the details of generating out the CRD on install. The CLI will use this package. After the Kubernetes changes land: Write an Instance to Dynamic Instance migrator. This will statically convert Instance templates to their corresponding Dynamic Instance CRD for use by operators. Add a Mutating Admission Controller that converts Instance CRDs to their corresponding Dynamic Instance. This enables GitOps users to continue operating as they do today without breaking their pipelines. The primary risk of this is that a fix for graceful deletion of CRDs never lands, or takes too long to land. In that instance, we would consider building a KUDO api-server as an aggregated or standalone API. `Summary`, `Motivation`, and `Goals` being merged. Add Proposal and Risks
Project: KICS (Provisioning / Security & Compliance)
File: 860ba89b-b8de-4e72-af54-d6aee4138a69.md

title: S3 Bucket Allows Public Policy hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 860ba89b-b8de-4e72-af54-d6aee4138a69 Query name: S3 Bucket Allows Public Policy Platform: CloudFormation Severity: <span style="color:#bb2124">High</span> Category: Access Control URL: S3 bucket allows public policy<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="10 19 4" Resources: Bucket11: Type: AWS::S3::Bucket Properties: Resources: Bucket12: Type: AWS::S3::Bucket Properties: PublicAccessBlockConfiguration: RestrictPublicBuckets : true Resources: Bucket13: Type: AWS::S3::Bucket Properties: PublicAccessBlockConfiguration: BlockPublicAcls: false BlockPublicPolicy : false IgnorePublicAcls : false RestrictPublicBuckets : true ``` ```json title="Positive test num. 2 - json file" hl_lines="8" { "Resources": { "Bucket1": { "Type": "AWS::S3::Bucket", "Properties": { "PublicAccessBlockConfiguration": { "BlockPublicAcls": false, "BlockPublicPolicy": false, "IgnorePublicAcls": false, "RestrictPublicBuckets": true }, "AccessControl": "Private" } } } } ``` ```yaml title="Negative test num. 1 - yaml file" Resources: Bucket1: Type: AWS::S3::Bucket Properties: PublicAccessBlockConfiguration: BlockPublicAcls : true BlockPublicPolicy : true IgnorePublicAcls : true RestrictPublicBuckets : true ``` ```json title="Negative test num. 2 - json file" { "Resources": { "Bucket1": { "Type": "AWS::S3::Bucket", "Properties": { "PublicAccessBlockConfiguration": { "BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true }, "AccessControl": "Private" } } } } ```
Project: secureCodeBox (Provisioning / Security & Compliance)
File: service-auto-discovery.md

title: "Service AutoDiscovery" sidebar_label: "Service AutoDiscovery" path: "docs/auto-discovery/service-auto-discovery" sidebar_position: 2 The Service AutoDiscovery will create a `ScheduledScan` with the given parameters (see for config options) for each Kubernetes `Service` it detects. The Service AutoDiscovery will ignore services where the underlying pods do not serve http(s). It does this by checking for open ports `80, 443, 3000, 5000, 8000, 8443, 8080`. It is also sufficient to name the ports `http` or `https` when a different port is used than the ports specified above. Services without a matching port number or name are currently ignored. By default the Service AutoDiscovery creates for each service. These scans are relatively generic and don't include any configuration regarding authentication / authorization. As the setup and configuration of the ZAP-Advanced Chart is located in each namespace it is possible to tweak the default configuration to support authenticated and more highly configured scans. For guides on how to configure ZAP Advanced refer to the . By default the Service AutoDiscovery creates ScheduledScans using the ScanType. It has to be installed in the same namespace as the containers that you wish to scan. The following steps will install zap-advanced in the `default` namespace: ```bash helm upgrade --install zap-advanced secureCodeBox/zap-advanced ``` The Service AutoDiscovery is enabled by default but can be disabled manually. ```bash helm upgrade --namespace securecodebox-system --install auto-discovery-kubernetes secureCodeBox/auto-discovery-kubernetes --set config.serviceAutoDiscovery.enabled=false ```
Project: YugabyteDB (App Definition and Development / Database)
File: yba_storage-config_s3_list.md

List S3 YugabyteDB Anywhere storage-configurations List S3 YugabyteDB Anywhere storage-configurations ``` yba storage-config s3 list [flags] ``` ``` -h, --help help for list ``` ``` -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 S3 storage configuration
Project: Apache Ignite (App Definition and Development / Database)
File: DEVNOTES.md

Building and testing Kubernetes module ========================================= The instructions provide a guidance on how to build and test Ignite Kubernetes IP finder in Kubernetes environment. To test the IP finder you have to build the whole Apache Ignite project, package the binary as a Docker image and feed the image to your kubernetes environment. Building Apache Ignite ========================= To assemble an Apache Ignite binary use instructions from DEVNOTES.txt file in the root of the repository. Note, if you alter the build instruction somehow make sure to update the files under 'config' folder if needed. Installing Docker and Minikube ============================== Install Docker and Minikube for testing purpose in your development environment. Once this is done, make sure that Minikube sees Docker images registered locally: eval $(minikube docker-env) Start Minikube: minikube start Assembling Apache Ignite Docker Image ===================================== Create a folder for all the files to be placed in the Docker image and copy the following there: Apache Ignite binary in a zip form built at the step above. Dockerfile from `ignite-kubernetes/config/Dockerfile`. Ignite configuration with enabled Kubernetes IP finder from `ignite-kubernetes/config/example-kube.xml`. The executable file that starts the Ignite node process from `ignite-kubernetes/config/run.sh` To prepare the image, navigate to the folder and execute the following command: docker build -t ignite-kube:v1 --build-arg IGNITE_VERSION=2.10.0-SNAPSHOT . Creating containerized Ignite pods and Ignite lookup service ============================================================ Create the Kuberenetes role that provides access to endpoints of pods to provide communication between Ignite nodes: kubectl apply -f {path_to}/ignite-account-role.yaml Create the Kubernetes service account to bind the role: kubectl apply -f {path_to}/ignite-service-account.yaml kubectl apply -f {path_to}/ignite-role-binding.yaml Start the Kubernetes service that is used for IP addresses lookup. Use `ignite-kubernetes/config/ignite-service.yaml`: kubectl create -f {path_to}/ignite-service.yaml Create and deploy Ignite pods using `ignite-kubernetes/config/ignite-deployment.yaml` configuration: kubectl create -f {path_to}/ignite-deployment.yaml Make sure that the pods were deployed and running properly: kubectl get pod kubectl logs {pod name} Increase or decrease number of Ignite pods checking that Kubernetes IP finder works as expected: kubectl scale --replicas=4 -f {path_to}/ignite-deployment.yaml Docker Image Redeployment ========================= If you need to redeploy the docker image after it gets updated and you prefer not to change the image version then delete a current Kubernetes Ignite deployment (don't delete the service): kubectl delete deployment ignite-cluster After that you are free to build and deploy an updated docker image using the same commands as listed above.
Project: YDB (App Definition and Development / Database)
File: RELEASING.md

See https://pillow.readthedocs.io/en/stable/releasenotes/versioning.html for information about how the version numbers line up with releases. Released quarterly on January 2nd, April 1st, July 1st and October 15th. [ ] Open a release ticket e.g. https://github.com/python-pillow/Pillow/issues/3154 [ ] Develop and prepare release in `main` branch. and to confirm passing tests in `main` branch. and jobs by manually triggering them. , update version identifier in `src/PIL/_version.py` [ ] Update `CHANGES.rst`. [ ] Run pre-release check via `make release-test` in a freshly cloned repo. [ ] Create branch and tag for release e.g.: ```bash git branch 5.2.x git tag 5.2.0 git push --tags ``` , increment and append `.dev0` to version identifier in `src/PIL/_version.py` and then: ```bash git push --all ``` Released as needed for security, installation or critical bug fixes. [ ] Make necessary changes in `main` branch. [ ] Update `CHANGES.rst`. [ ] Check out release branch e.g.: ```bash git checkout -t remotes/origin/5.2.x ``` [ ] Cherry pick individual commits from `main` branch to release branch e.g. `5.2.x`, then `git push`. and to confirm passing tests in release branch e.g. `5.2.x`. , update version identifier in `src/PIL/_version.py` [ ] Run pre-release check via `make release-test`. [ ] Create tag for release e.g.: ```bash git tag 5.2.1 git push --tags ``` [ ] Create and check source distribution: ```bash make sdist ``` and then: ```bash git push ``` Released as needed privately to individual vendors for critical security-related bug fixes. [ ] Prepare patch for all versions that will get a fix. Test against local installations. [ ] Commit against `main`, cherry pick to affected release branches. [ ] Run local test matrix on each release & Python version. [ ] Privately send to distros. [ ] Run pre-release check via `make release-test` [ ] Amend any commits with the CVE # [ ] On release date, tag and push to GitHub. ```bash git checkout 2.5.x git tag 2.5.3 git push origin --tags ``` and then: ```bash git push origin 2.5.x ``` has passed, including the "Upload release to PyPI" job. This will have been triggered by the new tag. and copy into `dist`. Check and upload them e.g.: ```bash python3 -m twine check --strict dist/* python3 -m twine upload dist/Pillow-5.2.0* ``` and e.g. https://twitter.com/PythonPillow/status/1013789184354603010 is up-to-date with the release changes [ ] Update Pillow in the Docker Images repository ```bash git clone https://github.com/python-pillow/docker-images cd docker-images ./update-pillow-tag.sh [[release tag]] ```
Project: ClickHouse (App Definition and Development / Database)
File: v21.8.6.15-lts.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Use real tmp file instead of predefined "rows_sources" for vertical merges. This avoids generating garbage directories in tmp disks. (). Backported in : Fix strange sessions expiration logic in Keeper. Probably it should help in CI: https://clickhouse-test-reports.s3.yandex.net/0/6bd9b82141c98dcd7796fd9d08326831095ba519/stresstest(debug).html#fail1. (). Backported in : To be added. Closes . (). Backported in : Fix PostgreSQL-style cast (`::` operator) with negative numbers. (). Backported in : Fix transformation of disjunctions chain to `IN` (controlled by settings `optimizeminequalitydisjunctionchainlength`) in distributed queries with settings `legacycolumnnameoftupleliteral = 0`. (). Backported in : Fix rare case when changes of `clickhouse-keeper` settings may lead to lost logs and server hung. (). Backported in : Fix lack of quotes for table names in MaterializedPostgreSQL engine. Closes . (). Backported in : Fixed possible ZooKeeper watches leak on background processing of distributed DDL queue. Closes . (). Backported in : Fix bug which can lead to error `Existing table metadata in ZooKeeper differs in sorting key expression.` after alter of `ReplicatedVersionedCollapsingMergeTree`. Fixes . (). Backported in : Fix `There is no subcolumn` error, while select from tables, which have `Nested` columns and scalar columns with dot in name and the same prefix as `Nested` (e.g. `n.id UInt32, n.arr1 Array(UInt64), n.arr2 Array(UInt64)`). (). Backported in : Add Settings.Names, Settings.Values aliases for system.processes table. (). Backported in : Fix the coredump in the creation of distributed tables, when the parameters passed in are wrong. (). Backported in : Fix benign race condition in ReplicatedMergeTreeQueue. Shouldn't be visible for user, but can lead to subtle bugs. (). Backported in : Fixed a race condition between `DROP PART` and `REPLACE/MOVE PARTITION` that might cause replicas to diverge in rare cases. (). Backported in : Fix reading of subcolumns from compact parts. (). Backported in : Fix higher-order array functions (`SIGSEGV` for `arrayCompact`/`ILLEGAL_COLUMN` for `arrayDifference`/`arrayCumSumNonNegative`) with consts. (). Add more checks for LC in native protocol. (). CHJIT custom memory manager (). Function dictGet default implementation for nulls (). Fix usage of nested columns with non-array columns with the same prefix (). Lower compiledexpressioncache_size to 128MB (). Fix some images in release PRs ().
Project: KICS (Provisioning / Security & Compliance)
File: 221015a8-aa2a-43f5-b00b-ad7d2b1d47a8.md

title: Security Definitions Using Basic Auth hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 221015a8-aa2a-43f5-b00b-ad7d2b1d47a8 Query name: Security Definitions Using Basic Auth Platform: OpenAPI Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Security Definition Object should not use basic authentication<br> ```json title="Positive test num. 1 - json file" hl_lines="25" { "swagger": "2.0", "info": { "title": "Simple API overview", "version": "1.0.0" }, "schemes": [ "https" ], "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "description": "200 response" } } } } }, "securityDefinitions": { "oAuth2AuthCodeNeg2": { "type": "basic", "description": "For more information, see https://api.my.company.com/docs/oauth" } } } ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="17" swagger: "2.0" info: title: Simple API overview version: 1.0.0 schemes: https paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": description: 200 response securityDefinitions: oAuth2AuthCodeNeg2: type: basic description: For more information, see https://api.my.company.com/docs/oauth ``` ```json title="Negative test num. 1 - json file" { "swagger": "2.0", "info": { "title": "Simple API overview", "version": "1.0.0" }, "schemes": [ "https" ], "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "description": "200 response" } } } } }, "securityDefinitions": { "oAuth2AuthCodeNeg2": { "type": "oauth2", "description": "For more information, see https://api.my.company.com/docs/oauth", "flow": "accessCode", "authorizationUrl": "https://api.my.company.com/oauth/authorize", "tokenUrl": "https://api.my.company.com/oauth/token", "scopes": { "write:api": "modify apis in your account", "read:api": "read your apis" } } } } ``` ```yaml title="Negative test num. 2 - yaml file" swagger: "2.0" info: title: Simple API overview version: 1.0.0 schemes: https paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": description: 200 response securityDefinitions: oAuth2AuthCodeNeg2: type: oauth2 description: For more information, see https://api.my.company.com/docs/oauth flow: accessCode authorizationUrl: https://api.my.company.com/oauth/authorize tokenUrl: https://api.my.company.com/oauth/token scopes: write:api: modify apis in your account read:api: read your apis ```