jiebi/CodeConvo huggingface dataset:
A certain software component product is created and packaged by a Supplier.  The package by itself does not include a proof of authenticity.  A signing authority is tasked with adding a proof of <del> authenticity.  Trust has to be established from the Supplier towards the Signing Authority - and vice versa.  The mutual trust relationship (trust bond) between Supplier and Signing Authority is </del> <ins> authenticity.  Trustworthiness has to be established from the Supplier towards the Distributor - and vice versa.  The mutual trustworthiness relationship between Supplier and Distributor is </ins> established per each individual software component package. A consumer of a released software wants: <del> to understand and verify that an actual trust bond exists between the Supplier of a certain software component package and the Signing Authority of that software component package. </del> <ins> to understand and verify that an actual trustworthiness relationship exists between the Supplier of a certain software component package and the Distributor of that software component package. </ins> There is no standardized way to: <del> enable the consumer to verify that a trust bond for a certain software component package exists and is still valid. </del> <ins> enable the consumer to verify that a trustworthiness relationship for a certain software component package exists and is still valid. </ins> 3.2.
A software component source (e.g., a library) released by a certain original producer is becoming popular.  The released software component source is accompanied by a statement of authenticity (e.g., <del> a detached signature).  Over time, there has been an increasing amount of providers of the same version of the software component source over the Internet.  Some popular providers package the software component and provide the package with proof of authenticity using their own issuer authority.  Some packages include the original statement of authenticity, and some do not.  Over time, some providers no longer offer the exact same software component source but pre-compiled software component binaries.  Some sources do not provide the exact same software component but include patches and </del> <ins> a detached signature).  Over time, due to its enhanced applicability to various products, there has been an increasing amount of multiple providers of the same software component version on the internet. Some providers include this particular software component as part of their release package bundle and provide the package with proof of authenticity using their own issuer authority.  Some packages include the original statement of authenticity, and some do not.  Over time, some providers no longer offer the exact same software component source but pre-compiled software component binaries.  Some sources do not provide the exact same software component but include patches and </ins> fixes produced by third-parties, as these emerge faster than solutions from the original producer.  Due to complex distribution and promotion lifecycle scenarios, the original software component
3.5. <ins> In contrast to operating systems or user space software components of a large and complex systems, firmware components are often already executed during boot-cycles before there is an opportunity to authenticate them. Authentication takes place, for example, by validating a signature or by creating a hash of measurements and comparing them to a reference value.  Corresponding procedures are often called authenticated, measured, or secure boot.  The output of these high assurance boot procedures is often used as input to more complex verification known as remote attestation procedures. If measurements before execution are not possible, static after-the- fact analysis is required. When best practices are followed, in such cases measurements (e.g., a hash or digests) are stored in a protected or shielded environment (e.g., TEEs or TPMs). After finishing a high assurance boot sequence, these measurements about foundational firmware are retrieved after-the-fact from shielded locations and must be compared to reference values that are part of Reference Integrity Manifests (RIMs). A verifying system appraising the integrity of a high assurance boot sequence must identify, locate, retrieve, and authenticate corresponding RIMs. A consumer of published software wants: to easily identify sources for RIMs to select appropriate RIMs and download them for the appraisal of measurements to be able to assure the authenticity, applicability, and freshness of RIMs over time There is no standardized way to: identify, locate, retrieve and authenticate RIMs in a uniform fashion to uniquely identify among multiple potential available RIMs (e.g., by age, source, signing authority, etc.) to store RIMs in a fashion that enables their usage in appraisal procedures years after they were created in a secure and believable fashion 3.6. </ins> An organization has established procurement requirements and compliance policies for software use.  In order to allow the acquisition and deployment of software in certain security domains of
allow for more than one level of complexity of audit procedures (potentially depending on criticality) <del> 3.6. </del> <ins> 3.7. </ins> Some software is deployed on systems not connected to the Internet. Authenticity checks for off-line systems can occur at time of deployment of released software.  Off-line systems require appropriate configuration and maintenance to be able to conduct <del> useful authenticity checks.  If the off-line systems are operation are part of constrained node environments, they do not possess the </del> <ins> useful authenticity checks.  If the off-line systems in operation are part of constrained node environments, they do not possess the </ins> capabilities to process and evaluate all kinds of different authenticity proofs that come with a released software.
such as global open source repositories down to off-line constrained devices <del> 3.7. 3.7.1. Firmware is ubiquitous in IoT devices (e.g., appliances, televisions, smart LED bulbs, HVAC, automobiles), runs at the highest privilege level possible, and is often the bedrock on which the security story of the devices it powers. </del> <ins> 3.8. </ins> <del> Firmware is powerful.  It runs in the highest privilege level possible and is often the bedrock on which the security story of the devices it powers. </del> <ins> 3.8.1. </ins> <del> 3.7.2. </del> <ins> Firmware is a critical component for successful execution of any constrained IoT device.  It is often the bedrock on which the security story of the devices it powers. </ins> Personal health monitoring devices, i.e., eHealth devices, are generally battery driven and offer health telemetry monitoring, such
3.3. <del> A released software product is accompanied by a set of complementary statements about it's security compliance and is deemed trustworthy by both producers and consumers.  After some time, new statements produced and published by third-parties show that a software component used in the software product contains a potential weakness. Over time, a statement from another third-party illustrates that the weakness is exposed in the software product in a way that it is an exploitable vulnerability.  The producer of the software product now provides a statement that confirms the linking of software component </del> <ins> This use case is a specialization of the use case above. A released software product is often accompanied by a set of complementary statements about it's security compliance.  This gives enough confidence to both producers and consumers that the released software has a good security standard and is suitable to use. Subsequently, multiple security researchers often run sophisticated security analysis tools on the same product.  The intention is to identify any security weaknesses or vulnerabilities in the package. Initially a particluar analysis can identify itself as a simple weakness in a software component.  Over a period of time, a statement from another third-party illustrates that the weakness is exposed in the same software component in a way that it is an exploitable vulnerability.  The producer of the software product now provides a statement that confirms the linking of software component </ins> vulnerability with the software product and also issues an advisory <del> statement on how to mitigate the vulnerability ad-hoc.  Later, the </del> <ins> statement on how to mitigate the vulnerability.  At first, the </ins> producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that <del> inhibits exploitation.  A second update of the software product includes a patch to the affected software component created by the software product producer.  A third update includes an updated version of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and consumers. </del> <ins> inhibits exploitation.  Later, A second update of the software product includes a security patch to the affected software component from the software producer.  Finally, A third update includes a new release (updated version) of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and consumers. </ins> A consumer of a released software wants: <del> to know where to get these statements from producers and third- parties related to the software product in a timely and </del> <ins> to know where to get these security statements from producers and third-parties related to the software product in a timely and </ins> unambiguous fashion, how to attribute them to an authoritative issuer,
Authenticity checks for off-line systems can occur at time of deployment of released software.  Off-line systems require appropriate configuration and maintenance to be able to conduct <del> useful authenticity checks.  If the off-line systems are operation are part of constrained node environments, they do not possess the </del> <ins> useful authenticity checks.  If the off-line systems in operation are part of constrained node environments, they do not possess the </ins> capabilities to process and evaluate all kinds of different authenticity proofs that come with a released software.
3.7.1. <del> Firmware is ubiquitous in IoT devices (e.g., appliances, televisions, smart LED bulbs, HVAC, automobiles), runs at the highest privilege level possible, and is often the bedrock on which the security story of the devices it powers. Firmware is powerful.  It runs in the highest privilege level possible and is often the bedrock on which the security story of the devices it powers. 3.7.2. </del> <ins> Firmware is a critical component for successful execution of any constrained IoT device.  It is often the bedrock on which the security story of the devices it powers. </ins> Personal health monitoring devices, i.e., eHealth devices, are generally battery driven and offer health telemetry monitoring, such
4.1. Micro Coding Wizards (MCW) is a small, fictional, software <del> development company providing software solutions to help manage a fleet of electric vehicles (EV) for corporations.  MCW's software solution, MCWManager, is an asset management platform specifically designed to manage electric vehicle fleets.  MCWManager tracks usage, charge level, range, and other important characteristics of each EV in the fleet.  The US Department of the Interior (DOI), a government agency has expressed interest in licensing the MCWManager software to manage a fleet of 20 Electric Vehicles, spread across the Western Region, which includes States west of the Rocky Mountains. </del> <ins> development company providing software solutions for managing fleets of electric vehicles (EV).  MCW's software solution, MCWManager, is an asset management platform specifically designed to manage fleets of electric vehicles.  MCWManager tracks usage, charge level, range, and other important characteristics of each EV in the fleet.  The US Department of the Interior (DOI), a government agency has expressed interest in licensing the MCWManager software to manage a fleet, starting with 20 Electric Vehicles. </ins> MCW has been informed by DOI that their software will be subject to Cybersecurity Executive Order (EO) 14028 recommendations from NIST
Makes a claim to establish its own identity as a producer of the overall SBOM. <del> The issuer in certain situations can make further claims (example claims that relate to steps that might assist independent building of the software components, to arrive at the final deliverable). </del> <ins> The issuer may make further claims, fo example: claims that relate to steps that might assist independent building of the software components. </ins> <del> Once all the claim construction is complete, make a CBOR data payload of all the claims. </del> <ins> Place all claims in a CBOR data payload for submission to SCITT. </ins> <del> Signs the payload using SCITT recommended signing scheme.  For now this will be COSE signing. </del> <ins> Signs the payload using COSE signing. </ins> <del> Submits the COSE signed object to the transparent registry. </del> <ins> Submits the COSE signed object to the SCITT instance. </ins> <del> Receives the return receipts (A COSE Countersignature object, </del> <ins> Receives the return receipts: A COSE Countersignature object, </ins> containing the inclusion proofs, the original COSE payload and a <del> signature from the transparency service). </del> <ins> signature from the transparency service. </ins> <del> Producer would then ship the software along with the return </del> <ins> Producer would then distribute the software along with the return </ins> receipts to the Software Consumer. 4.1.2. <del> A software consumer, in this case DOI, receives the software </del> <ins> A software consumer, in this case DOI, consumes the software </ins> deliverable along with return receipts from the Producer. The Consumer may choose to verify that the received software
Cybersecurity Executive Order (EO) 14028 recommendations from NIST and will need to supply "Software Bill of Materials" (SBOM) and a "Vulnerability Disclosure Report" (VDR) NIST attestation to the DOI <del> prior to procurement. </del> <ins> prior to procurement.  Unlike SBOMs, VDRs continue to evolve over time as new vulnerabilities are discovered that may impact previously released software.  Consumers will continually check their vendors and potentially other SCITT sources for updated VDR reports providing the most up to date information on new and previously consumed software. </ins> 4.2.1.
Generate a Vulnerability Disclosure Report (VDR) listing all the known vulnerabilities and mitigation plans to meet Executive Order <del> 14028 and OMB M-22-18 requirements. </del> <ins> 14028 and OMB M-22-18 requirements with the date the report was generated. </ins> Digitally sign the VDR artifact. <del> Place the VDR and digital signature artifacts within an access- controlled location, i.e., a customer portal, and provide the end consumer with a link to these artifacts for downloading to the customers environment. </del> <ins> Submit the VDR and digital signature to the same SCITT instance, providing a common feed of supply chain information. If the VDR contains critical vulnerabilities, a SCITT claim may be generated, identifying any potential mitigations such as new versions. </ins> 4.2.2.
third-party code, development practices and tools, deployment methods and infrastructure, and interfaces and protocols.  The software supply chain comprises all elements associated with an application's <del> design, development, deployment, and maintenance throughout its entire lifecycle.  The complexity of software coupled with a lack of lifecycle visibility increases the risks associated with system attack surface and the number of cyber threats capable of harmful impacts, such as exfiltration of data, disruption of operations, and loss of reputation, intellectual property, and financial assets. There is a need for a platform architecture that will allow consumers to know that suppliers maintained appropriate security practices without requiring access to proprietary intellectual property. SCITT-enabled products and analytics solutions will assist in managing compliance and assessing risk to help prevent and detect supply chain attacks across the entire software lifecycle while prioritizing data privacy. </del> <ins> design, development, build, integration, deployment, and maintenance throughout its entire lifecycle.  The complexity of software coupled with a lack of lifecycle visibility increases the risks associated with system attack surface and the number of cyber threats capable of harmful impacts, such as exfiltration of data, disruption of operations, and loss of reputation, intellectual property, and financial assets.  There is a need for a platform architecture that will allow consumers to know that suppliers maintained appropriate security practices without requiring access to proprietary intellectual property.  SCITT-enabled products and analytics solutions will assist in managing compliance and assessing risk to help prevent and detect supply chain attacks across the entire software lifecycle while prioritizing data privacy. </ins> 1.1.
TIPS uses this directory schema to generate template URIs which allow clients to construct the location of incremental updates after receiving the tips-view-uri path from the server.  The generic <del> template for the location of the update item on the edge from node i to node j in the updates graph is: </del> <ins> template for the location of the update item on the edge from node 'i' to node 'j' in the updates graph is: </ins> Due to the sequential nature of the update item IDs, a client can long poll a future update that does not yet exist (e.g., the
4.4. Conceptually, the sequence number space of TIPS views satisfy the <del> following requirements: First, for a specific client, it may expect to see the same sequence number for the same version, to avoid occasional disconnections.  Second, the coupling of sequence numbers should be minimized for ALTO resources monitored by multiple clients. </del> <ins> following requirements: First, a specific client may expect to see the same sequence number for the same version to avoid occasional disconnections.  Second, the coupling of sequence numbers should be minimized for ALTO resources monitored by multiple clients. </ins> <del> Thus, the sequence number space is constant for each TIPS view per </del> <ins> Thus, the sequence number space is constant for each TIPS view per- </ins> client but is independent across TIPS views.  Note that For the same TIPS resource queried by different clients, multiple TIPS views will be created, one for each client, whose sequence number spaces are independent. <del> Independence implies that the clients must not assume there is a </del> <ins> Independence implies that ALTO clients must not assume there is a </ins> consensus of how different versions map to sequence numbers but does not force the sequence numbers to be different.  See shared- tips-view for cases where an ALTO server may desire to use the
5.4. <del> Extending the IRD example in Section 8.1 of RFC8895, below is the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and ALTO TIPS. </del> <ins> Extending the IRD example in Section 8.1 of RFC8895, ex-ird is the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and ALTO TIPS. </ins> Note that it is straightforward for an ALTO server to run HTTP/2 and support concurrent retrieval of multiple resources such as "my-
"400 Bad Request" to the ALTO client; the body of the response follows the generic ALTO error response format specified in Section 8.5.2 of RFC7285.  Hence, an example ALTO error response has <del> the format: </del> <ins> the format shown in ex-bad-reques. </ins> Note that "field" and "value" are optional fields.  If the "value" field exists, the "field" field MUST exist.
For simplicity, assume that the ALTO server is using the Basic authentication.  If a client with username "client1" and password "helloalto" wants to create a TIPS view of an ALTO Cost Map resource <del> with resource ID "my-routingcost-map", it can send the following request: </del> <ins> with resource ID "my-routingcost-map", it can send the request depiced in ex-op. </ins> <del> If the operation is successful, the ALTO server returns the following message: </del> <ins> If the operation is successful, the ALTO server returns the message shown in ex-op-rep. </ins> 6.4.
correctly enabled.  The requested URL is the root path of the TIPS view, appended with "push", as shown below. <del> The server returns an JSON object with content type "application/ alto-tipsparams+json".  The response MUST include only one field "server-push".  If the server push is enabled, the value of the "server-push" field MUST be the JSONBool value "true" (without the quote marks), and otherwise JSONBool value "false" (without the quote marks). </del> <ins> The server returns a JSON object with content type "application/alto- tipsparams+json".  The response MUST include only one field "server- push".  If the server push is enabled, the value of the "server-push" field MUST be the JSONBool value "true" (without the quote marks), and otherwise JSONBool value "false" (without the quote marks). </ins> 8.1.3.
is communicated using PACI Extensions defined in [RFC7798] Section 4.4.4.2. A WebRTC implementation that has negotiated use of RTP header extensions containing TSCI information (such as the Dependency Descriptor [DD]) SHOULD <del> NOT send TSCI information within the PACI, and where TSCI information is being received in RTP header extensions MUST ignore TSCI information contained in the PACI. </del> <ins> NOT send TSCI information within the PACI.  If TSCI information is being received in an RTP header extension, implementations MUST ignore TSCI information contained in the PACI. </ins> Implementations of the H.265 codec have utilized a wide variety of optional parameters.  To improve interoperability, the following
tx-mode: Implementations SHOULD NOT include this parameter within SDP. If no tx-mode parameter is present, a value of "SRST" MUST be inferred. <del> Support for the "MRST" and "MRMT" modes is OPTIONAL; implementations that do not support the "MRST" or "MRMT" modes MUST NOT include these modes in the tx-mode parameter. </del> <ins> Implementations MUST support "SRST"; support for "MRST" and "MRMT" is OPTIONAL. Implementations that do not support "MRST" or "MRMT" MUST NOT include these tx-mode values in SDP. </ins> sprop-sps, sprop-pps, sprop-vps, sprop-sei: H.265 allows sequence and picture information to be sent both in-band and out-of-band.  WebRTC implementations
This document defines state variables and constants for the BBR algorithm. <del> The variables starting with C, P, or rs not defined below are defined in delivery-rate-samples, "Delivery Rate Samples". </del> <ins> Variables for connection state (C), per-packet state (P), or per-ACK rate sample (rs) that are not defined below are defined in delivery- rate-samples, "Delivery Rate Samples". </ins> 2.1.
bottleneck link in one round-trip or less.  As noted in BBRDrainPacingGain, any value at or below 1 / BBRStartupCwndGain = 1 / 2 = 0.5 will theoretically achieve this.  BBR uses the value 0.35, <del> which has been shown to offer good performance on YouTube, when compared with other alternatives. </del> <ins> which has been shown to offer good performance when compared with other alternatives. </ins> 2.6.