Re: [open-regulatory-compliance] Kicking off the CRA Attestations projec

[Elizabeth Mattijsen <eclipse@xxxxxx>]

> On 29 Oct 2025, at 21:48, Salve J. Nilsen via open-regulatory-compliance <open-My recommendation is that an attestation is bound to the following
> conditions:
> 
> 0. A list of assurances, like the ones listed above…
> 1. …Related to a specific component, named and uniquely identified
> 2. …limited to a single specific versioned release of said component
> 3. …limited in duration, depending on the Maintainer's resources
> 4. …Addressed to the requesting Manufacturer, named and uniquely ID'd
> 5. …Signed and attested by the entities offering the assurance
> 6. …Verifiable by the Manufacturer, Market Authorities and other Auditors

I can't help but think that it should also be limited to an OS type and version.
A component may be free of issues on e.g. Linux and MacOS, but may have known issues on Windows (in general, or with a specific version range).  It would be a pity if a component could not be attested for because of issues on a specific OS.

One alternative could be to consider a component bound to an OS.  And thus e.g. have 3 components (one for Linux, one for MacOS and one for Windows) that just happen to share the same codebase.  Which feels hacky to me.

The other alternative being not supporting that specific OS at all.  Which in the long run may hurt the component's existence long-term.


> On the Maintainer's side of the Steward, I think it's necessary to assume
> the Steward has NO LEVERAGE over the Maintainer's project, other than any
> terms they come to agreement with. By default, I believe it's best to
> assume the absolute minimum, as to avoid undue (and unpaid) impositions on
> the Maintainer.

Indeed.


Elizabeth Mattijsen