cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: changes1_6.md

From v1.6, KICS will read .gitignore file in the root of the project to exclude from the scan the paths therein. How does this impact your scans? You will only be affected by this change in case you use KICS locally on your develop environment. Notice that if you are using KICS on top of a repository (e.g., as part of a CI/CD pipeline) those paths already do not exist, so there will be no effect for those scenarios. Youll notice an apparent loss of results: results identified in files under the .gitignore paths will no more be identified. <br/> -t or --type flag is used to instruct KICS to scan only files of specific technologies. Before v1.6, KICS with -t flag would scan the project and, in case there are no files of the specified technologies, it will terminate with a message No files were scanned and no other output. From v1.6, KICS will keep its behavior consistent whether -t flag is used or not. Meaning: it will always output results file, even if it is an empty results report is created due to no files being scanned, as shown in the image below. How does this impact your scans? You will only be affected by this change in case you use KICS with flag -t/--type AND there are no files of the specified type in the scanned project. If you rely on the message No files were scanned for some post-scan action, this change will also affect you, because that message disappears now. <div style="min-width:150;flex:0 0 25%;display:flex;align-items:center;justify-content:center;margin:8px"> <img alt="-t flag behavior" src="../img/1-6-t-flag.png" width="300" style="min-width:300px"> </div> <br/> From v1.6, KICS will mask/hide identified secrets out of results reports, in order to avoid exposing them to undesirable report readers. How does this impact your scans? This is not likely to impact you in any way. Notice that results of secrets and passwords will appear in a slightly different, but more secure, fashion (see below an example of an HTML report) <div style="min-width:150;flex:0 0 25%;display:flex;align-items:center;justify-content:center;margin:8px"> <img alt="Masked Secrets" src="../img/masked-secrets.png" width="450" style="min-width:450px"> </div> During KICS 1.6.x versions we intend to deprecate some of our flags and keep using their default values. They are the following: --minimal-ui --no-progress --preview-lines --no-color
Project: YugabyteDB (App Definition and Development / Database)
File: rollback.diagram.md

<svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="269" height="70" viewbox="0 0 269 70"><path class="connector" d="M0 22h15m83 0h30m106 0h20m-136 25q0 5 5 5h5m57 0h54q5 0 5-5m-131-25q5 0 5 5v33q0 5 5 5h116q5 0 5-5v-33q0-5 5-5m5 0h15"/><polygon points="0,29 5,22 0,15" style="fill:black;stroke-width:0"/><rect class="literal" x="15" y="5" width="83" height="25" rx="7"/><text class="text" x="25" y="22">ROLLBACK</text><rect class="literal" x="128" y="5" width="106" height="25" rx="7"/><text class="text" x="138" y="22">TRANSACTION</text><rect class="literal" x="128" y="35" width="57" height="25" rx="7"/><text class="text" x="138" y="52">WORK</text><polygon points="265,29 269,29 269,15 265,15" style="fill:black;stroke-width:0"/></svg>
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-farm.1.md

% podman-farm 1 podman\-farm - Farm out builds to machines running podman for different architectures podman farm subcommand Farm out builds to machines running Podman for different architectures. Manage farms by creating, updating, and removing them. Note: All farm machines must have a minimum podman version of v4.9.0. Podman manages the farms by writing and reading the `podman-connections.json` file located under `$XDGCONFIGHOME/containers` or if the env is not set it defaults to `$HOME/.config/containers`. Or the `PODMANCONNECTIONSCONF` environment variable can be set to a full file path which podman will use instead. This file is managed by the podman commands and should never be edited by users directly. To manually configure the farms use the `[farm]` section in containers.conf. If the ReadWrite column in the podman farm list output is set to true the farm is stored in the `podman-connections.json` file otherwise it is stored in containers.conf and can therefore not be edited with the podman farm remove/update commands. It can still be used with podman farm build. | Command | Man Page | Description | | -- | -| -- | | build | | Build images on farm nodes, then bundle them into a manifest list | | create | | Create a new farm | | list | | List the existing farms | | remove | | Delete one or more farms | | update | | Update an existing farm | July 2023, Originally compiled by Urvashi Mohnani (umohnani at redhat dot com)
Project: VMClarity (Provisioning / Security & Compliance)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: Copa (Provisioning / Security & Compliance)
File: troubleshooting.md

title: Troubleshooting You might want to filter/ignore some of the vulnerabilities while patching. To do so, you need to first filter those undesired vulnerabilities from your scanner output. For Trivy, vulnerabilities can be filtered by the following 2 ways: An example rego file which demonstrates how to ignore certain Vulnerability IDs or Package Names: ```bash $ cat trivy_ignore.rego package trivy import data.lib.trivy default ignore = false ignorevulnerabilityids := { "CVE-2018-14618" } ignore_pkgs := {"bash", "vim"} ignore { input.VulnerabilityID == ignorevulnerabilityids[_] } ignore { input.PkgName == ignorepkgs[] } ``` After adding the above rego file, run the image scan with the `--ignore-policy` flag followed by the file name to ignore them while scanning: ```bash trivy image --ignore-policy trivy_ignore.rego ruby:2.4.0 ``` In the above example, the vulnerability "CVE-2018-14618" and the packages "bash" & "vim" are ignored while scanning, and hence patching the image. Use a `.trivyignore` file to list all the vulnerabilities you want to ignore. Example: ```bash $ cat .trivyignore CVE-2018-14618 ``` In the above example, the vulnerability CVE-2018-14618 is ignored while scanning, and hence while patching the image. For a more detailed explanation on how to ignore certain vulnerabilities with Trivy, please refer to the official documentation .
Project: StarRocks (App Definition and Development / Database)
File: tanh.md

displayed_sidebar: "English" Computes the hyperbolic tangent of the argument. This function is supported from v3.0. ```Haskell DOUBLE tanh(DOUBLE arg) ``` `arg`: You can specify only a numeric value. This function converts the numeric value into a DOUBLE value before it computes the hyperbolic tangent of the value. Returns a value of the DOUBLE data type. If you specify a non-numeric value, this function returns `NULL`. ```Plain mysql> select tanh(-1); ++ | tanh(-1) | ++ | -0.7615941559557649 | ++ mysql> select tanh(0); ++ | tanh(0) | ++ | 0 | ++ mysql> select tanh(1); +--+ | tanh(1) | +--+ | 0.7615941559557649 | +--+ mysql> select tanh(""); +-+ | tanh('') | +-+ | NULL | +-+ ``` TANH
Project: Meshery (Provisioning / Automation & Configuration)
File: kubevault-operator.md

layout: integration title: Kubevault Operator subtitle: Collaborative and visual infrastructure as code for Kubevault Operator image: /assets/img/integrations/kubevault-operator/icons/color/kubevault-operator-color.svg permalink: extensibility/integrations/kubevault-operator docURL: https://docs.meshery.io/extensibility/integrations/kubevault-operator description: integrations-category: Security & Compliance integrations-subcategory: Uncategorized registrant: Artifact Hub components: name: vault-server colorIcon: assets/img/integrations/kubevault-operator/components/vault-server/icons/color/vault-server-color.svg whiteIcon: assets/img/integrations/kubevault-operator/components/vault-server/icons/white/vault-server-white.svg description: featureList: [ "Deploy TLS secured Vault Servers on Kubernetes using KubeVault. You can use cert-manager to manage VaultServer TLS or you can manage TLS with self-signed.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_compute_ssl_certificates.md

+++ title = "googlecomputessl_certificates resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlecomputessl_certificates" identifier = "inspec/resources/gcp/googlecomputesslcertificates.md googlecomputesslcertificates resource" parent = "inspec/resources/gcp" +++ A `googlecomputessl_certificates` is used to test a Google SslCertificate resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ```ruby describe googlecomputessl_certificates(project: 'chef-gcp-inspec') do its('names') { should include 'inspec-gcp-ssl-certificate' } its('descriptions') { should include 'A fake ssl certificate (DO NOT USE)' } its('certificates') { should include '--BEGIN CERTIFICATE-- MIICqjCCAk+gAwIBAgIJAIuJ+0352Kq4MAoGCCqGSM49BAMCMIGwMQswCQYDVQQG EwJVUzETMBEGA1UECAwKV2FzaGluZ3RvbjERMA8GA1UEBwwIS2lya2xhbmQxFTAT BgNVBAoMDEdvb2dsZSwgSW5jLjEeMBwGA1UECwwVR29vZ2xlIENsb3VkIFBsYXRm b3JtMR8wHQYDVQQDDBZ3d3cubXktc2VjdXJlLXNpdGUuY29tMSEwHwYJKoZIhvcN AQkBFhJuZWxzb25hQGdvb2dsZS5jb20wHhcNMTcwNjI4MDQ1NjI2WhcNMjcwNjI2 MDQ1NjI2WjCBsDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCldhc2hpbmd0b24xETAP BgNVBAcMCEtpcmtsYW5kMRUwEwYDVQQKDAxHb29nbGUsIEluYy4xHjAcBgNVBAsM FUdvb2dsZSBDbG91ZCBQbGF0Zm9ybTEfMB0GA1UEAwwWd3d3Lm15LXNlY3VyZS1z aXRlLmNvbTEhMB8GCSqGSIb3DQEJARYSbmVsc29uYUBnb29nbGUuY29tMFkwEwYH KoZIzj0CAQYIKoZIzj0DAQcDQgAEHGzpcRJ4XzfBJCCPMQeXQpTXwlblimODQCuQ 4mzkzTv0dXyB750fOGN02HtkpBOZzzvUARTR10JQoSe2/5PIwaNQME4wHQYDVR0O BBYEFKIQC3A2SDpxcdfn0YLKineDNq/BMB8GA1UdIwQYMBaAFKIQC3A2SDpxcdfn 0YLKineDNq/BMAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwIDSQAwRgIhALs4vy+O M3jcqgA4fSW/oKw6UJxp+M6a+nGMX+UJR3YgAiEAvvl39QRVAiv84hdoCuyON0lJ zqGNhIPGq2ULqXKK8BY= --END CERTIFICATE-- ' } end ``` Properties that can be accessed from the `googlecomputessl_certificates` resource: See the resource for more information. `certificates` : an array of `googlecomputessl_certificate` certificate `creation_timestamps` : an array of `googlecomputesslcertificate` creationtimestamp `descriptions` : an array of `googlecomputessl_certificate` description `ids` : an array of `googlecomputessl_certificate` id `names` : an array of `googlecomputessl_certificate` name `private_keys` : an array of `googlecomputesslcertificate` privatekey This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method. Ensure the is enabled for the current project.
Project: EDB (App Definition and Development / Database)
File: applications.md

Applications are supposed to work with the services created by CloudNativePG in the same Kubernetes cluster: `[cluster name]-rw` `[cluster name]-ro` `[cluster name]-r` Those services are entirely managed by the Kubernetes cluster and implement a form of Virtual IP as described in the . !!! Hint It is highly recommended using those services in your applications, and avoiding connecting directly to a specific PostgreSQL instance, as the latter can change during the cluster lifetime. You can use these services in your applications through: DNS resolution environment variables For the credentials to connect to PostgreSQL, you can use the secrets generated by the operator. !!! Seealso "Connection Pooling" Please refer to the for information about how to take advantage of PgBouncer as a connection pooler, and create an access layer between your applications and the PostgreSQL clusters. You can use the Kubernetes DNS service to point to a given server. The Kubernetes DNS service is required by the operator. You can do that by using the name of the service if the application is deployed in the same namespace as the PostgreSQL cluster. In case the PostgreSQL cluster resides in a different namespace, you can use the full qualifier: `service-name.namespace-name`. DNS is the preferred and recommended discovery method. If you deploy your application in the same namespace that contains the PostgreSQL cluster, you can also use environment variables to connect to the database. For example, suppose that your PostgreSQL cluster is called `pg-database`, you can use the following environment variables in your applications: `PGDATABASERSERVICEHOST`: the IP address of the service pointing to all the PostgreSQL instances for read-only workloads `PGDATABASEROSERVICEHOST`: the IP address of the service pointing to all hot-standby replicas of the cluster `PGDATABASERWSERVICEHOST`: the IP address of the service pointing to the primary instance of the cluster The PostgreSQL operator will generate up to two `basic-auth` type secrets for every PostgreSQL cluster it deploys: `[cluster name]-app` (unless you have provided an existing secret through `.spec.bootstrap.initdb.secret.name`) `[cluster name]-superuser` (if `.spec.enableSuperuserAccess` is set to `true` and you have not specified a different secret using `.spec.superuserSecret`) Each secret contain the following: username password hostname to the RW service port number database name a working The `-app` credentials are the ones that should be used by applications connecting to the PostgreSQL cluster, and correspond to the user owning the database. The `-superuser` ones are supposed to be used only for administrative purposes, and correspond to the `postgres` user. Since version 1.21, superuser access over the network is disabled by default.
Project: KICS (Provisioning / Security & Compliance)
File: 20dcd953-a8b8-4892-9026-9afa6d05a525.md

title: Stackdriver Monitoring Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 20dcd953-a8b8-4892-9026-9afa6d05a525 Query name: Stackdriver Monitoring Disabled Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: Kubernetes Engine Clusters must have Stackdriver Monitoring enabled, which means the attribute 'monitoring_service' must be defined and different than 'none'<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="32 3" name: create a cluster1 google.cloud.gcpcontainercluster: name: my-cluster1 initialnodecount: 2 master_auth: username: cluster_admin password: my-secret-password node_config: machine_type: n1-standard-4 disksizegb: 500 location: us-central1-a project: test_project auth_kind: serviceaccount serviceaccountfile: "/tmp/auth.pem" state: present name: create a cluster2 google.cloud.gcpcontainercluster: name: my-cluster2 initialnodecount: 2 master_auth: username: cluster_admin password: my-secret-password node_config: machine_type: n1-standard-4 disksizegb: 500 location: us-central1-a project: test_project auth_kind: serviceaccount serviceaccountfile: "/tmp/auth.pem" state: present monitoring_service: none ``` ```yaml title="Negative test num. 1 - yaml file" name: create a cluster google.cloud.gcpcontainercluster: name: my-cluster initialnodecount: 2 master_auth: username: cluster_admin password: my-secret-password node_config: machine_type: n1-standard-4 disksizegb: 500 location: us-central1-a project: test_project auth_kind: serviceaccount serviceaccountfile: /tmp/auth.pem state: present monitoring_service: monitoring.googleapis.com ```
Project: Copa (Provisioning / Security & Compliance)
File: SUPPORT.md

This project uses GitHub Issues to track bugs and suggestions. Please [search the existing issues](https://github.com/project-copacetic/copacetic/issues) before filing new issues to avoid duplicates. For new issues, using the appropriate template. For help and questions about using this project, please file a new issue using the Question issue template. The project maintainers will respond to the best of their abilities. Support for Project Copacetic is limited to the resources listed above and is [not covered by the Microsoft Azure support policy](https://support.microsoft.com/en-us/help/2941892/support-for-linux-and-open-source-technology-in-azure).
Project: YugabyteDB (App Definition and Development / Database)
File: yba_provider_azure_delete.md

Delete an Azure YugabyteDB Anywhere provider Delete an Azure provider in YugabyteDB Anywhere ``` yba provider azure delete [flags] ``` ``` -f, --force [Optional] Bypass the prompt for non-interactive usage. -h, --help help for delete ``` ``` -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 provider for the action. 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 provider
Project: YDB (App Definition and Development / Database)
File: workload-click-bench.md

The load is based on data and queries from the repository, and the queries and table layout are adapted to {{ ydb-short-name }}. The benchmark generates typical workload in the following areas: clickstream and traffic analysis, web analytics, machine-generated data, structured logs, and event data. It covers typical queries in analytics and real-time dashboards. The dataset for this benchmark was obtained from an actual traffic recording of one of the world's largest web analytics platforms. It has been anonymized while keeping all the essential data distributions. The query set was improvised to reflect realistic workloads, while the queries are not directly from production. Before running the benchmark, create a table: ```bash {{ ydb-cli }} workload clickbench init ``` See the description of the command to init the data load: ```bash {{ ydb-cli }} workload clickbench init --help ``` | Parameter name | Parameter description | | | `--table <value>` | The table name. The default value is `clickbench/hits`. | | `--store <value>` | Type of table storage. Acceptable values: `row`, `column`. Default value: `row`. | Upload data to the table. To do this, download and unzip the data archive, then upload the data to the table: ```bash wget https://datasets.clickhouse.com/hits_compatible/hits.csv.gz unzip hits.csv.gz {{ ydb-cli }} import file csv --path clickbench/hits --input-file hits.csv ``` Run the load: ```bash {{ ydb-cli }} workload clickbench run ``` During this test, workload statistics for each query are displayed on the screen. See the description of the command to run the data load: ```bash {{ ydb-cli }} workload clickbench run --help ``` | Parameter name | Parameter description | | | `--output <value>` | The name of the file in which the query execution results will be saved. The default value is `results.out`. | | `--iterations <value>` | The number of executions of each load generating query. The default value is `1`. | | `--json` | The name of the file in which the query execution statistics will be saved in `json` format. By default, the file is not saved. | | `--ministat` | The name of the file in which the query execution statistics will be saved in `ministat` format. By default, the file is not saved. | | `--query-settings` | Query execution settings. By default, not specified. | | `--ext-queries-file` | The name of the file in which external queries to run the load can be specified. By default, the file is not required. | | `--ext-query` | A row with external queries to run the load. There is no default value. | | `--table` | The table name. The default value is `clickbench/hits`. | | `--include` | The numbers or number sections of the queries to be executed as part of the load. By default, all queries are executed. Separated by commas, for example, `1,2,4-6`. | | `--exclude` | The numbers or number sections of the queries to be excluded as part of the load. By default, all queries are executed. Separated by commas, for example, `1,2,4-6`. |