Giters

in-toto / apt-transport-in-toto

in-toto transport for apt

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Default layout, layout key and configuration

lukpueh opened this issue · comments

commented

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?
commented

Dropping my two cents here:

Is it okay to have one layout for all packages? And is above layout suited?

I think this is proper for now. I'll drop some blurb on in-toto/in-toto#247 regarding this.

Who should sign the layout?

I would love if any of the debian reproducible builds people did. Better yet, why not have a 2/3 threshold with them.

How does the user get/update a layout?

I believe the layout should be part of the apt transport package itself and updated with it. We can move to a separate package later down the line

When should the layout expire?

Let's set the expiration to two years

How does the client get the layout signing public keys (root of trust)?

These keys should belong to debian developers, so why not use the debian gpg keyring that's already bootstrapped in the client system?

What parts of the layout can the client override?
Authorized rebuilders?

I'd say their location only. Not the trust aspect to it.

Rebuilder threshold?

We could do so, although it's early to think about it.

How should the client override the layout?
By signing the layout with a key known to the client?
Using layout parameter substitution?

Let's keep this in a separate issue. For now i think this should be handled with lsigning a key in the debian keyring and handling it appropriately (i.e., having the config file set to be signed by the lsigned key).

Let's not open this can of worms just yet though.

What do you think?

commented

I appreciate your two cents, @SantiagoTorres, and it all sounds reasonable.

Not sure, though, if I understand the last part about "... lsigning a key in the debian keyring and handling it appropriately (i.e., having the config file set to be signed by the lsigned key)." But yes, we can have that discussion elsewhere.

My plan of action here would then be to:

  • add an unsigned root layout as described above to this repo,
  • make a note either in the README or in an issue that this root layout needs to be signed with Debian keys (probably in downstream),
  • update README to mention that this root layout should be used on for verification,
  • (maybe also rename the test layouts to avoid confusion).

What do you think?

commented

Not sure, though, if I understand the last part about "... lsigning a key in the debian keyring and handling it appropriately (i.e., having the config file set to be signed by the lsigned key)." But yes, we can have that discussion elsewhere.

It is possible to locally add and sign a key to your debian keyring iirc. That'd mean that you basically add a trusted key that you can use to verify custom layouts.

My plan of action here would then be to:
Yes,this all sounds very reasonable.

We should also set the default gnupg keyring to be debians's apt-key trusted fragments (we may have to tinker a little with this, but they are stored in /etc/apt/trusted.gpg.d