Closed lukpueh closed 5 years ago
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?
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:
What do you think?
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
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'spubkeys
field lists the authorized rebuilders' signing keyids, and thethreshold
field specifies the number of authorized rebuilders required to provide signed link metadata for rebuilding. An example rebuild link metadata file can be found intests/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 https://github.com/in-toto/docs/issues/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 rebuildersLayout
Location of local root layoutKeyids
Keyid(s) of layout public keysLogLevel
(optional) Configures verbosity of in-toto apt transportGPGHomedir
(optional) Path to non-default gpg keyringNofail
(see #12)Questions for discussion