Develop in-toto-rs capabilities to support rebuilderd

[adityasaky]

Description:

in-toto-rs was first created to enable the generation of in-toto link attestations in rebuilderd. However, in-toto-rs currently does not support the generation of signed link attestations. This functionality is provided via the runlib on the in-toto implementations written in Python and Go.

Current behaviour: in-toto-rs has no mechanisms for generating signed link attestations.

Expected behaviour: in-toto-rs provides a runlib that is equivalent to those found in other in-toto implementations, and which can be used by rebuilderd to generate in-toto link metadata.

[cutecutecat]

Hello!
I am a postgraduate student from Southern University of Science and Technology in China. I would be happy to join GSOC 2021 to work on this project. In the issue, I have some questions about the work.

I see at in_toto\runlib.py, the in_toto_record_start and such functions provided 3 method of signing: signing_key, gpg_signed and gpg_default.
That is

  if signing_key:
    LOG.info("Signing link metadata using passed key...")
    signature = link_metadata.sign(signing_key)

  elif gpg_keyid:
    LOG.info("Signing link metadata using passed GPG keyid...")
    signature = link_metadata.sign_gpg(gpg_keyid, gpg_home=gpg_home)

  else:  # (gpg_use_default)
    LOG.info("Signing link metadata using default GPG key ...")
    signature = link_metadata.sign_gpg(gpg_keyid=None, gpg_home=gpg_home)

In Rust version, we can use SignedMetadataBuilder.sign function inside metadata.rs to replace sign, but there is no such function about gpg? Should we implement them as well? Or leave them unimplemented?

Thank you for your reply!

[adityasaky]

Hi @cutecutecat! Nope, GPG support doesn't need to be implemented for GSOC. Maybe, and this is a big maybe, it can be a stretch goal, but certainly nothing to worry about to finish the requirements for this summer.

[adityasaky]

I think this can now be closed, thanks to #7. Great work, @joyliu-q!