cwielenb/CNCF-Dataset huggingface dataset:
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: v1.10.7.md

When attempting to connect to Kafka compatible services like Azure Event Hubs using SALS authentication the connection fails with the message "client has run out of available brokers to talk to." The issue impacts users on Dapr 1.10.x who use Kafka components to connect to Azure Event Hubs. Other Kafka compatible services may be impacted too. The latest versions (1.38.X) of the shopify/sarama kafka library introduced this problem. Downgrading the shopify/sarama library to release 1.37.2 resolves this problem. An issue with the maintainers of the sarama library has been created for further investigation. When using the Dapr sidecar HTTP APIs, some HTTP URLs where not being routed to the correct handler. For example, when prefixing the URL path with duplicated slashes. i.e. `//v1.0/actors/DemoActor/1234/method/SetReminder`. Since v1.10.0, requests which did not have perfect paths according to the API may be routed to the wrong API handler, and typically return some kind of error. The HTTP router inside Dapr was normalizing the request's HTTP path only after evaluating the route, causing routing errors with un-normalized paths. We changed the router used by the Dapr HTTP server to normalize HTTP paths before matching the route.
Project: KICS (Provisioning / Security & Compliance)
File: 1828a670-5957-4bc5-9974-47da228f75e2.md

title: Audit Policy Not Cover Key Security Concerns hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 1828a670-5957-4bc5-9974-47da228f75e2 Query name: Audit Policy Not Cover Key Security Concerns Platform: Kubernetes Severity: <span style="color:#edd57e">Low</span> Category: Observability URL: Audit Policy should cover key security concerns about the sensitive data logged in Kubernetes audit policies<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="6" apiVersion: audit.k8s.io/v1 # This is required. kind: Policy omitStages: "RequestReceived" rules: ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="4" apiVersion: audit.k8s.io/v1 # This is required. kind: Policy rules: level: RequestResponse resources: group: "" resources: ["secrets","configmaps","tokenreviews"] level: Metadata resources: group: "" resources: ["pods","deployments"] level: None resources: group: "" resources: ["pods/exec", "pods/portforward", "pods/proxy", "services/proxy"] ``` ```yaml title="Positive test num. 3 - yaml file" hl_lines="6" apiVersion: audit.k8s.io/v1 # This is required. kind: Policy omitStages: "RequestReceived" rules: level: Metadata resources: group: "" resources: ["secrets","configmaps","tokenreviews"] level: Metadata resources: group: "" resources: ["pods"] level: RequestResponse resources: group: "" resources: ["pods/exec", "pods/portforward", "pods/proxy", "services/proxy"] ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: audit.k8s.io/v1 # This is required. kind: Policy omitStages: "RequestReceived" rules: level: Metadata resources: group: "" resources: ["secrets","configmaps","tokenreviews"] level: Metadata resources: group: "" resources: ["pods","deployments"] level: RequestResponse resources: group: "" resources: ["pods/exec", "pods/portforward", "pods/proxy", "services/proxy"] ```
Project: Fluvio (App Definition and Development / Streaming & Messaging)
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. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. Examples of behavior that contributes to a positive environment for our community include: Demonstrating empathy and kindness toward other people Being respectful of differing opinions, viewpoints, and experiences Giving and gracefully accepting constructive feedback Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience Focusing on what is best not just for us as individuals, but for the overall community Examples of unacceptable behavior include: The use of sexualized language or imagery, and sexual attention or advances of any kind Trolling, insulting or derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or email address, without their explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. Community leaders 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, and will communicate reasons for moderation decisions when appropriate. This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address,posting via an official social media account, or acting as an appointed representative at an online or offline event. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at fluvio-lead@infinyon.com. All complaints will be reviewed and investigated promptly and fairly. All community leaders are obligated to respect the privacy and security of the reporter of any incident. This Code of Conduct is adapted from the , version 2.0, available at https://www.contributor-covenant.org/version/2/0/codeofconduct.html. For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq.
Project: Meshery (Provisioning / Automation & Configuration)
File: tremor.md

layout: integration title: Tremor subtitle: Collaborative and visual infrastructure as code for Tremor image: /assets/img/integrations/tremor/icons/color/tremor-color.svg permalink: extensibility/integrations/tremor docURL: https://docs.meshery.io/extensibility/integrations/tremor description: integrations-category: App Definition and Development integrations-subcategory: Streaming & Messaging registrant: Artifact Hub components: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "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: Pulsar (App Definition and Development / Streaming & Messaging)
File: CONTRIBUTORS.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. --> Amanveer Dhillon Andrews Sahaya Albert Arunabha Ghosh Chiaming Yang JK Kim Jaewoong Choi Jai Asher Joe Francis Lohith BK Ludwig Pummer Masahiro Sakamoto Masakazu Kitajo Matteo Merli Maurice Barnum Mike Marino Nozomi Kurihara Onkar Deshpande Rajagopalan Srinivasan Rajan Dhabalia Sameer Deokule Sangmin Lee Satheesh Nanniyur Siddharth Sunil Boobna Stefanus A Hinardi Vahid Fatourehchi Venkatasubramanian V Venkatesh Iyer Vinit Mahedia Xiaogang Chang Yi Pan Zuhair Parvez
Project: ThreatMapper (Provisioning / Security & Compliance)
File: index.md

title: Installing ThreatMapper Sensors Your production workloads are managed using ThreatMapper Sensors. The ThreatMapper Sensors are implemented as lightweight, privileged containers which monitor activity, discover workloads and retrieve manifests. They communicate with the ThreatMapper Management Console over TLS, using the URL and API key. A single ThreatMapper Console can manage multiple workload types, and on-premise and cloud deployments simultaneously. Before you install the Sensors, obtain the Management Console URL and API key as described in the . You should take care to install the sensor version that matches your Management Console version, as compatibility across versions is not guaranteed. Review the architecture for the Sensor Agent, as described in . ThreatMapper performs detailed scanning of resources using sensor agents that are deployed with the target infrastructure. Sensor containers can be deployed directly to Kubernetes or Fargate, or can be deployed on a Docker environment. If you wish to monitor a Linux-based virtual machine or bare-metal production server, you should install a docker runtime within the host Linux operating system: | Feature | Requirements | |-|-| | CPU: No of cores | 0.2 units of 1 core | | RAM | 200 MB to 1 GB | | Linux kernel version | >= 4.4 | | Connectivity | Access to Deepfence Management Console IP address, port 443 (configurable) | For Windows Server hosts, experimental support exists, but it is not suitable for production use. For your convenience, the ThreatMapper management console provides the default installation commands to install the agent on a docker host or in a kubernetes cluster: | | |:-:| | Default Agent Setup (URL and Key masked) | More detailed instructions are as follows: ```mdx-code-block import DocCardList from '@theme/DocCardList'; import {useCurrentSidebarCategory} from '@docusaurus/theme-common'; <DocCardList items={useCurrentSidebarCategory().items}/> ```
Project: SeaTunnel (App Definition and Development / Streaming & Messaging)
File: sql-udf.md

UDF of SQL transform plugin Use UDF SPI to extends the SQL transform functions lib. ```java package org.apache.seatunnel.transform.sql.zeta; public interface ZetaUDF { / Function name * @return function name */ String functionName(); / The type of function result * @param argsType input arguments type @return result type */ SeaTunnelDataType<?> resultType(List<SeaTunnelDataType<?>> argsType); / Evaluate * @param args input arguments @return result value */ Object evaluate(List<Object> args); } ``` Add these dependencies and provided scope to your maven project: ```xml <dependencies> <dependency> <groupId>org.apache.seatunnel</groupId> <artifactId>seatunnel-transforms-v2</artifactId> <version>2.3.2</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.apache.seatunnel</groupId> <artifactId>seatunnel-api</artifactId> <version>2.3.2</version> <scope>provided</scope> </dependency> <dependency> <groupId>com.google.auto.service</groupId> <artifactId>auto-service</artifactId> <version>1.0.1</version> <scope>provided</scope> </dependency> </dependencies> ``` Add a Java Class implements of ZetaUDF like this: ```java @AutoService(ZetaUDF.class) public class ExampleUDF implements ZetaUDF { @Override public String functionName() { return "EXAMPLE"; } @Override public SeaTunnelDataType<?> resultType(List<SeaTunnelDataType<?>> argsType) { return BasicType.STRING_TYPE; } @Override public Object evaluate(List<Object> args) { String arg = (String) args.get(0); if (arg == null) return null; return "UDF: " + arg; } } ``` Package the UDF project and copy the jar to the path: ${SEATUNNELHOME}/lib. And if your UDF use third party library, you also need put it to ${SEATUNNELHOME}/lib. If you use cluster mode, you need put the lib to all your node's ${SEATUNNEL_HOME}/lib folder and re-start the cluster. The data read from source is a table like this: | id | name | age | |-|-|--| | 1 | Joy Ding | 20 | | 2 | May Ding | 21 | | 3 | Kin Dom | 24 | | 4 | Joy Dom | 22 | We use UDF of SQL query to transform the source data like this: ``` transform { Sql { sourcetablename = "fake" resulttablename = "fake1" query = "select id, example(name) as name, age from fake" } } ``` Then the data in result table `fake1` will update to | id | name | age | |-||--| | 1 | UDF: Joy Ding | 20 | | 2 | UDF: May Ding | 21 | | 3 | UDF: Kin Dom | 24 | | 4 | UDF: Joy Dom | 22 | Add UDF of SQL Transform Connector
Project: Trivy (Provisioning / Security & Compliance)
File: overview.md

In this section you can find step-by-step guides that help you accomplish specific tasks. Please use the side-navigation on the left in order to browse the different topics. You are welcome to create tutorials and showcase them here. Tutorials can be either included in here as full articles, or included as external links under . Before sending PR, please first create an issue (of kind "Documentation") and describe the suggestion, if it's external link or article, and what category it's under. Guidelines: Focus on a specific use case. Start by clearly describing the use case and when/who it is relevant for. Provide an end-to-end set of instructions. Make sure anyone can easily follow. Describe the expected outcome after each step. Include examples as much as possible.
Project: Checkov (Provisioning / Security & Compliance)
File: SECURITY.md

If you think you have found a potential security vulnerability in `checkov`, please email psirt@paloaltonetworks.com directly. Do not file a public issue. If English is not your first language, please try to describe the problem and its impact to the best of your ability. For greater detail, please use your native language and we will try our best to translate it using online services. Please also include the code you used to find the problem and the shortest amount of code necessary to reproduce it. Please do not disclose this to anyone else. We will retrieve a CVE identifier if necessary and give you full credit under whatever name or alias you provide. We will only request an identifier when we have a fix and can publish it in a release. We will respect your privacy and will only publicize your involvement if you grant us permission. This following information discusses the process the `checkov` project follows in response to vulnerability disclosures. If you are disclosing a vulnerability, this section of the documentation lets you know how we will respond to your disclosure. When you report an issue, one of the project members will respond to you within few days. This initial response will at the very least confirm receipt of the report. If we were able to rapidly reproduce the issue, the initial response will also contain confirmation of the issue. If we are not, we will often ask for more information about the reproduction scenario. Our goal is to have a fix for any vulnerability released within two weeks of the initial disclosure. This may potentially involve shipping an interim release that simply disables function while a more mature fix can be prepared, but will in the vast majority of cases mean shipping a complete release as soon as possible. Throughout the fix process we will keep you up to speed with how the fix is progressing. Once the fix is prepared, we will notify you that we believe we have a fix. Often we will ask you to confirm the fix resolves the problem in your environment, especially if we are not confident of our reproduction scenario. At this point, we will prepare for the release. We will obtain a CVE number if one is required, providing you with full credit for the discovery. We will also decide on a planned release date, and let you know when it is. On release day, we will push the patch to our public repository, along with an updated changelog that describes the issue. The change log is generated automatically from commit messages. We will then issue a PyPI release containing the patch. At this point, we will publicise the release. This will involve announcement on our Slack channel (https://codifiedsecurity.slack.com) and all other communication mechanisms available to the core team. We will also explicitly mention which commits contain the fix to make it easier for other distributors and users to easily patch their own versions of `checkov` if upgrading is not an option.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.4.12.md

layout: release date: 2020-10-8 tag: v0.4.12 General Added Release Card to Dashboard @m4tr1k (#1636) [Docs] Add UI screenshot to UI Contributor docs @aditya2499 (#1656) update Maesh to Traefik Mesh @dannylwe (#1659) [Mesheryctl]: Removal of unnecessary line breaks @NupurThakur27 (#1654) Fixing the Broken image of Meshery Architecture in README @spielers (#1649)
Project: Harbor (Provisioning / Container Registry)
File: 1-06-AD-user-log-in-log-out.md

Test 1-06 - AD (Active Directory) User Log In and Log Out (LDAP Mode) ======= To verify that a non-admin user can log in and log out when users are managed externally by an AD server (LDAP mode). User guide This test requires that a Harbor instance is running and available. Harbor is set to authenticate against an AD server. (auth_mode is set to ldap_auth* .) The user data is stored in an AD server. A linux host with Docker CLI installed (Docker client). An Active Directory (AD) server has been set up and it has a few users available for testing. A user has NEVER logged in to Harbor. He/she logs in to the UI for the first time by his/her id in AD. The id could be the cn attribute (or what is configured in ldap_uid) of his/her AD user DN. The user logs out from the UI. The user logs in again to the UI, should not see his/her own account settings and cannot change password(need to go to LDAP/AD for this). The user logs out from the UI. Use the incorrect password and username of the user to log in to the UI and check the error message. On a Docker client host, use `docker login <harbor_host>` command to verify the user can log in by username/password. Run `docker login <harbor_host>` command to log in with incorrect password of the user. Log in as a system admin to UI, go to "admin Options" and should see above AD user in the list. System admin can assign or remove system admin role of the above AD user. Disable or remove the user in AD. The user should no longer log in to UI or by Docker client. The user can log in to UI by AD id in Step 1 & 3, verify the dashboard and navigation bar are for a non-admin user. (should not see admin options) In Step 3, also verify that the user cannot update his/her account settings and cannot change password. After the user logged out in Step 2 & 4, the login page will be displayed again. The error message in Step 5 should not show which input value is incorrect. It should only display the username(email) and password combination is incorrect. Docker client can log in in Step 6. Docker client fails to log in in Step 7. AD user should have no difference from a user in local database in Step 8. The user's login should fail in Step 10. None
Project: ArangoDB (App Definition and Development / Database)
File: on_outcome_construction2.md

+++ title = "`static void onoutcomeconstruction(T *, U &&, V &&) noexcept`" description = "(>= Outcome v2.2.0) Hook invoked by the implicit constructors of `basic_outcome`." categories = ["observer-policies"] weight = 450 +++ One of the constructor hooks for {{% api "basicoutcome<T, EC, EP, NoValuePolicy>" %}}, generally invoked by the implicit constructors of `basicoutcome` which consume two arguments. See each constructor's documentation to see which specific hook it invokes. Requires: Always available. Guarantees: Never throws an exception.
Project: ClickHouse (App Definition and Development / Database)
File: text_log.md

slug: /en/operations/system-tables/text_log Contains logging entries. The logging level which goes to this table can be limited to the `text_log.level` server setting. Columns: `hostname` () Hostname of the server executing the query. `event_date` (Date) Date of the entry. `event_time` (DateTime) Time of the entry. `eventtimemicroseconds` (DateTime64) Time of the entry with microseconds precision. `microseconds` (UInt32) Microseconds of the entry. `thread_name` (String) Name of the thread from which the logging was done. `thread_id` (UInt64) OS thread ID. `level` (`Enum8`) Entry level. Possible values: `1` or `'Fatal'`. `2` or `'Critical'`. `3` or `'Error'`. `4` or `'Warning'`. `5` or `'Notice'`. `6` or `'Information'`. `7` or `'Debug'`. `8` or `'Trace'`. `query_id` (String) ID of the query. `logger_name` (LowCardinality(String)) Name of the logger (i.e.`DDLWorker`). `message` (String) The message itself. `revision` (UInt32) ClickHouse revision. `source_file` (LowCardinality(String)) Source file from which the logging was done. `source_line` (UInt64) Source line from which the logging was done. `messageformatstring` (LowCardinality(String)) A format string that was used to format the message. `value1` (String) - Argument 1 that was used to format the message. `value2` (String) - Argument 2 that was used to format the message. `value3` (String) - Argument 3 that was used to format the message. `value4` (String) - Argument 4 that was used to format the message. `value5` (String) - Argument 5 that was used to format the message. `value6` (String) - Argument 6 that was used to format the message. `value7` (String) - Argument 7 that was used to format the message. `value8` (String) - Argument 8 that was used to format the message. `value9` (String) - Argument 9 that was used to format the message. `value10` (String) - Argument 10 that was used to format the message. Example ``` sql SELECT * FROM system.text_log LIMIT 1 \G ``` ``` text Row 1: hostname: clickhouse.eu-central1.internal event_date: 2020-09-10 event_time: 2020-09-10 11:23:07 eventtimemicroseconds: 2020-09-10 11:23:07.871397 microseconds: 871397 thread_name: clickhouse-serv thread_id: 564917 level: Information query_id: logger_name: DNSCacheUpdater message: Update period 15 seconds revision: 54440 source_file: /ClickHouse/src/Interpreters/DNSCacheUpdater.cpp; void DB::DNSCacheUpdater::start() source_line: 45 messageformatstring: Update period {} seconds value1: 15 value2: value3: value4: value5: value6: value7: value8: value9: value10: ```
Project: YDB (App Definition and Development / Database)
File: delete_from.md

{% include %} Syntax of the `DELETE FROM` statement: {% include %} To delete a row from a table based on a specific column value, the construction `DELETE FROM <table name> WHERE <column name><condition><value/range>` is used. {% note warning %} Note that the use of the `WHERE ...` clause is optional, so when working with `DELETE FROM` it is very important to avoid accidentally executing the command before specifying the `WHERE ...` clause. {% endnote %} {% include %}