tests: Add sigstore-rs client test

[jku]

• This test is not in root-signing-staging since the client does not support staging
• Uses current main HEAD since last release does not have the "bundle" example we use
• Does not test signing since the client does not support signing with the GitHub Actions workflow identity

Testing this is an issue:

• as mentioned, we can't test this in staging
• Here the test currently fails because of key_id mismatch for root v11 #1431: sigstore-rs expects specifically computed TUF keyids which current root metadata does not provide.
• we can do a signing event to fix the keyid but can only test the result after the signing event is merged (but not necessarily published to production)

Setting as draft for now: let's figure out what we do with 1431.

[jku]

I think we could leave this after the repository has been fixed: theupdateframework/tuf-on-ci#536 should be enough to guaranteethat the signing event is good.

[jku]

Changes:

• rebased on sign/root-v12, set base to sign/root-v12: I'm proposing we merge this with the signing event to get immediate testing with sigstore-rs
• Switched to a branch of sigstore-rs that uses the v12 root as the embedded root (since v11 is incompatible): we should start using sigstore-rs release when possible

The idea here is that if everything works well, we get sigstore-rs tests running in the publishing pipeline. If something fails during publish, we can fix issues in the test workflow or even remove the sigstore-rs test if we decide so without redoing the signing event -- but we won't have another root update that breaks something without our knowledge.

[jku]

If something fails during publish, we can fix issues in the test workflow or even remove the sigstore-rs test if we decide so

I guess it's reasonable to mention why I said that: the workflow has never been tested because it can only possibly work after the next online signing. So there is a chance of bugs here.

[kommendorkapten]

Would your change need to be merged into upstream sigstore-rs after this so we can depend on that instead?

[jku]

Yes. I would expect

• root v12 change gets merged in sigstore-rs after we publish
• sigstore-rs makes a release
• we can start using the released sigstore-rs (maybe even via cargo and not actions checkout)

[kommendorkapten]

Lets try this out. The key id mismatch is the last known issue to me for sigstore-rs. Ans as it's quite complex to organize and test as @jku explains. This is the option with the fewest steps.