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.

Thanks,

James