cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: 31245f98-a6a9-4182-9fc1-45482b9d030a.md

title: MQ Broker Logging Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 31245f98-a6a9-4182-9fc1-45482b9d030a Query name: MQ Broker Logging Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: Check if MQ Brokers don't have logging enabled in any of the two options possible (audit and general).<br> ```tf title="Positive test num. 1 - tf file" hl_lines="8 1 17" resource "awsmqbroker" "positive1" { broker_name = "no-logging" } resource "awsmqbroker" "positive2" { broker_name = "partial-logging" logs { general = true } } resource "awsmqbroker" "positive3" { broker_name = "disabled-logging" logs { general = false audit = true } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsmqbroker" "negative1" { broker_name = "example" configuration { id = awsmqconfiguration.test.id revision = awsmqconfiguration.test.latest_revision } engine_type = "ActiveMQ" engine_version = "5.15.0" hostinstancetype = "mq.t2.micro" securitygroups = [awssecurity_group.test.id] user { username = "ExampleUser" password = "MindTheGap" } logs { general = true audit = true } } ```
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.12.13.md

RabbitMQ `3.12.13` is a maintenance release in the `3.12.x` . This release on June 1st, 2024. 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.2.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 . When a channel is closed, its consumer metric samples will now be cleared differently depending on the number of them. In , it was over optimized for the uncommon case with a very large number of consumers per channel, hurting the baseline case with one or a few consumers per channel. In part contributed by @SimonUnge (AWS). GitHub issue: CLI tool startup time was reduced. GitHub issue: JSON output formatter now avoids ANSI escape sequences. Contributed by @ariel-anieli. GitHub issue: ANSI escape sequences are no longer used on Windows. Contributed by @ariel-anieli. GitHub issue: If a stream publisher cannot be set up, a clearer message will be logged. GitHub issue: `GET /api/nodes/{name}` failed with a 500 when called with a non-existed node name. GitHub issue: AMQP 1.0 Shovels will no longer set a delivery mode header that is not meaningful in AMQP 1.0. Contributed by @luos (Erlang Solutions). GitHub issue: Upstream node shutdown could produce a scary looking exception in the log. GitHub issue: Exchange federation links could run into an exception. Contributed by @gomoripeti (CloudAMQP). GitHub issue: `cowboy` was updated to To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.12.13.tar.xz` instead of the source tarball produced by GitHub.
Project: ArangoDB (App Definition and Development / Database)
File: awaitables.md

+++ title = "Coroutine awaitables" weight = 20 tags = [ "coroutines", "eager", "lazy", "awaitables" ] +++ The second part of the support is provided by header `<boost/outcome/coroutine_support.hpp>` (or `<boost/outcome/experimental/coroutine_support.hpp>` if you want Coroutine support for Experimental Outcome). This adds into namespace `BOOSTOUTCOMEV2_NAMESPACE::awaitables` (or `BOOSTOUTCOMEV2_NAMESPACE::experimental::awaitables`) these awaitable types suitable for returning from a Coroutinised function: {{% api "eager<T>" %}} An eagerly evaluated Coroutine: invoking `co_await` upon a function returning one of these immediately begins the execution of the function now. If the function never suspends, the overhead is similar to calling an ordinary function. {{% api "lazy<T>" %}} A lazily evaluated Coroutine (often named `task<T>` in most C++ Coroutine literature): invoking `co_await` upon a function returning one of these causes the function to be immediately suspended as soon as execution begins. Only resuming the execution of the coroutine proceeds execution. `atomic_eager<T>` `eager<T>` does not employ thread synchronisation during resumption of dependent coroutines which is fine if you do not traverse kernel threads during a suspend-resume cycle. If you do however potentially traverse kernel threads during suspend-resume, you ought to use `atomic_eager<T>` instead -- this uses atomics to synchronise the setting and checking of state to ensure correctness. `atomic_lazy<T>` Same for `lazy<T>` as `atomic_eager<T>` is for `eager<T>`.
Project: external-secrets (Provisioning / Security & Compliance)
File: getallsecrets.md

In some use cases, it might be impractical to bundle all sensitive information into a single secret, or even it is not possible to fully know a given secret name. In such cases, it is possible that a user might need to sync multiple secrets from an external provider into a single Kubernetes Secret. This is possible to be done in external-secrets with the `dataFrom.find` option. !!! note The secret's contents as defined in the provider are going to be stored in the kubernetes secret as a single key. Currently, it's possible to apply a decoding Strategy during a find operation, but only at the secret level (e.g. if a secret is a JSON with some B64 encoded data within, `decodingStrategy: Auto` would not decode it) To fetch multiple secrets matching a name pattern from a common SecretStore you can apply the following manifest: ```yaml {% include 'getallsecrets-find-by-name.yaml' %} ``` Suppose we contain secrets `/path/key1`, `key2/path`, and `path/to/keyring` with their respective values. The above YAML will produce the following kubernetes Secret: ```yaml pathkey1: Cg== key2_path: Cg== pathtokeyring: Cg== ``` To fetch multiple secrets matching a name pattern from a common SecretStore you can apply the following manifest: ```yaml {% include 'getallsecrets-find-by-tags.yaml' %} ``` This will match any secrets containing all of the metadata labels in the `tags` parameter. At least one tag must be provided in order to allow finding secrets by metadata tags. Some providers support filtering out a find operation only to a given path, instead of the root path. In order to use this feature, you can pass `find.path` to filter out these secrets into only this path, instead of the root path. By default, kubernetes Secrets accepts only a given range of characters. `Find` operations will automatically replace any not allowed character with a ``. So if we have a given secret `ac` and `a/c` would lead to a naming conflict. If you happen to have a case where a conflict is happening, you can use the `rewrite` block to apply a regexp on one of the find operations (for more information please refer to ). You can also set `dataFrom.find.conversionStrategy: Unicode` to reduce the collistion probability. When using `Unicode`, any invalid character will be replaced by its unicode, in the form of `UXXXX`. In this case, the available kubernetes keys would be `ac` and `aU2215_c`, hence avoiding most of possible conflicts. !!! note "PRs welcome" Some providers might not have the implementation needed for fetching multiple secrets. If that's your case, please feel free to contribute!
Project: KICS (Provisioning / Security & Compliance)
File: 48207659-729f-4b5c-9402-f884257d794f.md

title: EFS Not Encrypted hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 48207659-729f-4b5c-9402-f884257d794f Query name: EFS Not Encrypted Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: Elastic File System (EFS) must be encrypted<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1 11" resource "awsefsfile_system" "positive1" { creation_token = "my-product" tags = { Name = "MyProduct" } } resource "awsefsfile_system" "positive2" { creation_token = "my-product" encrypted = false tags = { Name = "MyProduct" } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsefsfile_system" "negative1" { creation_token = "my-product" encrypted = true tags = { Name = "MyProduct" } } ```
Project: SeaTunnel (App Definition and Development / Streaming & Messaging)
File: Rabbitmq.md

Rabbitmq source connector Used to read data from Rabbitmq. :::tip The source must be non-parallel (parallelism set to 1) in order to achieve exactly-once. This limitation is mainly due to RabbitMQs approach to dispatching messages from a single queue to multiple consumers. | name | type | required | default value | |-||-|| | host | string | yes | - | | port | int | yes | - | | virtual_host | string | yes | - | | username | string | yes | - | | password | string | yes | - | | queue_name | string | yes | - | | schema | config | yes | - | | url | string | no | - | | routing_key | string | no | - | | exchange | string | no | - | | networkrecoveryinterval | int | no | - | | topologyrecoveryenabled | boolean | no | - | | automaticrecoveryenabled | boolean | no | - | | connection_timeout | int | no | - | | requestedchannelmax | int | no | - | | requestedframemax | int | no | - | | requested_heartbeat | int | no | - | | prefetch_count | int | no | - | | delivery_timeout | long | no | - | | common-options | | no | - | the default host to use for connections the default port to use for connections virtual host the virtual host to use when connecting to the broker the AMQP user name to use when connecting to the broker the password to use when connecting to the broker convenience method for setting the fields in an AMQP URI: host, port, username, password and virtual host the queue to publish the message to the routing key to publish the message to the exchange to publish the message to the schema fields of upstream data. how long will automatic recovery wait before attempting to reconnect, in ms if true, enables topology recovery if true, enables connection recovery connection tcp establishment timeout in milliseconds; zero for infinite initially requested maximum channel number; zero for unlimited Note: Note the value must be between 0 and 65535 (unsigned short in AMQP 0-9-1). the requested maximum frame size Set the requested heartbeat timeout Note: Note the value must be between 0 and 65535 (unsigned short in AMQP 0-9-1). prefetchCount the max number of messages to receive without acknowledgement deliveryTimeout maximum wait time, in milliseconds, for the next message delivery Source plugin common parameters, please refer to for details simple: ```hocon source { RabbitMQ { host = "rabbitmq-e2e" port = 5672 virtual_host = "/" username = "guest" password = "guest" queue_name = "test" schema = { fields { id = bigint c_map = "map<string, smallint>" c_array = "array<tinyint>" } } } } ``` Add Rabbitmq source Connector
Project: KICS (Provisioning / Security & Compliance)
File: 9f4a9409-9c60-4671-be96-9716dbf63db1.md

title: ECS Task Definition Network Mode Not Recommended hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 9f4a9409-9c60-4671-be96-9716dbf63db1 Query name: ECS Task Definition Network Mode Not Recommended Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: NetworkMode should be 'awsvpc' in ecstask_definition. AWS VPCs provides the controls to facilitate a formal process for approving and testing all network connections and changes to the firewall and router configurations<br> ```tf title="Positive test num. 1 - tf file" hl_lines="3" resource "awsecstask_definition" "positive1" { family = "service" network_mode = "none" volume { name = "service-storage" host_path = "/ecs/service-storage" } placement_constraints { type = "memberOf" expression = "attribute:ecs.availability-zone in [us-west-2a, us-west-2b]" } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsecstask_definition" "negative1" { family = "service" network_mode = "awsvpc" volume { name = "service-storage" host_path = "/ecs/service-storage" } placement_constraints { type = "memberOf" expression = "attribute:ecs.availability-zone in [us-west-2a, us-west-2b]" } } ```
Project: KICS (Provisioning / Security & Compliance)
File: abcb818b-5af7-4d72-aba9-6dd84956b451.md

title: Using Default Namespace hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: abcb818b-5af7-4d72-aba9-6dd84956b451 Query name: Using Default Namespace Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Insecure Configurations URL: The default namespace should not be used<br> ```tf title="Positive test num. 1 - tf file" hl_lines="9 4" resource "kubernetes_pod" "test" { metadata { name = "terraform-example" namespace = "default" } } resource "kubernetescronjob" "test2" { metadata { name = "terraform-example" } } ``` ```tf title="Negative test num. 1 - tf file" resource "kubernetes_pod" "test3" { metadata { name = "terraform-example" namespace = "terraform-namespace" } } resource "kubernetescronjob" "test4" { metadata { name = "terraform-example" namespace = "terraform-namespace" } } ```
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: dart-authorization.md

title: HTTP API Authorization in Dart labels: layer: network category: application software: dart tutorials: https://github.com/adaptant-labs/opa-api-authz-dart/README.md code: https://github.com/adaptant-labs/opa-api-authz-dart inventors: adaptant This integration demonstrates how to leverage OPA to perform basic HTTP API authorization in a simple Dart microservice. OPA makes it possible to provide fine-grained context-aware authorization for each REST endpoint and access method.
Project: YugabyteDB (App Definition and Development / Database)
File: read-replicas-ysql.md

title: Read replicas and follower reads in YugabyteDB YSQL headerTitle: Read replicas linkTitle: Read replicas description: Explore read replicas in YugabyteDB using YSQL headContent: Replicate data asynchronously to one or more read replica clusters menu: v2.18: name: Read replicas identifier: explore-multi-region-deployments-read-replicas-ysql parent: explore-multi-region-deployments weight: 750 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li > <a href="../read-replicas-ysql/" class="nav-link active"> <i class="icon-postgres" aria-hidden="true"></i> YSQL </a> </li> <li > <a href="../read-replicas-ycql/" class="nav-link"> <i class="icon-cassandra" aria-hidden="true"></i> YCQL </a> </li> </ul> Documentation for YSQL read replicas is forthcoming.
Project: in-toto (Provisioning / Security & Compliance)
File: ROADMAP.md

Roadmap ======= _Note: Previous roadmaps can be found with the roadmap reviews for that period. _ This document spans the Roadmap for the in-toto main implementation for the time window from August 2020 to August 2021. The main focus of this year is to achieve spec compliance and agreement between all the different implementers, integrators and users throughout the in-toto ecosystem. Although the previous years's roadmap aimed to culminate with in-toto's 1.0 release, we decided to hold off for a couple of months before we committed to such an important milestone. The main rationale is that there are some outstanding tickets we have not been able to squash. We'd much rather tag in-toto 1.0 once those are fixed. There has been quite the activity in the in-toto specification world. Namely, there are three new ITE's related to integration with existing technologies and tracking abstract artifacts. This year we will focus on making sure the reference implementation can provide for these community-sought-for plans. Since the first two ITEs relate to TUF integration, we will make sure we have a tighter testing harness with co-dependent libraries (e.g., securesystemslib). In addition we will make sure common elements (such as public key components and signatures) can be cross-verifiable by both implementations. A broader ITE is ITE-4, which focuses on abstract resources. This is paramount for some uses, such as the CNAB security specification. In this case, we will be adding facilities for custom artifact hashers/resolvers. We also envision providing some baseline catalog of these hashers for common usecases so that people have something to reference when writing their own and of course use them. in-toto is already marked as "Silver" under the Core Infrastructure Initiative best practices badge. This year we aim to upgrade our rating to "Gold". To work towards this goal, we'll review and comply with the few missing requirements for the gold badge. This year we intend to continue our release schedule. This includes a more formal Service Level Agreement considering a four-month window between minor versions. Months 1-2: Normal development. Including new features, refactoring, and bugfixes. Month 3: Feature freeze. Only bugfixes and security vulnerabilities are allowed. Month 4: Release candidate period. A new version is released by the end of the fourth month. This schedule will roughly match the following months: These time windows will also be used to review and update all stakeholders with the status of the in-toto implementation.
Project: StarRocks (App Definition and Development / Database)
File: date_diff.md

displayed_sidebar: "English" Returns the difference between two date values in the specified unit. This function returns the value of `expr1 - expr2` expressed in terms of `unit`. For example, `date_diff('second', '2010-11-30 23:59:59', '2010-11-30 20:58:59')` returns the difference between the two DATETIME values in unit of seconds. This function is supported from v3.1. The difference between date_diff and lies in that datediff() does not support the `unit` parameter. ```Haskell BIGINT DATE_DIFF(VARCHAR unit, DATETIME expr1, DATETIME expr2) ``` `expr1` and `expr2`: the two datetime values you want to compare, required. Supported data types are DATETIME and DATE. `unit`: the unit used to express the time difference, required. The following `unit` values are supported: year, quarter, month, week, day, hour, minute, second, millisecond. Returns a BIGINT value. If `expr1` is earlier than `expr2`, a negative value is returned. If `unit` is invalid, an error is returned. If any input value is NULL, NULL is returned. If the specified date does not exist, for example, `2022-11-31`, NULL is returned. ```Plain Text mysql> select date_diff('second', '2010-11-30 23:59:59', '2010-11-30 20:58:59'); +-+ | date_diff('second', '2010-11-30 23:59:59', '2010-11-30 20:58:59') | +-+ | 10860 | +-+ mysql> select date_diff('minute', '2010-11-30 23:59:59', '2010-11-30 20:58:59'); +-+ | date_diff('minute', '2010-11-30 23:59:59', '2010-11-30 20:58:59') | +-+ | 181 | +-+ mysql> select date_diff('hour', '2010-11-30 23:59:59', '2010-11-30 20:58:59'); +--+ | date_diff('hour', '2010-11-30 23:59:59', '2010-11-30 20:58:59') | +--+ | 3 | +--+ mysql> select date_diff('millisecond', '2010-11-30 23:59:59', '2010-11-30 20:58:59'); ++ | date_diff('millisecond', '2010-11-30 23:59:59', '2010-11-30 20:58:59') | ++ | 10860000 | ++ ```
Project: Meshery (Provisioning / Automation & Configuration)
File: 1.11.4.md

component: 1.11.4 integrations: consulmesh.meshery consulmesh_definition.json exportedservices.meshery exportedservices.meshery ingressgateway.meshery ingressgateway.meshery mesh.meshery mesh.meshery proxydefaults.meshery proxydefaults.meshery servicedefaults.meshery servicedefaults.meshery serviceintentions.meshery serviceintentions.meshery serviceresolver.meshery serviceresolver.meshery servicerouter.meshery servicerouter.meshery servicesplitter.meshery servicesplitter.meshery terminatinggateway.meshery terminatinggateway.meshery
Project: YugabyteDB (App Definition and Development / Database)
File: frame_clause,frame_bounds,frame_start,frame_end,frame_bound,frame_exclusion.grammar.md

```output.ebnf frameclause ::= [ { RANGE | ROWS | GROUPS } framebounds ] [ frame_exclusion ] framebounds ::= framestart | BETWEEN framestart AND frameend framestart ::= framebound frameend ::= framebound frame_bound ::= UNBOUNDED PRECEDING | offset PRECEDING | CURRENT ROW | offset FOLLOWING | UNBOUNDED FOLLOWING frame_exclusion ::= EXCLUDE CURRENT ROW | EXCLUDE GROUP | EXCLUDE TIES | EXCLUDE NO OTHERS ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: opa_cli.md

+++ title = "opa_cli resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "opa_cli" identifier = "inspec/resources/os/opacli.md opacli resource" parent = "inspec/resources/os" +++ Use the `opa_cli` Chef InSpec audit resource to query Open Policy Agent (OPA) using an OPA policy file, a data file, and a query. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} An `opa_cli` resource block declares OPA policy configurations that can be tested. describe opa_cli(policy: "example.rego", data: "input.json", query: "data.example.allow") do its(["result"]) { should eq "value" } end where `data` specifies the json formatted input data or file path. `policy` the path to policy file. `query` specifies the query to be run. `its(["result"]) { should eq "value" }` compares the results of the query against the expected result in the test The `opacli` resource InSpec resource accepts `policy`, `data`, `query`, and `opaexecutable_path` as parameters. The path to the OPA policy file. An OPA query as a JSON data file or a string in JSON format. The query to be evaluated against policy and input data. This is the full path to the OPA binary or EXE file used for running the OPA CLI or OPA commands. By default it will consider that the path is added in PATH variable. The `result` property checks whether the resource query returns an empty result. its('result') { should be nil } The `allow` property checks if specific input matches the policy defined in OPA. This matcher will not work if `allow` is not defined in the policy file. its('allow') { should eq 'value' } The following examples show how to use this Chef InSpec audit resource: describe opacli(query: "data.example.allow", policy: "example.rego", data: "input.json", opaexecutable_path: "./opa") do its("result") { shoule_not be nil } its(["result", 0, "expressions", 0, "value"]) { should eq true } its("allow") { should eq "true" } end The above example shows how the `allow` value can be fetched in two ways. {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.122.md

layout: release date: 2023-08-12 tag: v0.6.122 [Extension] Add Collaborator Extension Point @senali-d (#8323) Update logs.svg @ritiksaxena124 (#8448) [Performance profile]- fix label on new certificate upload @sudhanshutech (#8421) [bug] Fix cancelled ctx @theBeginner86 (#8453) [CI] Workflow update of meshkit error docs @suhail34 (#8451) Added new job to send emails on job failure @VaibhavMalik4187 (#8449) Update build-and-release-stable.yml @theBeginner86 #8455 [CI] Workflow update of meshkit error docs @suhail34 (#8451) [Extension] Add Collaborator Extension Point @senali-d (#8323) Thank you to our contributors for making this release possible: @Chadha93, @MUzairS15, @VaibhavMalik4187, @l5io, @leecalcote, @ritiksaxena124, @senali-d, @sudhanshutech, @suhail34, @theBeginner86 and l5io