jiebi/TextFlow huggingface dataset:
Original text:
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>  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>  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>  3.2.

Reviewer comments:
Signed-off-by: Henk Birkholz
Henk, The Distributor isn’t always the signing authority. It’s true in some app stores, but beyond that the model breaks, down. Walmart doesn’t digitally sign software it sells/distributes. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
Then this is going on the agenda for Monday, too. Thanks Dick
Thanks, Henk. Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
From discussion with Henk I believe the use-case here is an app store-like promotion scenario. If that's true, I recommend we refer to this as the relationship between a supplier/producer and the distributor. While signing is a property of the relationship between an app creator and an app store we can increase the clarity of the use-case by describing the roles in the relationship (producer/distributor/consumer). I've made some suggestions on the PR to replace "Signing Authority" with "Distributor".

Revised text:
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  <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:  <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:  <ins> enable the consumer to verify that a trustworthiness relationship for a certain software component package exists and is still valid. </ins> 3.2.
Original text:
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>  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

Reviewer comments:
Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!

Revised text:
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.,  <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
Original text:
3.5.  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

Reviewer comments:
Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!

Revised text:
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
Original text:
allow for more than one level of complexity of audit procedures (potentially depending on criticality) <del> 3.6. </del>  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>  capabilities to process and evaluate all kinds of different authenticity proofs that come with a released software.

Reviewer comments:
Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!

Revised text:
allow for more than one level of complexity of audit procedures (potentially depending on criticality)  <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  <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.
Original text:
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>  <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>  <del> 3.7.2. </del>  Personal health monitoring devices, i.e., eHealth devices, are generally battery driven and offer health telemetry monitoring, such

Reviewer comments:
Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!

Revised text:
such as global open source repositories down to off-line constrained devices  <ins> 3.8. </ins>  <ins> 3.8.1. </ins>  <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
Original text:
also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing installation. <del> 3.7.2.1. Even with a robust firmware update system, the following problems remain as given below: </del>  How does the client applying the firmware update on the system know that the received firmware is not faulty or malicious?

Reviewer comments:
Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!

Revised text:
also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing installation.  <ins> The various stake holders of a firmware update system wants to ascertain: </ins> How does the client applying the firmware update on the system know that the received firmware is not faulty or malicious?
Original text:
Consumers want to assess whether to trust a promoter or not (4.3.4) <del> To be continued... </del> 

Reviewer comments:
Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!

Revised text:
Consumers want to assess whether to trust a promoter or not (4.3.4)  <ins> Consumers and other stakeholders in the system wants to verify the claims made by a software supplier by recreating the build environment to ascertain that the delivered binary is precisely the same one as claimed by the supplier </ins>
Original text:
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>  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

Reviewer comments:
NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements

Revised text:
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.,  <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
Original text:
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>  capabilities to process and evaluate all kinds of different authenticity proofs that come with a released software.

Reviewer comments:
NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements

Revised text:
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  <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.
Original text:
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>  Personal health monitoring devices, i.e., eHealth devices, are generally battery driven and offer health telemetry monitoring, such

Reviewer comments:
NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements

Revised text:
3.7.1.  <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
Original text:
also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing installation. <del> 3.7.2.1. Even with a robust firmware update system, the following problems remain as given below: </del>  How does the client applying the firmware update on the system know that the received firmware is not faulty or malicious?

Reviewer comments:
NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements

Revised text:
also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing installation.  <ins> The various stake holders of a firmware update system wants to ascertain: </ins> How does the client applying the firmware update on the system know that the received firmware is not faulty or malicious?
Original text:
Consumers want to assess whether to trust a promoter or not (4.3.4) <del> To be continued... </del> 

Reviewer comments:
NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements

Revised text:
Consumers want to assess whether to trust a promoter or not (4.3.4)  <ins> Consumers and other stakeholders in the system wants to verify the claims made by a software supplier by recreating the build environment to ascertain that the delivered binary is precisely the same one as claimed by the supplier </ins>
Original text:
There is no standardized way to: enable the consumer to verify that software originated from a <del> 'duly authorized signing party' on behalf of the Supplier. </del>  3.2.

Reviewer comments:
Addressing issue and
This fixes issue and issue
Please add "and is still valid" - see new proposed langauge enable the consumer to verify that software originated from a 'duly authorized signing party' on behalf of the Supplier, and is still valid
+1 to this change
Closing as been addressed now!
I have no concerns with the revised language for 3.1. One minor nit on 3.2 to be consistent with the use case title REPLACE: A consumer of released software component wants: WITH A consumer of released software product wants:
LGTM
This issue has been resolved in the above PR.
LGTM

Revised text:
There is no standardized way to: enable the consumer to verify that software originated from a  <ins> 'duly authorized signing party' on behalf of the supplier and is still valid. </ins> 3.2.