Add --keyring and --fingerprint options

[josch]

Building on the work of #1 and #31 it is possible to further refactor the gpg verification code and add additional verification mechanisms other than using the python gpgme binding. With these changes, it is possible to pass a gpg keyring to bmaptool. So now I can instruct consumers of my disk images to run this:

bmaptool copy --keyring=/usr/share/keyrings/debian-keyring.gpg http://disk.img /dev/sda

And they will have the assurance that whatever they download, extract and copy to their disk was signed by the same gpg keys as their Debian OS. For even more paranoid people there is the --fingerprint option which forces the bmap file to be signed by the given fingerprint.

What do you think?

[josch]

Should bmaptool error out if the user supplied the --keyring or --fingerprint options but then bmaptool did not manage to discover a gpg signature? I think doing so would be a sane default, agreed?

[josch]

Hi @JPEWdev, while rebasing this pull request on top of main I found a couple of problems with how the key handling was tested. This should be fixed with 64f3b05 I think even if you do not like the --fingerprint and --keyring options, you should cherry-pick that commit into main.

I'm looking forward to your thoughts on the new --fingerprint and --keyring options.

[JPEWdev]

Would it make more sense to have an option to pass arbitrary arguments to gnupg instead of having to parrot and handle arguments for it?

It's been a while since I've used gnupg so idk if that makes sense

[josch]

This would mean that the user would have to pass different options depending on which verification backend they like to use. For gpg, they would have to add --homedir=... --no-default-keyring --keyring=... and for gpgv it would just be --keyring. I think the question is how much you want bmaptool in the business of doing the gpg check for the user. Because in principle, the user could also just download the bmap file, verify the gpg signature manually and then use bmaptool with it. But that would defeat the "quality of life" feature of bmaptool to "auto discover" and "auto download" bmap files, automating something that the user would have to do manually otherwise. Because if bmaptool is not supposed to do special magic with gpg and the user has to do it manually, then they can as well come up with the correct gpg arguments manually themselves as well. If on the other hand, you say that bmaptool is to do thing "automatically" for the user and should add some extra convenience, then i think it makes sense to add the smarts into bmaptool, abstracting away the extra knowlege the user would otherwise be required to have to do the verification themselves. My personal view point on that is, that the convenience features that bmaptool added over dd (auto-discovery, auto-download, auto-verification) are my main reasons for adding bmaptool support into my scripts. I'd like bmaptool to carry extra smarts to further go into that direction so that the user doesn't have to think about other things than "which keyring do i want" and "which fingerprint should it be signed with".

Another argument in favour of convenience (i.e.: let bmaptool do extra magic) is that currently only gpg and gpgv are supported but alternative gpg implementations exist now for many years and a number of important projects are switching away from gpg these days. For example, since last week, apt uses sqv instead of gpgv for verification. This means, that the next Debian releases and its derivatives like Ubuntu will no longer have gpgv installed but will come with sqv by default. I want to add sqv support to bmaptool as well, but that's another pull request. :)

Lastly, I personally become more and more frustrated with gpg and am welcoming the addition of alternative implementations. For example, I tried out the changes from bmaptool in the main branch as a Debian package and observed that now bmaptool fails to build as a Debian package. Why? It turns out that gpg-agent limits the socket path to 108 characters. This means that in a normal Debian build environment, gpg is not able to create a new key because it cannot connect to the gpg agent as the path to its socket is too long. Alternative implementations, like Stateless OpenPGP do not require a daemon process to run anymore to do key operations and do therefore not suffer from this issue. I'd like to add support for this.

In summary: I think it would be really nice if bmaptool would try to be as convenient as possible and abstract away the implementation details of gpg, gpgv, sqv (sequoia) or sopv (rpgp) and just do the right thing automatically depending on which gpg verification tool is installed.

(maybe slightly related to this is also the current mess surrounding the gpg schism which is happening with two different but conflicting gpg standards being developed independently from each other because they cannot agree on a common format )

[JPEWdev]

Ya, that makes sense. I think your point all make sense to me. I also agree that gpg has been frustrating lately, so I would not mind replacing it :)

I'm fine with this in principle, but @moto-timo and @twoerner should chime in if they have thoughts.

Between work and FOSSDEM coming up, it might be a while before I can review this

[josch]

Between work and FOSSDEM coming up, it might be a while before I can review this

Ah I nearly would've made it to Brussels this year but work got in the way. XD

I broke out the more important part of this pull request into its own pull request so that this can be discussed independently from the new commandline arguments for gpg keyring and fingerprint: #43

Enjoy FOSDEM! 😄

[josch]

Also, for others reviewing this, this is how bmaptool looks in practice with this change:

$ sudo bmaptool copy \
    --fingerprint 3AC6EB840FA5CE3FF31BAD80EF93221F8A44FEB2 \
    --keyring /usr/share/keyrings/debian-keyring.gpg \
    https://reform.debian.net/images/reform-system-imx8mq-bpo.img.xz \
    /dev/mmcblk0
bmaptool: info: discovered bmap file 'https://reform.debian.net/images/reform-system-imx8mq-bpo.img.xz.bmap'
bmaptool: WARNING: failed to open the URL with 10 sec timeout, is the proxy configured correctly? Keep trying ...
bmaptool: info: discovered signature file for bmap 'https://reform.debian.net/images/reform-system-imx8mq-bpo.img.xz.bmap.sig'
bmaptool: info: Trying to verify signature using gpgv
bmaptool: info: successfully verified bmap file signature of Johannes Schauer Marin Rodrigues <josch@mister-muffin.de> (fingerprint 3AC6EB840FA5CE3FF31BAD80EF93221F8A44FEB2)
bmaptool: info: block map format version 2.0
bmaptool: info: 1177601 blocks of size 4096 (4.5 GiB), mapped 762079 blocks (2.9 GiB or 64.7%)
bmaptool: info: copying image 'reform-system-imx8mq-bpo.img.xz' to block device '/dev/mmcblk0' using bmap file 'reform-system-imx8mq-bpo.img.xz.bmap'

In other words, this allows me, as a Debian Developer to release Debian system images which any user of Debian or its derivatives like Ubuntu can download and has a trust path from their locally installed (and thus also gpg verified) keyring to the image file I offer for download which is signed with one key inside the keyring. Since you already trust all the keys in the Debian keyring (because the software you have installed can be modified by any person in this keyring) the fingerprint option does not add much in this case but I think it's useful when using other keyrings to make sure that what is downloaded comes from the person I think it is from.