Parsec service 1.0.0 release

[ionut-arm]

Use this thread for discussions about the 1.0.0 release of the Parsec service, including:

• the planned content due to be released (see the associated milestone)
• the timeline of the release
• the status of the work feeding into the release

[ionut-arm]

This is the checklist to be followed in preparation for the 1.0.0 release.

Notification prior to code freeze

@puiterwijk, @nullr0ute, @ggardet - please be advised, the new Parsec service release will be available soon. Among the changes that might be of interest:

• we have added an SQLite key info manager using a bundled SQLite library
• the Parsec service systemd unit file has had some additions to help with system hardening

Date of the code freeze period

16th of February - TBD, no earlier than 2nd of March

During the code freeze period

• Pull in the latest git dependencies in the crates they are going to be used to make sure using the latest release would work
• Publish new versions of all managed crates. See this guide
• Execute the normal e2e tests on real hardware:
  • Nitrokey HSM
  • Raspberry Pi with TPM
  • Trusted Services on a supported board
• Execute fuzz testing for some time
• Ask the Linux distributions packagers to try the tagged version
• Ask the Parsec Yocto maintainers to try the tagged version
• Ask any interested people to try the tagged version
• Review the book and make sure all pages are up-to-date. In particular make sure the Threat Model is up to date.
• Make sure all the markdown pages (like the README) are looking good.
• Make sure the rustdoc pages (on docs.rs) are looking good (before and after the release).
• If there are any bugs reported, make new MINOR or PATCH tags (that would be 1.0.x for this release)
• When everything is OK (or at the end of the maximum code freeze time, one month), make a GitHub release out of the last tag which includes its changelog, ask maintainers to release this version of Parsec

After the release

• Close issues fixed in the release and the past milestone
• Make a new issue milestone for the next release
• Publish the new quickstart bundle and update the quickstart guide with it
• Update the Parsec Release Process with what we learnt
• Update the Parsec Tool demo
• Profit 🥂

[ggardet]

Will you release Beta/RC versions before 1.0.0?

[ionut-arm]

We will be in a code freeze with an RC tag until the checklist above gets all filled in, and then we can tag the actual release. Does that sound reasonable?

[ggardet]

Yes, if you tag an RC release, that's easier to tests for distros. Thanks.

[ionut-arm]

@nullr0ute - is there a requirement to align the bindgen versions across all of the crates that make use of it for FFI? We currently use 0.57.0 in some of the crates and 0.59.1 for others, but we could switch to 0.59.1 across the board if necessary

[nullr0ute]

Preferably aligned makes things more straight forward from my PoV

[ionut-arm]

First release candidate for the 1.0.0 release is up (tag here)!

cc @ggardet @nullr0ute

(NOTE: the tag will be moved to include the Changelog and version bump from this PR)

[ggardet]

1.0.0-rc1 builds properly on aarch64 and x86_64, but the build fails on armv7 with:

[  297s]    Compiling env_logger v0.8.4
[  298s] error[E0308]: mismatched types
[  298s]    --> /home/abuild/rpmbuild/BUILD/parsec-1.0.0-rc1/vendor/rust-cryptoauthlib/src/hw_impl/aes_gcm.rs:180:17
[  298s]     |
[  298s] 180 |                 iv.len() as u64,
[  298s]     |                 ^^^^^^^^^^^^^^^ expected `u32`, found `u64`
[  298s]     |
[  298s] help: you can convert a `u64` to a `u32` and panic if the converted value doesn't fit
[  298s]     |
[  298s] 180 |                 (iv.len() as u64).try_into().unwrap(),
[  298s]     |                 +               +++++++++++++++++++++
[  298s] 
[  298s] error[E0308]: mismatched types
[  298s]    --> /home/abuild/rpmbuild/BUILD/parsec-1.0.0-rc1/vendor/rust-cryptoauthlib/src/hw_impl/aes_gcm.rs:315:17
[  298s]     |
[  298s] 315 |                 tag_length as u64,
[  298s]     |                 ^^^^^^^^^^^^^^^^^ expected `u32`, found `u64`
[  298s]     |
[  298s] help: you can convert a `u64` to a `u32` and panic if the converted value doesn't fit
[  298s]     |
[  298s] 315 |                 (tag_length as u64).try_into().unwrap(),
[  298s]     |                 +                 +++++++++++++++++++++
[  298s] 
[  298s] error[E0308]: mismatched types
[  298s]    --> /home/abuild/rpmbuild/BUILD/parsec-1.0.0-rc1/vendor/rust-cryptoauthlib/src/hw_impl/aes_gcm.rs:348:17
[  298s]     |
[  298s] 348 |                 tag.len() as u64,
[  298s]     |                 ^^^^^^^^^^^^^^^^ expected `u32`, found `u64`
[  298s]     |
[  298s] help: you can convert a `u64` to a `u32` and panic if the converted value doesn't fit
[  298s]     |
[  298s] 348 |                 (tag.len() as u64).try_into().unwrap(),
[  298s]     |                 +                +++++++++++++++++++++
[  298s] 
[  298s] error[E0308]: mismatched types
[  298s]   --> /home/abuild/rpmbuild/BUILD/parsec-1.0.0-rc1/vendor/rust-cryptoauthlib/src/hw_impl/mac.rs:77:17
[  298s]    |
[  298s] 77 |                 data.len() as u64,
[  298s]    |                 ^^^^^^^^^^^^^^^^^ expected `u32`, found `u64`
[  298s]    |
[  298s] help: you can convert a `u64` to a `u32` and panic if the converted value doesn't fit
[  298s]    |
[  298s] 77 |                 (data.len() as u64).try_into().unwrap(),
[  298s]    |                 +                 +++++++++++++++++++++
[  298s] 
[  298s] For more information about this error, try `rustc --explain E0308`.
[  298s] error: could not compile `rust-cryptoauthlib` due to 4 previous errors
[  298s] warning: build failed, waiting for other jobs to finish...
[  423s] error: build failed
[  423s] error: Bad exit status from /var/tmp/rpm-tmp.q7UNfK (%build)

[ionut-arm]

Hi! Thanks for reporting. It seems to be related to the CryptoAuthLib provider, which relies on rust-cryptoauthlib - we have no control over that crate, and as far as I know it's currently unmaintained. We'll eventually sort that out in the long term, but the short-term solution is for us to remove that provider from the list of built features. I'll be removing it from all-providers for rc2.

So my suggestion is to simply remove the cryptoauthlib-provider from the features being built. Do you have a list of features to enable when building the service, or do you just build with all-providers? If using all-providers, you could replace it with the names of the others: tpm-provider,pkcs11-provider,mbed-crypto-provider,trusted-service-provider.

[ionut-arm]

I've just tagged a second release candidate - 1.0.0-rc2. There have been no changes to the actual code of the service, however the cryptoauthlib-provider has been removed from all-providers and the versions of some dependencies have been bumped following reports from cargo-audit.

You can see the full change here: #584 .

cc @ggardet @nullr0ute

[ionut-arm]

@puiterwijk - given the comment in parallaxsecond/rust-tss-esapi#332, would you strongly prefer we release tss-esapi with that fix in and make a new release candidate of Parsec to include that change?

[nullr0ute]

A 7.0.1 release would be useful for tss-esapi.

Also going through a bunch of pieces in the last day or so there's some discrepancies in picky crate requirements:
parsec:
picky-asn1 = { version = ">=0.3.1, <=0.3.1", optional = true }
picky-asn1-der = { version = "<=0.2.4", optional = true }
picky-asn1-x509 = { version = "0.4.0", optional = true }

parsec-tool:
picky-asn1 = "0.3.0"
picky-asn1-der = "0.2.4"
picky-asn1-x509 = "0.6.1"

I'm not sure what the conflicts are there but to have them aligned would make things more straight forward.

And also with parsec-tool there's a new dep of rcgen which if that could be provided by openssl functionality again that would make things more straight forward.

In general for audit for things like FIPS support if we can generally either rely on, or have an option of, using openssl it makes things a lot straight forward from an audit PoV for enterprise distributions in general.

[ggardet]

I've just tagged a second release candidate - 1.0.0-rc2. There have been no changes to the actual code of the service, however the cryptoauthlib-provider has been removed from all-providers and the versions of some dependencies have been bumped following reports from cargo-audit.

You can see the full change here: #584 .

cc @ggardet @nullr0ute

No regression found on 1.0.0-rc2

[ionut-arm]

Alright, I've tagged both a new service and a new Parsec tool version! This covers all those dependency mismatches/issues, including this regex vulnerability.

[ionut-arm]

Hi @ggardet, I was wondering what Rust compiler version is currently used for building packages. Looking at the logs from the Parsec package build it looks like 1.59 is used - is that correct? It would allow us to update some packages and change the version we use for testing!

[ggardet]

Hi @ggardet, I was wondering what Rust compiler version is currently used for building packages. Looking at the logs from the Parsec package build it looks like 1.59 is used - is that correct? It would allow us to update some packages and change the version we use for testing!

Currently, the following openSUSE distro are supported :

• openSUSE Tumbleweed : rust 1.59
• openSUSE Leap 15.4 Beta : rust 1.59
• openSUSE Leap 15.3 : rust 1.53

Leap 15.3 will be EOL at the end of November 2022.

[ionut-arm]

Release Candidate 3 has been tagged. It adds some updates to the service dependencies, including:

• tss-esapi to 7.0.1
• picky- crates to match the parsec-tool
• regex to 1.5.5 to avoid RUSTSEC-2022-0013

The full change can be seen here

cc @ggardet @nullr0ute

[ionut-arm]

Good question. There seems to be no plan at the moment to package the library necessary for the Trusted Services backend, we rely on Yocto builds (EDIT: rely for now :) ) for that sort of integration. Most sensible thing to do would be to not add in the TS provider for your builds.

[paulhowardarm]

It's not so much that we rely on Yocto. Rather it's that we are expecting Yocto to be the first place where all of these components are likely to land together. I certainly hope and expect that the TS userspace pieces will land in distros by some means in the future. However, for now I would agree that switching off the TS provider feature toggle is probably the best immediate approach.

[nullr0ute]

So where's the docs on these pieces and why are they hidden away in sub-modules rather than discrete components? ATM I have just disabled it but I've no idea what the functionality provides and whether it's useful for the PARSEC users.

[ionut-arm]

where's the docs on these pieces

That would be here, and also here

ATM I have just disabled it but I've no idea what the functionality provides and whether it's useful for the PARSEC users.

Where would you expect documentation or links to the documentation to these features? I'm thinking of adding more info on this, but I'm not sure where people would look first - the service README/the changelog/among the notification comments for a new version, above?

[ggardet]

Release Candidate 3 has been tagged. It adds some updates to the service dependencies, including:

I tested 1.0.0-rc3. No regression found.

[ionut-arm]

Hi all,

I have tagged and upstreamed the 1.0.0 version of the Parsec service! A Github Release will follow later today, followed by an updated quickstart package attached to that release in the next few days. Please let us know ASAP of any issues you encounter with this release.

cc @ggardet @nullr0ute

[ionut-arm]

@ggardet - is there any place where we can track the release status of the new package in openSUSE?

[ggardet]

Parsec 1.0.0 is in openSUSE Tumbleweed and will be in openSUSE Leap 15.4. No issue so far.

For openSUSE Tumbleweed, you can check the release repo: http://download.opensuse.org/tumbleweed/repo/oss/x86_64/
or the build project: https://build.opensuse.org/package/show/openSUSE:Factory/parsec

[ionut-arm]

Excellent, thank you very much for sorting that out!

Is there some process (e.g., tickets or issues raised somewhere) to suggest changes or updates to the packaging scripts so that we do that in a "centralised" manner?

[ggardet]

Excellent, thank you very much for sorting that out!

Is there some process (e.g., tickets or issues raised somewhere) to suggest changes or updates to the packaging scripts so that we do that in a "centralised" manner?

Not really. You can ping the maintainer (me) or create a ticket on https://bugzilla.opensuse.org if the update includes CVE fixes.
You can also branch the package in OBS and submit your changes. You just need to create an account.