apt-offline
apt-offline copied to clipboard
rickysarraf
[Security Issue] Not syncing in strict mode | can't check signature; no public key
I'm running am Ubuntu 23.10 box, and I'm using the new scheme for apt keyrings.
So, in the docker.list, I use the signed-by /usr/share/keyrings/docker.gpg.
The gpg key, is of course, where it's suppose to be.
I have the exact same scheme on an online scheme.
While installing, I get the above mention error in the title, plus, it says it's using some RSA key ?
I suspect that apt-offline is validating the gpg key against the gpg database.
Well, found out I need to use deb822-formatted .sources files. But I still have problems with the keys. I will get into it again. If I dont solve it, i'll post the error, here.
I had a similar issue, can you paste the output of the command? I solved it by adding new released keys by debian (I am not using Ubuntu).
Here is the problem. I'm actually on Kubuntu 23.10, and I'm using now the DEB822-STYLE FORMAT.
It seems that, by default, when doing an apt-offline install update.zip, apt-offline uses the /etc/apt/trusted.gpg.d to get the GPG files for checking against the inrelease files gotten from remote repo apt-offline get uris --bundle update.zip.
So, since I use gpg keys directly embedded into the file’s Signed-By field, like so :
Types: deb
URIs: https://deb.debian.org
Suites: stable
Components: main contrib non-free non-free-firmware
Signed-By:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mDMEYCQjIxYJKwYBBAHaRw8BAQdAD/P5Nvvnvk66SxBBHDbhRml9ORg1WV5CvzKY
CuMfoIS0BmFiY2RlZoiQBBMWCgA4FiEErCIG1VhKWMWo2yfAREZd5NfO31cFAmAk
IyMCGyMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQREZd5NfO31fbOwD6ArzS
dM0Dkd5h2Ujy1b6KcAaVW9FOa5UNfJ9FFBtjLQEBAJ7UyWD3dZzhvlaAwunsk7DG
3bHcln8DMpIJVXht78sL
=IE0r
-----END PGP PUBLIC KEY BLOCK-----
apt-offiline do not yet support the DEB822-STYLE FORMAT.
It is important to note, that prior to upgrading to kubuntu 23.10, I was using ubuntu 22.04, and the old way to specify repos like so deb [signed-by=/usr/share/keyrings/sane-keyring.gpg] tor+https://ppa.launchpadcontent.net/sane-project/sane-release/ubuntu jammy main, in separated .list files for each PPA in the /etc/apt/sources.list.d directory. This was working fine for a reason I don't understand yet. After upgrading from ubuntu 22.04 to kubuntu 23.10, that scheme stopped working.
To solve the issue, of course, I needed to move gpg keys from /usr/share/keyrings/ to /etc/apt/trusted.gpg.d, and it seems to work fine in preliminary testing. Further testing is needed to confirm.
As of now, I think it is possible to feed the embedded gpg key block to gpgv, but further analysis is needed.
Ubuntu: apt-key is deprecated
apt-key is deprecated from Ubuntu 22.04 LTS (Jammy Jellyfish) for security flaws: don’t use it anymore whatever your Linux environment. Instead of using it, consider the command gpg now. Then move your public keys relative to your APT package manager to a new location.
This requires to manage correctly the matching between a package repository and its related public key(s) serving to validate the signature of packages to install. As of apt 2.3.10, signed-by keys can be embedded directly into .sources files (Deb822)!
Recommended: Instead of placing keys into the /etc/apt/trusted.gpg.d directory, you can place them anywhere on your filesystem by using the Signed-By option in your sources.list and pointing to the filename of the key. See sources.list(5) for details. Since APT 2.4, /etc/apt/keyrings is provided as the recommended location for keys not managed by packages. When using a deb822-style sources.list, and with apt version >= 2.4, the Signed-By option can also be used to include the full ASCII armored keyring directly in the sources.list without an additional file.
Sources:
How You Manage Debian Apt Sources Is Changing
This is an issue for me, as some of my repos install their keys in /usr/share/keyring. An ugly but easy way to circumvent this would be to grab every file pointed by signed-by in the lists files and add them to the gpgv call.
apt-offline will only look at the default locations for keyring. For 3rd party repositories, it is always upto the user to decide where they store the keys.
As for /etc/apt/keyrings, this is new to me. I'll have a look at some point later.
