Use [signed-by=...] for extra repository keys

This narrows the trust offered to the keys associated with extra repos (e.g. local0).

Rather than simply trusting them across the board to sign anything (as is done when they are dropped into /etc/apt/trusted.gpg.d/), this switches to using the method recommended in apt-key(8) of putting them in /etc/apt/keyrings and then adding a [signed=by...] for that key to just the repository that it is supposed to sign.

Hopefully I've managed to arrange the commits so that it's clear that the earlier ones are just reorganising the code a bit to allow for the [signed-by=...] commit (that makes the actual change) to be nice and clean.

BTW This change was previously incorporated into !11 (closed), but I've split it out at @93sam's suggestion. It doesn't matter which of these two MRs gets merged first, as they apply pretty trivially in either order.

mentioned in merge request !11 (closed)

merged

mentioned in commit 9f3a1fb9

mentioned in merge request !1 (closed)

Undoing the merge -this and !11 (closed) don't seem to apply cleanly here together. Are they meant to?

They don't apply together, but it's trivial to rebase either on the other, so I'll push the rebased version of !11 (closed) now that this is merged.

oh, I see you've not applied either MR yet -- is that right?

Whichever MR gets applied first, the other one needs to be rebased onto that for it to then merge cleanly.

I don't mind which order you merge them in, as I have both versions of the rebases already prepared locally, so it's trivial for me to push the rebased version of whichever MR is going to be second in line.

I could of course just push the stacked changes straight into master, given that I have them sitting here -- it depends whether we want the MRs to be obvious in the history or not. I could also do the changes via MRs and merge them myself, and thus save you the effort if you would like me to.