On Mon, 28 Mar 2011 12:35:07 -0000, Mattias Backman <email address hidden> wrote:
> Hi,
>
> To me it seems like the solution in #8 is near trivial after all. I've
> just had a quick look at this so let me know if I'm oversimplifying.
>
> > * Copy the apt trustdb in to the chroot before running hwpack-
> install. [...]
>
> Sounds trivial, assuming that it just involves copying
> /etc/apt/trustdb.gpg to chroot_dir/apt/trustdb.gpg at the top of
> install_hwpacks.
Yes, I think that's all it takes for this step. In addition, I think
that would be a useful thing to do anyway.
My only pause here would be that if we want to have extra keys for
hwpacks that aren't in the host system's trustdb we'll have to find some
way to combine them (two trustdbs, concatenating trustdbs, adding keys
later, or something)
I don't think that should stop us from making this simple change which
seems generally useful to me though.
We don't want to tie ourselves to using Debian-based systems as the host
any more than we already do, so make sure that it will still work if
there is no system trustdb.
> > * Ship PPA keys that we use a lot (overlay, kernel, PPAs) with
> linaro-image-tools. We could either load them in to the machines
> trustdb, or have a custom trustdb that we copy over as well. [...]
>
> Shipping separate keys would mean to just add them to the machines
> trustdb before the step above, I guess.
If we put them in the host system's trustdb, yes.
However, I'm not sure we would do that at runtime, we could have the
package do it at install time, as that would be quicker.
We could do it at runtime if we don't put them in the system
trustdb. This would likely be a loop of calls to
sudo chroot $chroot apt-key add
at the top of install_hwpacks too. This would work on more than
Debian-based systems.
I'm not sure this is quite obviously the win that the first item
is. This is the part where there are multiple proposed solutions.
If you'll allow me to outline the other proposal in similar depth to
this one then we can compare the two better.
* Sign the hwpacks
- This is just a matter of calling GPG when building really, as
offspring is already set up to use a key for signing results.
- We may want to put it behind an option
- We can choose to sign the hwpack internally or externally.
- Externally means downloading an extra file and passing that
extra file to l-m-c so that it can verify the signature.
- Internally means signing something inside the hwpack. We want to
sign the data that we are trusting. We could sign everything,
but that would likely need a new hwpack format. (e.g. nested
tarballs with the outer one containing a signature on the inner
one)
- I would argue that the files that are included are implicitly
trusted here, and we can provide external signatures if
someone wants to check that the hwpack did indeed come from
us.
- What we are specifically asserting is trusted here is a bunch
of GPG public keys. We can't control what they are used to
sign anyway, so it is merely an assertion that we believe
those keys will be used responsibly and only used to sign
archives that we can trust the packages from. Therefore I say
we need to sign the GPG public keys in some manner.
- Before we can design how to sign the GPG public keys we need to
decide how we will determine the list of GPG pubkeys to include,
and what format to store them in.
- In order to avoid network access at hwpack install time we want
to include the GPG public keys themselves.
- Therefore we need to get those keys at build time. We could
fetch them based on ids, or we could ask that they be included with
the configuration some how, or we could just implicitly grab
them from looking at what the archives that we build from are
signed with.
- Fetching based on ids is probably a good middle ground
here. It makes the keys explicit, but avoids having to
download them when you create/change a hwpack config, and
avoids us having to do gymnastics to find the key id that
signs each archive in the config and then fetch that key (if
someone knows how to do this then we could consider it.)
- It does assume that we have access to a keyserver that has
the public keys on it from the offspring build slaves
though.
- Once we have all the public keys we need to package them for
including in the hwpack. We could put them in a GPG keyring, but
I suspect that it's harder to manipulate them once they are in
that format (e.g. we would need to concatenate GPG keyrings when
installing hwpacks)
- Therefore I suggest we ship them as plain files, named for their
key id, in a directory in the hwpack.
- We ship a sha256sum of those files in the same dir, and then we
sign that file.
- When installing we then unpack the hwpack, look for that dir, if
it is present then we verify the signature, and then iterate
through the files listed in the sha256sum, and add each referenced
file to the trustdb (we can do this in the chroot, so it's just
apt-key add or similar.)
- If the signature doesn't verify, or any files referenced in the
sha256 are missing or similar then we bail.
- If there is no signature then we do nothing or bail? We could have
an option to trust unsigned here, but it's not very important.
- The final piece of the puzzle is then verifying the signature. We
could ship the public key we will use with linaro-image-tools, and
then use it to verify. If the person installs from a package then
there is a trust path to that key. If they install from bzr then
it is weaker, but I can live with that.
- I'm unsure how we verify, as we likely want to support multiple
signing keys for hwpacks. Do we just load them in to roots GPG
trustdb (not the apt trustdb) in the chroot and leave that up to
GPG?
As you can see this is a lot more complex than my proposed solution, but
it is the "correct" one in some sense.
What do other people think?
I can break it down in to changes we need to make once we have agreement
on the approach.
On Mon, 28 Mar 2011 12:35:07 -0000, Mattias Backman <email address hidden> wrote: trustdb. gpg to chroot_ dir/apt/ trustdb. gpg at the top of
> Hi,
>
> To me it seems like the solution in #8 is near trivial after all. I've
> just had a quick look at this so let me know if I'm oversimplifying.
>
> > * Copy the apt trustdb in to the chroot before running hwpack-
> install. [...]
>
> Sounds trivial, assuming that it just involves copying
> /etc/apt/
> install_hwpacks.
Yes, I think that's all it takes for this step. In addition, I think
that would be a useful thing to do anyway.
My only pause here would be that if we want to have extra keys for
hwpacks that aren't in the host system's trustdb we'll have to find some
way to combine them (two trustdbs, concatenating trustdbs, adding keys
later, or something)
I don't think that should stop us from making this simple change which
seems generally useful to me though.
We don't want to tie ourselves to using Debian-based systems as the host
any more than we already do, so make sure that it will still work if
there is no system trustdb.
> > * Ship PPA keys that we use a lot (overlay, kernel, PPAs) with
> linaro-image-tools. We could either load them in to the machines
> trustdb, or have a custom trustdb that we copy over as well. [...]
>
> Shipping separate keys would mean to just add them to the machines
> trustdb before the step above, I guess.
If we put them in the host system's trustdb, yes.
However, I'm not sure we would do that at runtime, we could have the
package do it at install time, as that would be quicker.
We could do it at runtime if we don't put them in the system
trustdb. This would likely be a loop of calls to
sudo chroot $chroot apt-key add
at the top of install_hwpacks too. This would work on more than
Debian-based systems.
I'm not sure this is quite obviously the win that the first item
is. This is the part where there are multiple proposed solutions.
If you'll allow me to outline the other proposal in similar depth to
this one then we can compare the two better.
* Sign the hwpacks
- This is just a matter of calling GPG when building really, as
offspring is already set up to use a key for signing results.
- We may want to put it behind an option
- We can choose to sign the hwpack internally or externally.
- Externally means downloading an extra file and passing that
extra file to l-m-c so that it can verify the signature.
- Internally means signing something inside the hwpack. We want to
sign the data that we are trusting. We could sign everything,
but that would likely need a new hwpack format. (e.g. nested
tarballs with the outer one containing a signature on the inner
one)
- I would argue that the files that are included are implicitly
trusted here, and we can provide external signatures if
someone wants to check that the hwpack did indeed come from
us.
- What we are specifically asserting is trusted here is a bunch
of GPG public keys. We can't control what they are used to
sign anyway, so it is merely an assertion that we believe
those keys will be used responsibly and only used to sign
archives that we can trust the packages from. Therefore I say
we need to sign the GPG public keys in some manner.
- Before we can design how to sign the GPG public keys we need to
decide how we will determine the list of GPG pubkeys to include,
and what format to store them in.
- In order to avoid network access at hwpack install time we want
to include the GPG public keys themselves.
- Therefore we need to get those keys at build time. We could
fetch them based on ids, or we could ask that they be included with
the configuration some how, or we could just implicitly grab
them from looking at what the archives that we build from are
signed with.
- Fetching based on ids is probably a good middle ground
here. It makes the keys explicit, but avoids having to
download them when you create/change a hwpack config, and
avoids us having to do gymnastics to find the key id that
signs each archive in the config and then fetch that key (if
someone knows how to do this then we could consider it.)
- It does assume that we have access to a keyserver that has
the public keys on it from the offspring build slaves
though.
- Once we have all the public keys we need to package them for
including in the hwpack. We could put them in a GPG keyring, but
I suspect that it's harder to manipulate them once they are in
that format (e.g. we would need to concatenate GPG keyrings when
installing hwpacks)
- Therefore I suggest we ship them as plain files, named for their
key id, in a directory in the hwpack.
- We ship a sha256sum of those files in the same dir, and then we
sign that file.
- When installing we then unpack the hwpack, look for that dir, if
it is present then we verify the signature, and then iterate
through the files listed in the sha256sum, and add each referenced
file to the trustdb (we can do this in the chroot, so it's just
apt-key add or similar.)
- If the signature doesn't verify, or any files referenced in the
sha256 are missing or similar then we bail.
- If there is no signature then we do nothing or bail? We could have
an option to trust unsigned here, but it's not very important.
- The final piece of the puzzle is then verifying the signature. We
could ship the public key we will use with linaro-image-tools, and
then use it to verify. If the person installs from a package then
there is a trust path to that key. If they install from bzr then
it is weaker, but I can live with that.
- I'm unsure how we verify, as we likely want to support multiple
signing keys for hwpacks. Do we just load them in to roots GPG
trustdb (not the apt trustdb) in the chroot and leave that up to
GPG?
As you can see this is a lot more complex than my proposed solution, but
it is the "correct" one in some sense.
What do other people think?
I can break it down in to changes we need to make once we have agreement
on the approach.
Thanks,
James