cwielenb/CNCF-Dataset huggingface dataset:
Project: Kapitan (Provisioning / Automation & Configuration)
File: 2024-02-12.md

author: Luis Buriola authorghuser: gburiola read_time: 2m date: 2024-02-12 The Kapicorp team is happy to to announce a new release of Kapitan. This release contains loads of improvements for the past 8 months, the majority of which have been contributions from our community! Head over our on GitHub for a full list of features and contributors. Please help us by visiting our page.
Project: KICS (Provisioning / Security & Compliance)
File: 1ec253ab-c220-4d63-b2de-5b40e0af9293.md

title: S3 Bucket Without Restriction Of Public Bucket hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 1ec253ab-c220-4d63-b2de-5b40e0af9293 Query name: S3 Bucket Without Restriction Of Public Bucket Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: S3 bucket without restriction of public bucket<br> ```tf title="Positive test num. 1 - tf file" hl_lines="11 14" resource "awss3bucket" "positive1" { bucket = "example" } // comment resource "awss3bucketpublicaccess_block" "positive2" { bucket = awss3bucket.example.id blockpublicacls = true blockpublicpolicy = true restrictpublicbuckets = false } resource "awss3bucketpublicaccess_block" "positive3" { bucket = awss3bucket.example.id blockpublicacls = true blockpublicpolicy = true } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="8" module "s3_bucket" { source = "terraform-aws-modules/s3-bucket/aws" version = "3.7.0" bucket = "my-s3-bucket" acl = "private" restrictpublicbuckets = false versioning = { enabled = true } policy = <<POLICY { "Version": "2012-10-17", "Id": "MYBUCKETPOLICY", "Statement": [ { "Sid": "IPAllow", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::mytftest_bucket/*", "Condition": { "IpAddress": {"aws:SourceIp": "8.8.8.8/32"} } } ] } POLICY } ``` ```tf title="Positive test num. 3 - tf file" hl_lines="1" module "s3_bucket" { source = "terraform-aws-modules/s3-bucket/aws" version = "3.7.0" bucket = "my-s3-bucket" acl = "private" versioning = { enabled = true } policy = <<POLICY { "Version": "2012-10-17", "Id": "MYBUCKETPOLICY", "Statement": [ { "Sid": "IPAllow", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::mytftest_bucket/*", "Condition": { "IpAddress": {"aws:SourceIp": "8.8.8.8/32"} } } ] } POLICY } ``` ```tf title="Negative test num. 1 - tf file" resource "awss3bucket" "negative1" { bucket = "example" } resource "awss3bucketpublicaccess_block" "negative2" { bucket = awss3bucket.example.id blockpublicacls = true blockpublicpolicy = true restrictpublicbuckets = true } ``` ```tf title="Negative test num. 2 - tf file" module "s3_bucket" { source = "terraform-aws-modules/s3-bucket/aws" version = "3.7.0" bucket = "my-s3-bucket" acl = "private" restrictpublicbuckets = true versioning = { enabled = true } policy = <<POLICY { "Version": "2012-10-17", "Id": "MYBUCKETPOLICY", "Statement": [ { "Sid": "IPAllow", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::mytftest_bucket/*", "Condition": { "IpAddress": {"aws:SourceIp": "8.8.8.8/32"} } } ] } POLICY } ```
Project: KICS (Provisioning / Security & Compliance)
File: 0ed012a4-9199-43d2-b9e4-9bd049a48aa4.md

title: IAM Database Auth Not Enabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 0ed012a4-9199-43d2-b9e4-9bd049a48aa4 Query name: IAM Database Auth Not Enabled Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Encryption URL: IAM Database Auth Enabled should be configured to true when using compatible engine and version<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="9 22" name: create minimal aurora instance in default VPC and default subnet group community.aws.rds_instance: engine: mysql dbinstanceidentifier: ansible-test-aurora-db-instance instance_type: db.t2.small password: "{{ password }}" username: "{{ username }}" cluster_id: ansible-test-cluster enableiamdatabase_authentication: "No" name: Create a DB instance using the default AWS KMS encryption key community.aws.rds_instance: id: test-encrypted-db state: present engine: mariadb storage_encrypted: True dbinstanceclass: db.t2.medium username: "{{ username }}" password: "{{ password }}" allocatedstorage: "{{ allocatedstorage }}" enableiamdatabase_authentication: false ``` ```yaml title="Negative test num. 1 - yaml file" name: create minimal aurora instance in default VPC and default subnet group community.aws.rds_instance: engine: aurora dbinstanceidentifier: ansible-test-aurora-db-instance instance_type: db.t2.small password: '{{ password }}' username: '{{ username }}' cluster_id: ansible-test-cluster enableiamdatabase_authentication: true name: Create a DB instance using the default AWS KMS encryption key community.aws.rds_instance: id: test-encrypted-db state: present engine: mariadb storage_encrypted: true dbinstanceclass: db.t2.medium username: '{{ username }}' password: '{{ password }}' allocatedstorage: '{{ allocatedstorage }}' enableiamdatabase_authentication: true name: remove the DB instance without a final snapshot community.aws.rds_instance: id: '{{ instance_id }}' state: absent skipfinalsnapshot: true enableiamdatabase_authentication: true name: remove the DB instance with a final snapshot community.aws.rds_instance: id: '{{ instance_id }}' state: absent finalsnapshotidentifier: '{{ snapshot_id }}' enableiamdatabase_authentication: true name: create minimal aurora instance in default VPC and default subnet group community.aws.rds_instance: engine: aurora dbinstanceidentifier: ansible-test-aurora-db-instance instance_type: db.t2.small password: "{{ password }}" username: "{{ username }}" cluster_id: ansible-test-cluster enableiamdatabase_authentication: "No" name: create minimal aurora instance in default VPC and default subnet group community.aws.rds_instance: engine: mariadb engine_version: 10.2.43 dbinstanceidentifier: ansible-test-aurora-db-instance instance_type: db.t2.small password: "{{ password }}" username: "{{ username }}" cluster_id: ansible-test-cluster ```
Project: SlimToolkit (Provisioning / Security & Compliance)
File: ROADMAP.md

This is a high level roadmap that identies the current areas of focus. Note that it's not a detailed list of every possible enhancement. Community Collaborate with other CNCF projects to achieve mutually benefitial outcomes Talks, outreach, community training Engage with the community to increase project contributions Documentation Improve system design documentations to make it easier for new contributors to contribute to the project User docs (v1) Non-docker runtime support Direct ContainerD support Finch integration Podman support Kubernetes support vNext Container debugging Ephemeral container based debugging for Kubernetes Build/Optimize engine Error and logging enhancements to improve debuggability Improved build flag documentation with examples Improved CI/build tool integration documentation (including Github Actions) Integrations Consign integrations for `xray` (reporting) and `build` (signing) Plugins Plugin subsystem design Sample plugins Container image build plugin for BuildKit System sensor System sensor subsystem design External sensor integrations for Tetragon, Falco and Tracee as plugins Installers for all major platforms/package managers and publishing the packages to the official package manager distribution repos Homebrew (official tap), Mac Ports Apt Yum/Dnf/Rpm Apk Aur Nix Example More build/optimize/minify examples Documenting examples including the configs used to produce the minified images
Project: Beam (App Definition and Development / Streaming & Messaging)
File: go-2.40.md

title: "Big Improvements in Beam Go's 2.40 Release" date: 2022-07-06 00:00:01 -0800 categories: blog go authors: damccorm <!-- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> The 2.40 release is one of Beam Go's biggest yet, and we wanted to highlight some of the biggest changes coming with this important release! 2.40 marks the release of one of our most anticipated feature sets yet: native streaming Go pipelines. This includes adding support for: (added in 2.39) With all of these features, it is now possible to write your own streaming pipeline source DoFns in Go without relying on cross-language transforms from Java or Python. We encourage you to try out all of these new features in your streaming pipelines! The has additional information on getting started with native Go streaming DoFns. The release of in Go 1.18 unlocked significant performance improvements for Beam Go. With generics, we were able to add simple registration functions that can massively reduce your pipeline's runtime and resource consumption. For example, registering the ParDo's in our load tests which are designed to simulate a basic pipeline reduced execution time from around 25 minutes to around 7 minutes on average an over 70% reduction! <img class="center-block" src="/images/blog/go-registration.png" alt="Beam Registration Load Tests ParDo Improvements"> To get started with registering your own DoFns and unlocking these performance gains, check out the . Moving forward, we remain focused on improving the streaming experience and leveraging generics to improve the SDK. Specific improvements we are considering include adding support, introducing a Go expansion service so that Go DoFns can be used in other languages, and wrapping more Java and Python IOs so that they can be easily used in Go. As always, please let us know what changes you would like to see by , , or starting a !
Project: KICS (Provisioning / Security & Compliance)
File: e7e961ac-d17e-4413-84bc-8a1fbe242944.md

title: Cloud Storage Bucket Versioning Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: e7e961ac-d17e-4413-84bc-8a1fbe242944 Query name: Cloud Storage Bucket Versioning Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: Cloud Storage Bucket should have versioning enabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="10 6" resource "googlestoragebucket" "positive1" { name = "foo" location = "EU" versioning = { enabled = false } } resource "googlestoragebucket" "positive2" { name = "foo" location = "EU" } ``` ```tf title="Negative test num. 1 - tf file" resource "googlestoragebucket" "negative1" { name = "foo" location = "EU" versioning = { enabled = true } } ```
Project: Harbor (Provisioning / Container Registry)
File: 9-12-LDAP-user-push-unsigned-images.md

Test 9-12 User push unsigned images(LDAP mode) ======= To verify UI will difference unsigned images from signed. User guide This test requires that a Harbor instance is running and available. Harbor is set to authenticate against a LDAP or AD server. A Linux host with Docker CLI(Docker client)installed. A non-admin user that has at least a project as project admin. Same as Test 9-02 except that users are from LDAP/AD. Same as Test 9-02. None
Project: Cassandra (App Definition and Development / Database)
File: pull_request_template.md

Thanks for sending a pull request! Here are some tips if you're new here: Ensure you have added or run the for your PR. Be sure to keep the PR description updated to reflect all changes. Write your PR title to summarize what this PR proposes. If possible, provide a concise example to reproduce the issue for a faster review. Read our If you're making a documentation change, see our Commit messages should follow the following format: ``` <One sentence description, usually Jira title or CHANGES.txt summary> <Optional lengthier description (context on patch)> patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-##### Co-authored-by: Name1 <email1> Co-authored-by: Name2 <email2> ``` The
Project: KICS (Provisioning / Security & Compliance)
File: 3d24b204-b73d-42cb-b0bf-1a5438c5f71e.md

title: Secure Port Set To Zero hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 3d24b204-b73d-42cb-b0bf-1a5438c5f71e Query name: Secure Port Set To Zero Platform: Kubernetes Severity: <span style="color:#bb2124">High</span> Category: Networking and Firewall URL: When using kube-apiserver command, the --secure-port flag should not be 0<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: ["--secure-port=0"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: [] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver","--secure-port=6443"] args: [] restartPolicy: OnFailure ```
Project: KubeEdge (Provisioning / Automation & Configuration)
File: TESTS.md

`go test` is used for testing. A running PostgreSQL server is required, with the ability to log in. The database to connect to test with is "pqgotest," on "localhost" but these can be overridden using [environment variables](https://www.postgresql.org/docs/9.3/static/libpq-envars.html). Example: PGHOST=/run/postgresql go test A benchmark suite can be run as part of the tests: go test -bench . Run a postgres container: ``` docker run --expose 5432:5432 postgres ``` Run tests: ``` PGHOST=localhost PGPORT=5432 PGUSER=postgres PGSSLMODE=disable PGDATABASE=postgres go test ```
Project: ClickHouse (App Definition and Development / Database)
File: v23.1.2.9-stable.md

sidebar_position: 1 sidebar_label: 2023 Backported in : Fixed performance of short `SELECT` queries that read from tables with large number of`Array`/`Map`/`Nested` columns. (). Backported in : Fix wiping sensitive info in logs. (). Backported in : Fix key description when encountering duplicate primary keys. This can happen in projections. See for details. (). Trim refs/tags/ from GITHUB_TAG in release workflow ().
Project: YDB (App Definition and Development / Database)
File: case.md

Conditional expressions and branching. It's similar to `if`, `switch` and ternary operators in the imperative programming languages. If the result of the `WHEN` expression is `true`, the value of the `CASE` expression becomes the result following the condition, and the rest of the `CASE` expression isn't calculated. If the condition is not met, all the `WHEN` clauses that follow are checked. If none of the `WHEN` clauses are met, the `CASE` value is assigned the result from the `ELSE` clause. The `ELSE` branch is mandatory in the `CASE` expression. Expressions in `WHEN` are checked sequentially, from top to bottom. Since its syntax is quite sophisticated, it's often more convenient to use the built-in function . Examples ```yql SELECT CASE WHEN value > 0 THEN "positive" ELSE "negative" END FROM my_table; ``` ```yql SELECT CASE value WHEN 0 THEN "zero" WHEN 1 THEN "one" ELSE "not zero or one" END FROM my_table; ```
Project: KICS (Provisioning / Security & Compliance)
File: 815021c8-a50c-46d9-b192-24f71072c400.md

title: Paths Object is Empty (v3) hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 815021c8-a50c-46d9-b192-24f71072c400 Query name: Paths Object is Empty (v3) Platform: OpenAPI Severity: <span style="color:#5bc0de">Info</span> Category: Structure and Semantics URL: Paths object may be empty due to ACL constraints, meaning they are not exposed<br> ```json title="Positive test num. 1 - json file" hl_lines="7" { "openapi": "3.0.0", "info": { "title": "Simple API overview", "version": "1.0.0" }, "paths": {} } ``` ```json title="Positive test num. 2 - json file" hl_lines="7" { "swagger": "2.0", "info": { "title": "Simple API overview", "version": "1.0.0" }, "paths": {} } ``` ```yaml title="Positive test num. 3 - yaml file" hl_lines="5" openapi: 3.0.0 info: title: Simple API overview version: 1.0.0 paths: {} ``` <details><summary>Positive test num. 4 - yaml file</summary> ```yaml hl_lines="5" swagger: "2.0" info: title: Simple API overview version: 1.0.0 paths: {} ``` </details> ```json title="Negative test num. 1 - json file" { "openapi": "3.0.0", "info": { "title": "Simple API overview", "version": "1.0.0" }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "description": "200 response", "content": { "application/json": { "examples": { "foo": { "value": { "versions": [ { "status": "CURRENT", "updated": "2011-01-21T11:33:21Z", "id": "v2.0", "links": [ { "href": "http://127.0.0.1:8774/v2/", "rel": "self" } ] } ] } } } } } } } } } } } ``` ```json title="Negative test num. 2 - json file" { "swagger": "2.0", "info": { "title": "Simple API overview", "version": "1.0.0" }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "description": "200 response" } } } } } } ``` ```yaml title="Negative test num. 3 - yaml file" openapi: 3.0.0 info: title: Simple API version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: '200': description: 200 response content: application/json: examples: foo: value: versions: status: CURRENT updated: '2011-01-21T11:33:21Z' id: v2.0 links: href: http://127.0.0.1:8774/v2/ rel: self ``` <details><summary>Negative test num. 4 - yaml file</summary> ```yaml swagger: "2.0" info: title: Simple API overview version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": description: 200 response ``` </details>
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-system-df.1.md

% podman-system-df 1 podman\-system\-df - Show podman disk usage podman system df [options] Show podman disk usage Pretty-print images using a Go template or JSON. This flag is not allowed in combination with --verbose Valid placeholders for the Go template are listed below: | Placeholder | Description | | - | | | .Active | Indicates whether volume is in use | | .RawReclaimable | Raw reclaimable size of each Type | | .RawSize | Raw size of each type | | .Reclaimable | Reclaimable size or each type (human-readable) | | .Size | Size of each type (human-readable) | | .Total | Total items for each type | | .Type | Type of data | Show detailed information on space usage Show disk usage: ``` $ podman system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 6 2 281MB 168MB (59%) Containers 3 1 0B 0B (0%) Local Volumes 1 1 22B 0B (0%) ``` Show disk usage in verbose mode: ``` $ podman system df -v Images space usage: REPOSITORY TAG IMAGE ID CREATED SIZE SHARED SIZE UNIQUE SIZE CONTAINERS docker.io/library/alpine latest 5cb3aa00f899 2 weeks ago 5.79MB 0B 5.79MB 5 Containers space usage: CONTAINER ID IMAGE COMMAND LOCAL VOLUMES SIZE CREATED STATUS NAMES 073f7e62812d 5cb3 sleep 100 1 0B 20 hours ago exited zen_joliot 3f19f5bba242 5cb3 sleep 100 0 5.52kB 22 hours ago exited pedantic_archimedes 8cd89bf645cc 5cb3 ls foodir 0 58B 21 hours ago configured agitated_hamilton a1d948a4b61d 5cb3 ls foodir 0 12B 21 hours ago exited laughing_wing eafe3e3c5bb3 5cb3 sleep 10000 0 72B 21 hours ago exited priceless_liskov Local Volumes space usage: VOLUME NAME LINKS SIZE data 1 0B $ podman system df --format "{{.Type}}\t{{.Total}}" Images 1 Containers 5 Local Volumes 1 ``` , March 2019, Originally compiled by Qi Wang (qiwan at redhat dot com)
Project: Redpanda (App Definition and Development / Streaming & Messaging)
File: 01_bug_report.md

name: Bug report about: Something is not working labels: "kind/bug" Redpanda version: (use `rpk version`): <!-- Please also give versions of other components: Operating System (e.g. from `/etc/os-release`): Any Kafka client libraries in use (e.g. rdkafka, franz-go) Docker (use `docker info`): Kubernetes (use `kubectl version`): Include link to test results for automated test failures --> <!-- Describe the unexpected behavior --> <!-- Describe what you wanted to happen. --> Please attach any relevant logs, backtraces, or metric charts.
Project: ArangoDB (App Definition and Development / Database)
File: advantages.md

+++ title = "The main advantages" weight = 5 +++ The main advantages of choosing `<boost/outcome/experimental>` over default Outcome: Codegen is tighter and less verbose[^1], sometimes remarkably so. Build time impact is markedly lower, barely above the inclusion of naked `<basic_result.hpp>`, as the STL allocator machinery and `std::string` et al is not dragged into inclusion by including `<system_error>`. Note that `<boost/outcome/experimental/status_outcome.hpp>` bring in `<exception>`, however `<boost/outcome/experimental/status_result.hpp>` brings in no extra system headers. More discipline is imposed on your use of Outcome, leading to less ambiguous code which is easier to optimise by the compiler, lower cost to maintain, and lower cognitive load to audit code based on experimental Outcome for correctness. Code written to `<boost/outcome/experimental>` can be fairly easily dual targeted, with just a few switching type aliases, to default Outcome. This author has several Outcome-based libraries with identical source code which can target either configuration of Outcome. The experimental Outcome build regularly beats the default Outcome build in benchmarks by 2-3%, and the dual target source code, being written to tighter discipline, is faster and more deterministic in the default target than it was before the (non-trivial) port to `<boost/outcome/experimental>`. If you are building a codebase on top of Outcome expecting long term maintenance, the author's personal recommendation is that you design, write, test and optimise it for `<boost/outcome/experimental>`. What you ship to your customers ought to be targeted at default Outcome however, so employ type aliases and macros as appropriate to switch the build configuration for production releases. This is what the Outcome author does himself, to date with great success, despite the fundamental architectural differences between `<system_error>` and proposed `<system_error2>`.