Explain when xbps warns about a changed RSA key and when not

[camoz]

Right now the following parts mention that xbps might report about a new RSA key:

• https://github.com/void-linux/void-docs/blob/master/src/xbps/troubleshooting/common-issues.md#verifying-rsa-keys
• https://github.com/void-linux/void-docs/blob/master/src/installation/guides/fde.md#system-installation
• https://github.com/void-linux/void-docs/blob/master/src/installation/guides/chroot.md#the-xbps-method

xbps-install might ask you to verify the RSA keys for the packages you are installing.

To me, that does not sound very encouraging, especially because it's a security-relevant step. When I was first reading it, I thought "hm, so does that mean it sometimes just forgets about it?". Explaining what that "might" depends on would probably help, e.g. "if condition, then xbps-install will ask you to verify the RSA keys".

Someone on IRC said that the condition depends on whether the new key is already on the system, and that in turn depends on the installation method.

AFAIK the chroot and fde guides will be merged someday, then it has to be explained only in two places. The troubleshooting section can then link to the explanation in the unified installation guide, then it has to be explained only in one place.

Edit: Use correct link

[Duncaen]

The chroot guides could just copy the keys from the live media instead of having to manually verify. This keeps the chain of trust from the verified ISOs and is less error prone than manually verifying.

mkdir -p rootdir/var/db/xbps/keys
cp /var/db/xbps/keys/*.plist rootdir/var/db/xbps/keys/

[camoz]

Makes sense. It's an additional step in the guide, but it saves the user from manually comparing the fingerprints, so I think it would be a good addition.

An alternative would be to give xbps a -k, --key-dir (or similar) option to specify a custom directory containing the keys, similar to -C and -c. pacman has this FWIW (--gpgdir). But maybe this is considered "feature-creep" for xbps? It would save the guide the proposed additional step of manually copying keys, and might come in handy for quickly creating chroots. Or is there some other trick/mechanism to create chroots, which doesn´t require manually comparing fingerprints?

[Duncaen]

The plan is to replace the signature stuff completely, adding new features that are going to be replaced with something where we may not have a "key dir" is probably not beneficial.
There is no trick, other than copying the actual keys into the the directory, static binaries and the ISOs come with the right keys.