Add debian metadata and fixes for 0.1.0 release

[lukpueh]

UPDATED ON 2021-01-25

Fixes issue #: closes #11

Description of the changes being introduced by the pull request:

• Adds debian metadata Above all, look at debian/apt-transport-in-toto.install, which installs the transport executable, and copies over a default config and a generic in-toto layout. The latter serves as root of trust, and specifies policies such as: any package must be rebuilt by <n> rebuilders, and the corresponding attestations (in-toto link metadata) must be signed with keys <xyz>. This layout is not yet signed.

  TODO: Sign data/root.layout with maintainer key and add corresponding gpg keyid to data/intoto.conf. Signing can be done by, e.g.

  sudo apt install in-toto
  wget https://raw.githubusercontent.com/in-toto/apt-transport-in-toto/debian/data/root.layout
  in-toto-sign --file root.layout --gpg <YOUR GPG KEYID>

• Fixes tests to run during Debian package build

  • To do so we had to change calls to the python interpreter in tests to python3 because the former is not available during a python3 only build.

  • Running tests during the Debian build also requires the test scripts to have a Debian-style shebang, i.e. #!/usr/bin/python3, which unfortunately breaks the virtualenv-based tox/travis builds.

    TODO: Fix tox/travis builds * --> fixed in #27

• Fixes a minor linter issue and the test coverage configuration

• Removes Python 2.7 builds from tox/travis (we don't build for Python 2) and instead adds 3.7 and 3.8

• Fixes a BrokenPipeError bug (see 91af874)

  TODO: The fix seems to work but might need revision (see commit message) --> reviewed in https://github.com/in-toto/apt-transport-in-toto/pull/27#issuecomment-766917790

• See #27 for further updates

The package built and tested with the changes of this PR can be found on: https://mentors.debian.net/package/apt-transport-in-toto

Please verify and check that the pull request fulfills the following requirements:

• [ ] The code follows the Code Style Guidelines
• [ ] Tests have been added for the bug fix or new feature
• [ ] Docs have been added for the bug fix or new feature

[lukpueh]

• Sign data/root.layout with maintainer key and add corresponding gpg keyid to data/intoto.conf.

.... is the only thing that's currently missing here. This means that in-toto reproducibility verification upon apt installation will fail always right away, because the first check in the verification routine is whether the layout is signed by at least one key.

However, users can still change the layout locally, sign it with their own key and specify the keyid in the config file accordingly, e.g. to experiment with other policies, etc.. I suppose that is what @fepitre did for qubes?

[h01ger]

I'm here ;)

[fepitre]

* Sign data/root.layout with maintainer key and add corresponding gpg keyid to data/intoto.conf.

.... is the only thing that's currently missing here. This means that in-toto reproducibility verification upon apt installation will fail always right away, because the first check in the verification routine is whether the layout is signed by at least one key.

However, users can still change the layout locally, sign it with their own key and specify the keyid in the config file accordingly, e.g. to experiment with other policies, etc.. I suppose that is what @fepitre did for qubes?

Yes this exactly what we did on a simple example. Currently the only way to have some working setup while installing the transport, would be to have Debian providing root.layout with a list of validated rebuilders and have it signed. We plan to do the same for Qubes once we have stable rebuilders.

[h01ger]

On Mon, Jan 25, 2021 at 08:52:17AM -0800, Frédéric Pierret wrote:

Yes this exactly what we did on a simple example. Currently the only way to have some working setup while installing the transport, would be to have Debian providing root.layout with a list of validated rebuilders and have it signed. We plan to do the same for Qubes once we have stable rebuilders.

i'd be delighted if we could make this happen during the bookworm cycle...

-- cheers, Holger

⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄

Our civilization is being sacrificed for the opportunity of a very small number of people to continue making enormous amounts of money... It is the sufferings of the many which pay for the luxuries of the few... You say you love your children above all else, and yet you are stealing their future in front of their very eyes... (Greta Thunberg)

[lukpueh]

On a second thought, I guess I'm also quite fine if we ship out the package with a layout that has no signature. The rebuilders whose keys it currently authorizes are rather experimental (one of them actually seems to be down at the moment). cc @SantiagoTorres

[lukpueh]

Just uploaded to mentors: https://mentors.debian.net/package/apt-transport-in-toto/

Apart from a few lintian errors it looks good. I can take care of these tomorrow. Need to sign off for today.

[fepitre]

Just uploaded to mentors: https://mentors.debian.net/package/apt-transport-in-toto/

Apart from a few lintian errors it looks good. I can take care of these tomorrow. Need to sign off for today.

Thank you for all. If you need help tomorrow, let me know.

[h01ger]

Lukas, please add me to this repo so I can push my signature on data/root.layout :-)

[h01ger]

however, with a new data/root.layout it will become a new version... so maybe I'll still upload what's on mentors today (if its good) and then/at the same time you create that new release and I can reupload that...

[marmarek]

Can I ask why root.layout needs a signature? Anyone who could modify it (have write access to that file) can also modify apt-transport-in-toto config to trust another key, so it doesn't seem to provide much added value. Am I missing something?

[fepitre]

Can I ask why root.layout needs a signature? Anyone who could modify it (have write access to that file) can also modify apt-transport-in-toto config to trust another key, so it doesn't seem to provide much added value. Am I missing something?

I guess it's useful to get it remotely?

[lukpueh]

Can I ask why root.layout needs a signature? Anyone who could modify it (have write access to that file) can also modify apt-transport-in-toto config to trust another key, so it doesn't seem to provide much added value. Am I missing something?

Very good question, @marmarek! The layout is the root of trust for in-toto. The underlying bootstrapping issue, that is why you should trust the root of trust, is out of scope for in-toto.

But the benefit of having signatures on the layout is that it limits the users responsibility to "auditing" the keyid(s) (are they trustworthy?) in the config file. If it weren't signed, the user would have to audit the entire layout file with its supply chain policies and rebuilder authorizations, etc.

Moreover, the signatures allow you to separate the trust in the layout from the trust in the package uploader. As @fepitre says, the layout could be shipped out independently, even in a separate package. https://github.com/in-toto/apt-transport-in-toto/issues/13 has some more infos about this.

This is probably something that should be discussed in the README.md and also made available in a man page or so.

[lukpueh]

Given that the tip of this PR is what's currently being processed on Debian FTP masters as 0.1.0, I'll just merge here and push a corresponding 0.1.0 tag on that merge commit. We can add lintian fixes and a signed layout in 0.1.1, which @fepitre is already preparing in #29. Let's continue there.