--- tags: ietf-scitt --- ###### tags: `ietf-scitt` # SCITT: Artifact Versioning and Feeds ## Examples To support the [SCITT Use Cases][use-cases], the follow examples are illustrated. ## Integrating SCITT With a Build System Topics to cover: - [ ] How to structure SCITT Feeds - [ ] How to correlate each build artifact with previous versions - [ ] How to group a collection of artifacts (client/server, service1, 2, 3) - [ ] Where to store SCITT Receipts > Note: This example uses the [net-watcher][net-watcher] Github repository The [net-watcher][net-watcher] application serves multiple customer audiences through 2 supported versions across Windows and Linux servers. - **Version 1** - Supports on-premise networks - **Version 2** - Adds support for hosted cloud networks Both major versions, on both platform maintain support, including minor fixes and security patching. - Updates are not linear over time. A security patch `1.1.1` shipped after `2.2.0` had already shipped. - Not all users of Version `1.0.0` can move to the `2` release as some incompatibilities were introduced and features were added that require the customer to pay for the upgrade - A new `Version 3` has been started by the development team. **net-watcher - Linux** ``` Version 1.0.0 --> Version 1.1.0 --> Version 1.2.0 \ \ \ Version 1.1.1 --> Version 1.1.2 --> Version 1.0.1 --> Version 1.0.2... Version 2.0.0 --> Version 2.1.0 --> Version 2.2.0 \ Version 2.1.1 --> Version 2.1.2 --> Version 3-alpha --> ``` **net-watcher - Windows** ``` Version 1.0.0 --> Version 1.3.0 --> Version 1.4.0 \ \ Version 1.3.1 --> Version 1.3.2 Version 2.0.0 --> Version 2.1.0 \ Version 2.0.1 --> Version 2.0.2 --> Version 3-alpha --> ``` **[TODO]:** Add CalVer examples ### Questions - [ ] How does a producer declare version `1.1.0` supersedes `1.0.0` - [ ] How does a producer declare version `1.0.2` supersedes `1.0.1` and `1.0.0` - [ ] How does a producer make statements, unique to each version of the `net-watcher` product? - [ ] For each release, how does the development team structure their SCITT Feed? - [ ] How does a developer group a collection of like services? - [ ] Is each build/version a unique Feed? - [ ] Is there a way to make a continuous stream for a specific release? - [ ] Is the concept of version bands in scope for SCITT? - [ ] If not in scope, will the application platforms have to unique solve this for each? ### References - [calver.org](https://calver.org/) - [semver.org](https://semver.org/) [use-cases]: https://datatracker.ietf.org/doc/draft-ietf-scitt-software-use-cases/ [net-watcher]: https://github.com/wabbit-networks/net-watcher
Last changed by  
 
Steve Lasker
115

Read more

Notary Project Meeting Notes

TUF-notary meeting notes NOTE: Time Change - Starting May 9 2022, we will hold two meetings a a week to account for folks in the US, Europe and Asia times. Meetings are now: Mondays 5-6pm pacific time, 8-9pm US Eastern, 8-9am Shanghai (US Summer time) Mondays 4-5pm pacific time (US Winter time) Thursdays 9-10am pacific time, 12pm US Eastern, 5pm UK Links

5/1/2024
Veraison go-cose Community Meeting Notes

Bi-weekly on Fridays 8:00-9:00 pacific timeSee below for the next scheduled meeting and proposed agenda

3/8/2024
IETF 118 SCITT Hackathon

oras push https://ghcr.io/stevelasker/artifact:v1 –artifact-type application/vnd.acme.rocket.config artifact.txt:text/plain

11/4/2023
SCITT Feed Structure

Statements of Artifacts must support a narrowed scope.For each platform/architecture a series of compatible versions are released.For each version, a series of statements are made.Statements for a specific platform/architecture and version would not apply to another platform/architecture and version.Each variant MUST be treated uniquely.

8/14/2023
Read more from Steve Lasker
Published on HackMD