in-toto / apt-transport-in-toto

in-toto transport for apt

in-toto

in-toto provides a framework to protect the integrity of the software supply chain. It does so by verifying that each task in the chain is carried out as planned, by authorized personnel only, and that the product is not tampered with in transit.

in-toto requires a project owner to create a layout. A layout lists the sequence of steps of the software supply chain, and the functionaries authorized to perform these steps. When a functionary performs a step in-toto gathers information about the used command and the related files and stores it in a link metadata file. As a consequence link files provide the required evidence to establish a continuous chain that can be validated against the steps defined in the layout.

The layout, signed by the project owners, together with the links, signed by the designated functionaries, are released as part of the final product, and can be validated manually or via automated tooling in, e.g. a package manager.

Getting Started

Installation

in-toto is available on PyPI and can be installed via pip. See in-toto.readthedocs.io to learn about system dependencies and installation alternatives and recommendations.

pip install in-toto

Create layout, run supply chain steps and verify final product

Layout

The in-toto software supply chain layout consists of the following parts:

• expiration date
• readme (an optional description of the supply chain)
• functionary keys (public keys, used to verify link metadata signatures)
• signatures (one or more layout signatures created with the project owner key(s))
• software supply chain steps correspond to steps carried out by a functionary as part of the software supply chain. The steps defined in the layout list the functionaries who are authorized to carry out the step (by key id). Steps require a unique name to associate them (upon verification) with link metadata that is created when a functionary carries out the step using the in-toto tools. Additionally, steps must have material and product rules which define the files a step is supposed to operate on. Material and product rules are described in the section below.
• inspections define commands to be run during the verification process and can also list material and product rules.

Take a look at the demo layout creation example for further information on how to create an in-toto layout.

Artifact Rules

A software supply chain usually operates on a set of files, such as source code, executables, packages, or the like. in-toto calls these files artifacts. A material is an artifact that will be used when a step or inspection is carried out. Likewise, a product is an artifact that results from carrying out a step.

The in-toto layout provides a simple rule language to authorize or enforce the artifacts of a step and to chain them together. This adds the following guarantees for any given step or inspection:

• Only artifacts authorized by the project owner are created, modified or deleted,
• each defined creation, modification or deletion is enforced, and also
• restricted to the scope of its definition, which chains subsequent steps and inspections together.

Note that it is up to you to properly secure your supply chain, by authorizing, enforcing and chaining materials and products using any and usually multiple of the following rules:

• CREATE <pattern>
• DELETE <pattern>
• MODIFY <pattern>
• ALLOW <pattern>
• DISALLOW <pattern>
• REQUIRE <file>
• MATCH <pattern> [IN <source-path-prefix>] WITH (MATERIALS|PRODUCTS) [IN <destination-path-prefix>] FROM <step>

Rule arguments specified as <pattern> allow for Unix shell-style wildcards as implemented by Python's fnmatch.

in-toto's Artifact Rules, by default, allow artifacts to exist if they are not explicitly disallowed. As such, a DISALLOW * invocation is recommended as the final rule for most step definitions. To learn more about the different rule types, their guarantees and how they are applied, take a look at the Artifact Rules section of the in-toto specification.

Carrying out software supply chain steps

in-toto-run

in-toto-run is used to execute a step in the software supply chain. This can be anything relevant to the project such as tagging a release with git, running a test, or building a binary. The relevant step name and command are passed as arguments, along with materials, which are files required for that step's command to execute, and products which are files expected as a result of the execution of that command. These, and other relevant details pertaining to the step are stored in a link file, which is signed using the functionary's key.

If materials are not passed to the command, the link file generated just doesn't record them. Similarly, if the execution of a command via in-toto-run doesn't result in any products, they're not recorded in the link file. Any files that are modified or used in any way during the execution of the command are not recorded in the link file unless explicitly passed as artifacts. Conversely, any materials or products passed to the command are recorded in the link file even if they're not part of the execution of the command.

See this simple usage example from the demo application for more details. For a detailed list of all the command line arguments, run in-toto-run --help or look at the online documentation.

in-toto-record

in-toto-record works similar to in-toto-run but can be used for multi-part software supply chain steps, i.e. steps that are not carried out by a single command. Use in-toto-record start ... to create a preliminary link file that only records the materials, then run the commands of that step or edit files manually and finally use in-toto-record stop ... to record the products and generate the actual link metadata file. For a detailed list of all command line arguments and their usage, run in-toto-record start --help or in-toto-record stop --help, or look at the online documentation.

Release final product

In order to verify the final product with in-toto, the verifier must have access to the layout, the *.link files, and the project owner's public key(s).

Verification

Use in-toto-verify on the final product to verify that

• the layout was signed with the project owner's private key(s),
• has not expired,
• each step was performed and signed by the authorized functionary,
• the functionaries used the commands, they were supposed to use,
• materials and products of each step were in place as defined by the rules, and
• run the defined inspections

For a detailed list of all command line arguments and their usage, run in-toto-verify --help or look at the online documentation.

Signatures

in-toto-sign is a metadata signature helper tool to add, replace, and verify signatures within in-toto Link or Layout metadata, with options to:

• replace (default) or add signature(s), with layout metadata able to be signed by multiple keys at once while link metadata can only be signed by one key at a time
• write signed metadata to a specified path (if no output path is specified, layout metadata is written to the path of the input file while link metadata is written to <name>.<keyid prefix>.link)
• verify signatures

This tool serves well to re-sign test and demo data. For example, it can be used if metadata formats or signing routines change.

For a detailed list of all command line arguments and their usage, run in-toto-sign --help or look at the online documentation.

in-toto demo

You can try in-toto by running the demo application. The demo basically outlines three users viz., Alice (project owner), Bob (functionary) and Carl (functionary) and how in-toto helps to specify a project layout and verify that the layout has been followed in a correct manner.

Specification

You can read more about how in-toto works by taking a look at the specification.

Security Issues and Bugs

See SECURITY.md.

Governance and Contributing

For information about in-toto's governance and contributing guidelines, see GOVERNANCE.md and CONTRIBUTING.md.

Acknowledgments

This project is managed by Prof. Santiago Torres-Arias at Purdue University. It is worked on by many folks in academia and industry, including members of the Secure Systems Lab at NYU and the NJIT Cybersecurity Research Center.

This research was supported by the Defense Advanced Research Projects Agency (DARPA), the Air Force Research Laboratory (AFRL), and the US National Science Foundation (NSF). Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of DARPA, AFRL, and NSF. The United States Government is authorized to reproduce and distribute reprints notwithstanding any copyright notice herein.

apt-transport-in-toto's Issues

debian/control: Vcs-Git outdated? debian branch not updated?

Either the debian branch is not updated, or the Vcs-Git entry in debian/control needs the "-b debian" part removed.

Explore possibility of splitting current /sources into /source and /binary

Topic: Explore the possibility of replacing current /sources used by the transport into /source and /binary in order to distinguish between source package name and produced binary package names. It would have the advantage to also be consistent with current Debian snapshot API having start point /mr/package/... (well not source) and /mr/binary/... (see comment #28 (comment)). From the user point of view, it helps in understanding what exactly we are looking for and which (built) package. From rebuilder software point of view, it makes referring/linking produced in-toto metadata to all binary packages.

Original description: I'm trying to understand how originally debian-rebuilder-setup was intended to work. From what I can see, a rebuilder is supposed to POST to visualizer (https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/-/blob/master/builder/srebuild#L454) an in-toto metadata referenced by part of the name of buildinfo file (https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/-/blob/master/visualizer/accumulator.py#L69), mostly the source package name right? My question is how is supposed to be referenced for example mypackage-dev or any other packages built from a given sources mypackage.buildinfo?

HTTPS support

Description of issue or feature request:

Make it possible to use HTTPS to access the actual apt repository.
Currently enabling intoto is by changing sources.list entry, for example:
from: deb https://deb.debian.org/debian bullseye main
to: deb intoto://deb.debian.org/debian bullseye main

Current behavior:

When enabling intoto this way, deb.debian.org is accessed via HTTP, not HTTPS.

Expected behavior:

A way to specify whether the repository should use HTTP or HTTPS. Maybe "intotos" symlink to "intoto", similar to "https" -> "http" symlink (plus, obviously appropriate handling in intoto.py)?

Define configuration format and required parameters

Description of feature request:
The apt in-toto transport should be configurable via an apt configuration file (see apt.conf(5)) in a suitably named file that remains in /etc/apt/apt.conf.d/, e.g. /etc/apt/apt.conf.d/intoto.

Current behavior:
In the general message flow between apt and an apt transport, apt responds to the first message from the transport (i.e. 100 Capabilities) with a 601 Configuration message containing all the individual Config-Item's read from apt configuration files (see above) on separate lines.

601 Configuration
Config-Item: APT::Architecture=amd64
Config-Item: APT::Build-Essential::=build-essential
... [further config items]

Which, when parsed using the in-toto deserialize_one function, looks like:

{
'info': 'Configuration', 
'fields': [
  ('Config-Item', 'APT::Architecture=amd64'), 
  ('Config-Item', 'APT::Build-Essential::=build-essential'), 
  ...], 
'code': 601
}

Expected behavior:
We need to define required (and optional) configuration parameters in order to perform in-toto verification. Any related configuration parameter may be prefixed with APT::intoto::. Note that parameters don't need to have unique names (or values). At least the following information should be configurable:

• URIs of available rebuilders
• Location of local root layout
• Keyids of root layout gpg keys, which must be present in a local keychain
• A path to a non-default gpg keychain, to load root layout public keys from (optional)

These parameters may be parsed and used in a suitable manner during the apt <-> transport message flow (see comments in the intoto.handle function for more details).

root.layout signature has expired

Description of issue or feature request:
The signature for /data/root.layout has expired:

"expires": "2021-01-06T18:30:57Z",

I have not checked much further, but i expect this means apt-transport-in-toto will now fail to do anything useful, as it can't trust its root layout.

Current behaviour:
Untested, but probably prevents apt-transport-in-tot from doing its job.

Expected behaviour:
The root.layout file should have a signature which has an expiry date in the future.

One of the default rebuilders is offline (https://reproducible-builds.engineering.nyu.edu/)

Description of issue or feature request:
The default apt configuration file (installed at /etc/apt/apt.conf.d/intoto) uses two rebuilders:

  Rebuilders {
    "http://158.39.77.214";
    "https://reproducible-builds.engineering.nyu.edu";
  };

One of these two rebuilders, https://reproducible-builds.engineering.nyu.edu/, appears to be offline.

Current behaviour:
/etc/apt/apt.conf.d/intoto should points to an offline rebuilder, leaving only one rebuilder to compare with, which a very small set.

Expected behaviour:
/etc/apt/apt.conf.d/intoto should point to active rebuilders, and have more than 1.

Small extra note
I believe it's customary to add a priority number on an apt.conf.d file, to provide apt information as to when to run / how important a configuration file is. Currently, the in-toto apt.conf.d file is just named /etc/apt.conf.d/intoto which isn't ideal.

Improve apt-transport stdout

I fill this issue as a TODO. When fetching in-toto metadata of a unreproducible package, the APT output looks not very user friendly:

$ apt reinstall bash
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  bash-doc
The following packages will be upgraded:
  bash
1 upgraded, 0 newly installed, 0 to remove and 620 not upgraded.
Need to get 1,417 kB of archives.
After this operation, 1,024 B of additional disk space will be used.
Get:1 intoto://ftp.fr.debian.org/debian bullseye/main amd64 bash amd64 5.1-2+b1 [1,417 kB]
80% [1 bash 1,417 kB]Prepare in-toto verification for '/var/cache/apt/archives/partial/bash_5.1-2+b1_amd64.deb'
Create verification directory '/tmp/tmpcdvpjfuz'
Request in-toto metadata from 2 rebuilder(s) (apt config)
Request in-toto metadata from https://debian.notset.fr/rebuild/sources/bash/5.1-2+b1/metadata
Successfully downloaded in-toto metadata 'rebuild.8deb0bef.link' from rebuilder 'https://debian.notset.fr/rebuild/'
Request in-toto metadata from https://qubes.notset.fr/rebuild/deb/r4.1/vm/sources/bash/5.1-2+b1/metadata
Could not retrieve in-toto metadata from rebuilder 'https://qubes.notset.fr/rebuild/deb/r4.1/vm/', reason was: server response: 404
Copy final product to verification directory
Load in-toto layout '/var/lib/intoto/root.layout' (apt config)
Load in-toto layout key(s) '['9fa64b92f95e706bf28e2ca6484010b5cdc576e2']' (apt config)
Use gpg keyring '/var/lib/intoto/gnupg' (apt config)
Run in-toto verification
In-toto verification for '/var/cache/apt/archives/partial/bash_5.1-2+b1_amd64.deb' failed, reason was: 'DISALLOW *.deb' matched the following artifacts: ['bash_5.1-2+b1_amd64.deb']
Full trace for 'expected_materials' of item 'verify-reprobuilds':
Available materials (used for queue):
['bash_5.1-2+b1_amd64.deb']
Available products:
['bash_5.1-2+b1_amd64.deb']
Queue after 'MATCH *.deb WITH PRODUCTS FROM rebuild':
['bash_5.1-2+b1_amd64.deb']

Err:1 intoto://ftp.fr.debian.org/debian bullseye/main amd64 bash amd64 5.1-2+b1
  In-toto verification for '/var/cache/apt/archives/partial/bash_5.1-2+b1_amd64.deb' failed, reason was: 'DISALLOW *.deb' matched the following artifacts: ['bash_5.1-2+b1_amd64.deb']\nFull trace for 'expected_materials' of item 'verify-reprobuilds':\nAvailable materials (used for queue):\n['bash_5.1-2+b1_amd64.deb']\nAvailable products:\n['bash_5.1-2+b1_amd64.deb']\nQueue after 'MATCH *.deb WITH PRODUCTS FROM rebuild':\n['bash_5.1-2+b1_amd64.deb']\n
E: Failed to fetch intoto://ftp.fr.debian.org/debian/pool/main/b/bash/bash_5.1-2+b1_amd64.deb  In-toto verification for '/var/cache/apt/archives/partial/bash_5.1-2+b1_amd64.deb' failed, reason was: 'DISALLOW *.deb' matched the following artifacts: ['bash_5.1-2+b1_amd64.deb']\nFull trace for 'expected_materials' of item 'verify-reprobuilds':\nAvailable materials (used for queue):\n['bash_5.1-2+b1_amd64.deb']\nAvailable products:\n['bash_5.1-2+b1_amd64.deb']\nQueue after 'MATCH *.deb WITH PRODUCTS FROM rebuild':\n['bash_5.1-2+b1_amd64.deb']\n
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

The configuration and root.layout used can be found in https://github.com/fepitre/package-rebuilder#configure-apt-transport-in-toto. For this package bash the corresponding rebuild log shows that checksums comparison failed with the original. The produced metadata can be found in https://debian.notset.fr/rebuild/sources/bash/5.1-2%2Bb1/.

We would need to figure out the best way to present failing in-toto test with respect to a fail because of no metadata at all like e.g.:

In-toto verification for '/var/cache/apt/archives/partial/mc_3%3a4.8.26-1_amd64.deb' failed, reason was: Step 'rebuild' requires '1' link metadata file(s), found '0'.

Unrelated remark: we have made a policy choice to not fail on checksums verification because that would help user to identify a package being unreproducible/having possibly an issue.

Collection of resources

in-toto reproducible builds resources

• reproducible-builds.engineering.nyu.edu rebuilder for debian packages, creating in-toto link metadata
• debian-rebuilder-setup source code for rebuilder
• buildinfo.debian.net hosts buildinfo files for debian packages
• lamby/buildinfo.debian.net#54 "implements an endpoint returning a list of buildinfo files since a given date given in Unix time."
• buildinfo.nyu.wtf mirror of buildinfo.debian.net including above PR

apt resources

• Debian package management
• Debian builtin transport methods (source)

apt transports resources

• APT method interface for building transports
• lucidsoftware/apt-boto-s3 "The fast and simple S3 transport for apt. Access S3-hosted apt repositories via the AWS APIs."
• APT transport for S3 Blogpost from apt-boto-s3 author

Provide nofail configuration option

Description of issue or feature request:
Successful in-toto verification and thus package installation using apt and the intoto transport depends on a configured threshold of rebuilders providing valid in-toto link metadata that attests for the reproducibility of the package to be installed, as well as for its dependencies.

As of today there are two publicly accessible rebuilders that provide such link metadata for small and mostly different subsets of all debian packages [1], [2].

As a consequence it is not possible at the moment to install a debian package when using the intoto transport. For a slow roll-out, the client should be able to use the intoto transport with a nofail policy.

That policy should then be updated to a more restrictive policy, once there is broader support for rebuilder link metadata.

[1] https://reproducible-builds.engineering.nyu.edu/sources
[2] http://158.39.77.214/sources

Current behavior:
Installation fails if in-toto verification for a package to be installed, or for any of its dependencies, fails, e.g. if not enough link metadata can be found.

Expected behavior:
Allow the client to configure a "nofail" option, to install packages even if in-toto verification fails. For the foreseeable future this configuration might also be a default.

"nofail" may be applicable to certain in-toto verification failure reasons only. To address above issue, I suggest to only not fail on LinkNotFoundError if the "nofail" option is set.

Add automated testing (CI/CD)

Description of issue or feature request:
Add setup for automated testing of offline tests (see #9)

Current behavior:
No automated testing

Expected behavior:
Configure tox, coverage, pylint, Travis CI and coveralls.io

Vagrant still in debian/control:Uploaders

While I appreciate the honorable mention, it appears that I'm still listed in debian/control Uploaders field, despite debian/changelog mentioning removing me from Uploaders. Appears to be the same in both the "develop" and "debian" branches.

Unfortunately I haven't had much chance to help with apt-transport-in-toto, so probably worth making Uploaders reflect that actuality.

Thanks for apt-transport-in-toto, maybe someday I'll be able to contribute more meaningfully. :)

live well,
vagrant

Default layout, layout key and configuration

The following files must be available on a client that uses the in-toto apt transport:

Layout
An example layout can be found in tests/data/root.layout it has one step, i.e. rebuild. That step's pubkeys field lists the authorized rebuilders' signing keyids, and the threshold field specifies the number of authorized rebuilders required to provide signed link metadata for rebuilding. An example rebuild link metadata file can be found in tests/data/rebuild.5863835e.link.

In addition the layout defines one dummy inspection, to associate the package to be installed with the product hash of the rebuild step (see in-toto/specification#27 for a discussion about dummy inspections).

Layout key
The layout's signing key(s) are the root of trust and the in-toto apt transport requires the corresponding public key(s) to be available in a local gpg keyring on the client.

NOTE: Above test layout is signed with a test private key that is publicly available in this repo tests/gpg_keyring and thus not secret.

Configuration file
An example layout can be found in apt.conf.d/intoto. It contains the following parameters:

• Rebuilders Location of remote rebuilders
• Layout Location of local root layout
• Keyids Keyid(s) of layout public keys
• LogLevel (optional) Configures verbosity of in-toto apt transport
• GPGHomedir (optional) Path to non-default gpg keyring
• Nofail (see #12)

---

Questions for discussion

• Is it okay to have one layout for all packages? And is above layout suited?
• Who should sign the layout?
• How does the user get/update a layout?
• When should the layout expire?
• How does the client get the layout signing public keys (root of trust)?
• What parts of the layout can the client override?
  • Authorized rebuilders?
  • Rebuilder threshold?
• How should the client override the layout?
  • By signing the layout with a key known to the client?
  • Using layout parameter substitution?

Update `README.md`

Description of issue or feature request:
Update README to fit current state of code and enhance installation and usage instructions.
Address this issue in accordance with #13, #12 and #11.

Current behavior:
REAMDE is outdated and insufficient.

Expected behavior:
Updated and enhanced README.

`deserialize_one` attempts to parse `Message:`

Description of issue or feature request:
deserialize_one attempts to parse the Message: field in the test suite in develop during test_bad_target and fails to do so. Should be easy to replicate with tox -e py37

Current behavior:

message_str

Message: In-toto verification for '/home/fox/Git/prosjekter/master/apt-transport-in-toto/tests/data/bad/final-product_0.0.0.0-0_all.deb' failed, reason was: 'DISALLOW *.deb' matched the following artifacts: ['final-product_0.0.0.0-0_all.deb']
Full trace for 'expected_materials' of item 'verify-reprobuilds':
Available materials (used for queue):
['final-product_0.0.0.0-0_all.deb']
Available products:
['final-product_0.0.0.0-0_all.deb']
Queue after 'MATCH *.deb WITH PRODUCTS FROM rebuild':
['final-product_0.0.0.0-0_all.deb']

We are failing the check in the loop as the .splitlines() will provide lines with only one string.

    if len(header_field_parts) < 2:
      raise Exception("Invalid header field: {}, message was:\n{}"
          .format(line, message_str))

Traceback:

Traceback (most recent call last):
  File "/home/fox/Git/prosjekter/master/apt-transport-in-toto/tests/test_intoto.py", line 215, in test_bad_target
    acquire_args={"filename": FINAL_PRODUCT_PATH_BAD})
  File "/home/fox/Git/prosjekter/master/apt-transport-in-toto/tests/test_intoto.py", line 148, in mock_apt
    return intoto.deserialize_one(intoto.read_one(intoto_proc.stdout))
  File "/home/fox/Git/prosjekter/master/apt-transport-in-toto/intoto.py", line 334, in deserialize_one
    .format(line, message_str))
Exception: Invalid header field: ['final-product_0.0.0.0-0_all.deb'], message was:
400 URI Failure
Message: In-toto verification for '/home/fox/Git/prosjekter/master/apt-transport-in-toto/tests/data/bad/final-product_0.0.0.0-0_all.deb' failed, reason was: 'DISALLOW *.deb' matched the following artifacts: ['final-product_0.0.0.0-0_all.deb']
Full trace for 'expected_materials' of item 'verify-reprobuilds':
Available materials (used for queue):
['final-product_0.0.0.0-0_all.deb']
Available products:
['final-product_0.0.0.0-0_all.deb']
Queue after 'MATCH *.deb WITH PRODUCTS FROM rebuild':
['final-product_0.0.0.0-0_all.deb']

Expected behavior:
I'm a little bit unsure if the error is that we are unable to parse Message: or if the fact that we have in-toto failure messages in Message:.

Add more comprehensive tests that work with online and offline tests

Description of issue or feature request:
Restructure existing online and offline tests and add more comprehensive test scenarios that may be used for both.

Current behavior:
Currently there are two ways of testing the apt transport:

1. Online test using real remote rebuilders and real debian apt and apt http transport (see tests/Dockerfile)
2. Offline test that mocks rebuilders, apt and apt http transport (see tests/test_intoto.py)

Each currently performs one specific scenario of package installation using apt, which triggers in-toto verification with the proposed intoto transport.

Expected behavior:

• Add more comprehensive test cases, i.e. passing/failing in-toto verification (with different combinations of configuration values).

• Adapt online and (above all) offline test setup so that both can run the same test cases.

Add debian package support

Description of issue or feature request:
The intoto transport should be installable as debian package eventually, e.g. apt-get install apt-transport-intoto should make intoto.py available as executable in /usr/lib/apt/methods/intoto, and also install required metadata (default layout, layout key and configuration) to the right locations.

Note: The intoto transport depends on the in-toto package, which itself depends on the securesystemslib package, both of which are not yet available as debian packages. Ideally, these dependencies may also be installed as debian packages.

Current behavior:
No installation setup.

Expected behavior:
Provide installation setup.

Sign default root.layout and add keyid to default config

Description of issue or feature request:

During installation a default layout (data/root.layout) and config file (data/intoto.conf) are copied to the system.

The layout defines generic supply chain policies, i.e. any package must be rebuilt by n rebuilders, and the corresponding attestations must be signed with the keys authorized by the layout.

As root of trust for the supply chain verification, the layout itself must be signed by at least one key, which is available in the system key chain and the corresponding keyid(s) must be defined in the config file.

See #13 for more details.

Current behavior:
Default layout is not signed and default config authorizes a dummy keyid. As a consequence, in-toto verification performed by the transport will immediately fail, because the first step in the verification routine is checking the layout signature(s).

Note: regardless of the default layout, users can aways change the layout locally, sign it with their own key and specify the keyid in the config file accordingly.

Expected behavior:
Default layout is signed by at least one Debian maintainer and the corresponding keyid(s) are listed in the config file.

Support Python 2/3

Description of issue or feature request:
Modify all Python scripts of this repo intoto.py (transport) and test_intoto.py and serve_metadata.py (tests) to support Python in version 2 and 3.

FWIW, the intoto transport will usally be started from apt as executable, i.e. ./intoto, hence the Python interpreter specified in the first line (shebang) will be used. Since we don't specify an explicit version (see #!/usr/bin/env python) this will resolve to the default system Python, which, unless modified by the user, is Python2 (see Debian Python packaging manuals).

Current behavior:
Only supports Python2

Expected behavior:
From a quick check (using 2to3) the following packages have different names in Python2/Python3: Queue/queue, SocketServer/socketserver, SimpleHTTPServer/http.server, subprocess32 (requires external package)/subprocess.

Additionally, there is one call to dict.keys(), whose return value needs an explicit cast to list in Python3.