jiebi/CodeConvo huggingface dataset:
Code change:
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!

Related discussion:
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> <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
Code change:
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!

Related discussion:
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
Code change:
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!

Related discussion:
text: 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.
Code change:
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!

Related discussion:
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> <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
Code change:
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!

Related discussion:
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> <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?
Code change:
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!

Related discussion:
text: Consumers want to assess whether to trust a promoter or not (4.3.4) <del> To be continued... </del> <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>
Code change:
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

Related discussion:
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> <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
Code change:
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

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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
Code change:
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

Related discussion:
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> <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?
Code change:
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

Related discussion:
text: Consumers want to assess whether to trust a promoter or not (4.3.4) <del> To be continued... </del> <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>
Code change:
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

Related discussion:
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> <ins> 'duly authorized signing party' on behalf of the supplier and is still valid. </ins> 3.2.
Code change:
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

Related discussion:
text: identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product. <del> A consumer of released software component wants: </del> <ins> A consumer of released software product wants: </ins> to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf
Code change:
Updated firmware and Software integrator use case to the same format as the ones above.
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.

Related discussion:
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> <ins> 'duly authorized signing party' on behalf of the supplier, and is still valid. </ins> 3.2.
Code change:
Updated firmware and Software integrator use case to the same format as the ones above.
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.

Related discussion:
text: identity of the authoritaitve bodies adds a significant cost to the end user or consumer of the product. <del> A consumer of released software component wants: </del> <ins> A consumer of released software product wants: </ins> to offload the burden of identifying all relevant authoritative entities to an entity who does it on their behalf
Code change:
Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!

Related discussion:
text: assessments.  There is no assurance that all the bodies may be aware of statements from other authoritative entities or actively acknowledge them.  Discovery of all sources of such reports and/or <del> identity of the authoritaitve bodies adds a significant cost to the </del> <ins> identity of the authoritative bodies adds a significant cost to the </ins> end user or consumer of the product. A consumer of released software product wants:
Code change:
Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!

Related discussion:
text: security analysis tools on the same product.  The intention is to identify any security weaknesses or vulnerabilities in the package. <del> Initially a particluar analysis can identify itself as a simple </del> <ins> Initially a particular analysis can identify itself as a simple </ins> 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
Code change:
Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!

Related discussion:
text: allow for application in constrained node environments a simple and low cost way to update the configuration of a system <del> component in charge of validity or authenticity cecking </del> <ins> component in charge of validity or authenticity checking </ins> There is no standardized way to: