cwielenb/CNCF-Dataset huggingface dataset:
Project: Trivy-Operator (Provisioning / Security & Compliance)
File: RELEASING.md

Checkout your fork and make sure it's up-to-date with the `upstream` ```console $ git remote -v origin git@github.com:<your account>/trivy-operator.git (fetch) origin git@github.com:<your account>/trivy-operator.git (push) upstream git@github.com:aquasecurity/trivy-operator.git (fetch) upstream git@github.com:aquasecurity/trivy-operator.git (push) ``` ```sh git pull -r git fetch upstream git merge upstream/main git push ``` Prepare release by creating the PR with the following changes In [`deploy/helm/Chart.yaml`] Update the `version` property (if change automatically will release a new chart) Update the `appVersion` property Update the `app.kubernetes.io/version` labels in the following files: [`deploy/static/namespace.yaml`] [`deploy/helm/templates/specs/nsa-1.0.yaml`] Update static resources from Helm chart by running the mage target: ```sh mage generate:manifests ``` In [`mkdocs.yml`] Update the `extra.var.prevgittag` property Update the `extra.var.chart_version` property Review and merge the PR (make sure all tests are passing) Update your fork again ```sh git pull -r git fetch upstream git merge upstream/main git push ``` Create an annotated git tag and push it to the `upstream`. This will trigger the [`.github/workflows/release.yaml`] workflow ```sh git tag -v0.20.1 -m 'Release v0.20.1' git push upstream v0.20.1 ``` Verify that the `release` workflow has built and published the following artifacts Trivy-operator container images published to DockerHub `docker.io/aquasec/trivy-operator:0.20.1` Trivy-operator container images published to Amazon ECR Public Gallery `public.ecr.aws/aquasecurity/trivy-operator:0.20.1` Trivy-operator container images published to GitHub Container Registry `ghcr.io/aquasecurity/trivy-operator:0.20.1` Submit trivy-operator Operator to OperatorHub and ArtifactHUB by opening the PR to the <https://github.com/k8s-operatorhub/community-operators> repository.
Project: YugabyteDB (App Definition and Development / Database)
File: show_transaction.diagram.md

<svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="369" height="35" viewbox="0 0 369 35"><path class="connector" d="M0 22h15m58 0h10m106 0h10m87 0h10m58 0h15"/><polygon points="0,29 5,22 0,15" style="fill:black;stroke-width:0"/><rect class="literal" x="15" y="5" width="58" height="25" rx="7"/><text class="text" x="25" y="22">SHOW</text><rect class="literal" x="83" y="5" width="106" height="25" rx="7"/><text class="text" x="93" y="22">TRANSACTION</text><rect class="literal" x="199" y="5" width="87" height="25" rx="7"/><text class="text" x="209" y="22">ISOLATION</text><rect class="literal" x="296" y="5" width="58" height="25" rx="7"/><text class="text" x="306" y="22">LEVEL</text><polygon points="365,29 369,29 369,15 365,15" style="fill:black;stroke-width:0"/></svg>
Project: ArangoDB (App Definition and Development / Database)
File: value-or-error.md

+++ title = "valueorerror Concept" weight = 7 tags = [ "value-or-error" ] +++ Something not really mentioned until now is how Outcome interoperates with the proposed {{% api "std::expected<T, E>" %}}, whose design lands in between {{% api "unchecked<T, E = varies>" %}} and {{% api "checked<T, E = varies>" %}} (both of which are type aliases hard coding no-value policies ). Expected and Outcome are , but interoperation for code using Expected and Outcome ought to be seamless thanks to the [proposed `ValueOrError` concept framework](https://wg21.link/P0786), a subset of which Outcome implements. The {{% api "explicit basicresult(concepts::valueorerror<T, E> &&)" %}} and {{% api "explicit basicoutcome(concepts::valueorerror<T, E> &&)" %}} constructors will explicitly construct from any type matching the {{% api "concepts::valueorerror<T, E>" %}} concept, which includes `std::expected<A, B>`, if `A` is constructible to `X`, and `B` is constructible to `Y`. The `valueorerror` concept in turn is true if and only if the input type has: A `.has_value()` observer returning a `bool`. `.value()` and `.error()` observers. Outcome's machinery for implementing `concepts::valueorerror` conversion is user extensible by injection of specialisations of the {{% api "valueorerror<T, U>" %}} type into the `BOOSTOUTCOMEV2_NAMESPACE::convert` namespace. Outcome's default `convert::valueorerror<T, U>` implementation explicitly excludes Outcome `result` and `outcome` types from the default mechanism as there is a major gotcha: the `valueorerror` matched type's `.value()` is often not callable in constexpr as it can throw, which makes this conversion mechanism pretty much useless for constexpr code. Besides, `outcome` has a converting constructor overload for `result` inputs which is constexpr capable. Note that if you do enable `outcome` inputs, a `result` will match an input `outcome`, but silently dropping any exception state. This is probably undesirable. Examples of how to implement your own `convert::valueorerror<T, U>` converter is demonstrated in the worked example, next.
Project: Pulsar (App Definition and Development / Streaming & Messaging)
File: README.md

<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you 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. --> Note: This Lua script may cause a crash in the newest version of Wireshark, see . Make sure the version of Wireshark is earlier than v4.0.0. You need to put PulsarApi.proto to a separate path. Open your Wireshark. Go to Edit > Preferences > Protocols > ProtoBuf > Protobuf, and then search paths. Add the path of PulsarApi.proto. Check `Dissect Protobuf fields as Wireshark fields` box. When this box is checked, you can use `pbf.pulsar.proto` to visit fields in protobuf package. Open Wireshark. Go to About Wireshark > Folders > Personal Lua Plugins > Plugin Path. Add pulsar.lua to this path. This plugin registers a Pulsar protocol automatically in 6650. You can use this Wireshark filter string to find out Pulsar packages (ignore ping/pong): ``` tcp.port eq 6650 and pulsar and pbf.pulsar.proto.BaseCommand.type ne "ping" and pbf.pulsar.proto.BaseCommand.type ne "pong" ```
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.12.6.md

RabbitMQ `3.12.6` is a maintenance release in the `3.12.x` . Please refer to the upgrade section from the if upgrading from a version prior to 3.12.0. This release requires Erlang 25 and supports Erlang versions up to `26.1.x`. has more details on Erlang version requirements for RabbitMQ. As of 3.12.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases. Users upgrading from 3.11.x (or older releases) on Erlang 25 to 3.12.x on Erlang 26 (both RabbitMQ and Erlang are upgraded at the same time) must consult the first. Release notes can be found on GitHub at . `3.12.5` unintentionally shipped with a `seshat` version older than `0.6.1`. This can potentially result in an incompatibility with the stream subsystem. GitHub issue: Improved forward compatibility of classic queues with 3.13. GitHub issue: `seshat` was upgraded to None in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.12.6.tar.xz` instead of the source tarball produced by GitHub.
Project: Notary (Provisioning / Security & Compliance)
File: notation-cli.md

This spec contains reference information on using notation commands. Each command has a reference page along with usages. | Command | Description | | - | - | | | Sign, verify and inspect singatures associated with blobs | | | Manage certificates in trust store | | | Inspect OCI signatures | | | Manage keys used for signing | | | List signatures of a signed OCI artifact | | | Log into OCI registries | | | Log out from the logged in OCI registries | | | Manage plugins | | | Manage trust policy configuration for OCI signature verification | | | Sign OCI artifacts | | | Verify OCI artifacts | | | Print the version of notation CLI | ```text Notation - a tool to sign and verify artifacts Usage: notation [command] Available Commands: blob Sign, verify and inspect signatures associated with blobs certificate Manage certificates in trust store inspect Inspect all signatures associated with a signed OCI artifact key Manage keys used for signing list List signatures of a signed OCI artifact login Log into OCI registries logout Log out from the logged in OCI registries plugin Manage plugins policy Manage trust policy configuration for OCI signature verification sign Sign OCI artifacts verify Verify OCI artifacts version Show the notation version information Flags: -h, --help Help for notation ```
Project: ClickHouse (App Definition and Development / Database)
File: v21.3.10.1-lts.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Fixed a bug in recovery of staled `ReplicatedMergeTree` replica. Some metadata updates could be ignored by staled replica if `ALTER` query was executed during downtime of the replica. (). Backported in : Avoid possible "Cannot schedule a task" error (in case some exception had been occurred) on INSERT into Distributed. (). Backported in : Fix crash when `PREWHERE` and row policy filter are both in effect with empty result. (). Backported in : Fix `CLEAR COLUMN` does not work when it is referenced by materialized view. Close . (). Flat, Hashed dictionary include update field bytes into bytes_allocated ().
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_add.md

title: "Command - devspace add" sidebar_label: devspace add Convenience command: adds something to devspace.yaml ``` Adds config sections to devspace.yaml ``` ``` -h, --help help for add ``` ``` --config string The devspace config file to use --debug Prints the stack trace if an error occurs --disable-profile-activation If true will ignore all profile activations --inactivity-timeout int Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems (default 180) --kube-context string The kubernetes context to use -n, --namespace string The kubernetes namespace to use --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before -p, --profile strings The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified --profile-parent strings One or more profiles that should be applied before the specified profile (e.g. devspace dev --profile-parent=base1 --profile-parent=base2 --profile=my-profile) --profile-refresh If true will pull and re-download profile parent sources --restore-vars If true will restore the variables from kubernetes before loading the config --save-vars If true will save the variables to kubernetes after loading the config --silent Run in silent mode and prevents any devspace log output except panics & fatals -s, --switch-context DEPRECATED: Switches and uses the last kube context and namespace that was used to deploy the DevSpace project --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) --vars-secret string The secret to restore/save the variables from/to, if --restore-vars or --save-vars is enabled (default "devspace-vars") ```
Project: OAuth2 Proxy (Provisioning / Key Management)
File: gitea.md

id: gitea title: Gitea Create a new application: `https://< your gitea host >/user/settings/applications` Under `Redirect URI` enter the correct URL i.e. `https://<proxied host>/oauth2/callback` Note the Client ID and Client Secret. Pass the following options to the proxy: ``` --provider="github" --redirect-url="https://<proxied host>/oauth2/callback" --provider-display-name="Gitea" --client-id="< client_id as generated by Gitea >" --client-secret="< client_secret as generated by Gitea >" --login-url="https://< your gitea host >/login/oauth/authorize" --redeem-url="https://< your gitea host >/login/oauth/access_token" --validate-url="https://< your gitea host >/api/v1/user/emails" ```
Project: kube-hunter (Provisioning / Security & Compliance)
File: KHV004.md

vid: KHV004 title: Azure SPN Exposure categories: [Identity Theft] severity: medium Kubernetes has native integration with Microsoft Azure, for that a Kubernetes installation on Azure will require API access to manage the cluster's resources in Azure (for example, to create a cloud load balancer). Some installations of Kubernetes on Azure rely on a shared file on the node that contains credentials to the Azure API under `/etc/kubernetes/azure.json`. A Pod with access to this file may become a gateway for an attacker to control your Azure environment. The better solution would be to use Azure Managed Identities instead of a static SPN. However this functionality is not mature yet, and is currently available in alpha stage only for aks-engine (non-managed Kubernetes). You can update or rotate the cluster SPN credentials, in order to prevent leaked credentials to persist over time.
Project: CloudTTY (App Definition and Development / Application Definition & Image Build)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.8.21.md

RabbitMQ `3.8.21` is a maintenance release that addresses a regression introduced in `3.8.17`. All users are recommended to upgrade to this release. RabbitMQ releases are distributed via , , and . This release and . explains what package repositories and tools can be used to provision modern Erlang versions. See the for general documentation on upgrades and for release notes of other releases. If upgrading from a`3.7.x` release, see upgrade and compatibility notes first. If upgrading from a `3.6.x` or older , first upgrade to and then to this version. Any questions about this release, upgrades or RabbitMQ in general are welcome on the and . Release notes are kept under . Contributors are encouraged to update them together with their changes. This helps with release automation and more consistent release schedule. Queues that had messages with per-message TTL in them could fail to recover their indices after a restart. GitHub issues: , No dependency changes in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.8.21.tar.xz` instead of the source tarball produced by GitHub.
Project: Apache Storm (App Definition and Development / Streaming & Messaging)
File: Generic-resources.md

title: Generic Resources layout: documentation documentation: true Generic Resources allow Storm to reference arbitrary resource types. Generic Resources may be considered an extension of the resources enumerated by the , which accounts for CPU and memory. For a Storm Topology, the user can now specify the amount of generic resources a topology component (i.e. Spout or Bolt) is required to run a single instance of the component. The user can specify the resource requirement for a topology component by using the following API call. ``` public T addResource(String resourceName, Number resourceValue) ``` Parameters: resourceName The name of the generic resource resourceValue The amount of the generic resource Example of Usage: ``` SpoutDeclarer s1 = builder.setSpout("word", new TestWordSpout(), 10); s1.addResouce("gpu.count", 1.0); ``` A storm administrator can specify node resource availability by modifying the conf/storm.yaml file located in the storm home directory of that node. ``` supervisor.resources.map: {[type<String>] : [amount<Double>]} ``` Example of Usage: ``` supervisor.resources.map: {"gpu.count" : 2.0} ```
Project: Beam (App Definition and Development / Streaming & Messaging)
File: 38_ai_runinference.md

Prompt: How can I run inference on a trained ML model using Apache Beam? Response: Apache Beam enables efficient inference on both local and remote ML models within your pipelines through the RunInference API. This functionality is available in the Python SDK versions 2.40.0 and later. The Java SDK versions 2.41.0 and later also support the API through Apache Beams framework. The `RunInference` transform performs inference on a of examples using an ML model and outputs a `PCollection` containing both the input examples and the corresponding output predictions. Key features of the RunInference API include: Support for both batch and streaming inference. Centralized model management for efficient memory and bandwidth usage. Compatibility with multiple model frameworks and model hubs. Automatic model refreshing to ensure the latest model version is used. GPU support for model inference. The RunInference API supports a variety of frameworks and model hubs, including , , , , , , , , and . Additionally, you can easily integrate custom model frameworks. To import a model into your Apache Beam pipeline, you will need to configure the object, which wraps the underlying model and allows you to set necessary environment variables for inference. Here is an example of importing a PyTorch model handler for use in your pipeline: ```python from apachebeam.ml.inference.pytorchinference import PytorchModelHandlerTensor from apache_beam.ml.inference.base import RunInference model_handler = PytorchModelHandlerTensor( ) with pipeline as p: predictions = p | 'Read' >> beam.ReadFromSource('a_source') | 'RunInference' >> RunInference(model_handler) ``` For comprehensive end-to-end examples of inference with supported model frameworks and model hubs, refer to the . If you need to run inference on a model that isn't explicitly supported, you can , refer to the example in the Apache Beam GitHub repository. For recommended patterns and best practices when leveraging Apache Beam for inference tasks, see the section in the official documentation. For an example of using the RunInference API in the Java SDK, see the in the Apache Beam GitHub repository. Additionally, for an illustration of a composite Python transform integrating the RunInference API with preprocessing and postprocessing from a Beam Java SDK pipeline, you can refer to the section in the official documentation.
Project: YugabyteDB (App Definition and Development / Database)
File: edit-config-flags.md

title: Edit configuration flags headerTitle: Edit configuration flags linkTitle: Edit configuration flags description: Use YugabyteDB Anywhere to edit configuration flags. menu: v2.18_yugabyte-platform: identifier: edit-config-flags parent: manage-deployments weight: 50 type: docs Adding and modifying configuration flags for your YB-Master and YB-TServer nodes in a YugabyteDB universe allows you to resolve issues, improve performance, and customize functionality. If your universe includes a read replica cluster, you can also add or modify configuration flags for the YB-TServer nodes in the read replica cluster. For more information about the available configuration flags, see the following: You can add and edit configuration flags by opening the universe in the YugabyteDB Anywhere UI and clicking Actions > Edit Flags to open the G-Flags dialog shown in the following illustration: To customize flags of the read replica of a universe that has a read replica cluster, deselect the Apply the same Flags to primary cluster and Read Replica option. (This option is only available for universes with a read replica.) This displays the Read Replica tab. and flags as you would for the primary cluster. Note that read replicas only have YB-TServers. Depending on the flag, the universe may need to be restarted to apply the changes. You can apply changes as follows: Immediately using a rolling restart. Immediately using a concurrent restart. Immediately apply any changes that do not require a restart and wait until the next time the universe is restarted to apply the remaining changes. Click Add Flags > Add to Master to open the Add to Master dialog, then select the flag you want to add to YB-Master and set its value, as per the following illustration: Click Add Flags > Add to T-Server to open the Add to T-Server dialog, then select the flag you want to add to YB-TServer and set its value. Use Add as JSON > Add to Master and Add as JSON > Add to T-Server to import flags in bulk. The flags must be defined as key-value pairs in a JSON format via the in the Add to T-Server or Add to Master dialog, as per the following illustration: To edit a flag: Find the flag you want to change in the FLAG NAME column. Click the Edit Flag icon for either MASTER VALUE or T-SERVER VALUE to open the Edit Flag Value dialog, as per the following illustration: Change the value in the Flag Value field and then click Confirm. To delete the flag's value, click the Remove Flag icon for either MASTER VALUE or T-SERVER VALUE or both. You can add configuration flags when you are creating a new universe, as follows: Navigate to either Dashboard or Universes and click Create Universe. Complete the required sections of the Create Universe page. When you reach G-Flags, perform steps described in .
Project: KICS (Provisioning / Security & Compliance)
File: 7081f85c-b94d-40fd-8b45-a4f1cac75e46.md

title: IAM Access Key Is Exposed hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 7081f85c-b94d-40fd-8b45-a4f1cac75e46 Query name: IAM Access Key Is Exposed Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: IAM Access Key should not be active for root users<br> ```tf title="Positive test num. 1 - tf file" hl_lines="2 7" resource "awsiamaccess_key" "positive1" { user = "root" status = "Active" } resource "awsiamaccess_key" "positive2" { user = "root" } ``` ```tf title="Negative test num. 1 - tf file" resource "awsiamaccess_key" "negative1" { user = "some-user" } resource "awsiamaccess_key" "negative2" { user = "some-user" status = "Active" } resource "awsiamaccess_key" "negative3" { user = "root" status = "Inactive" } ```