Solved Invalid key for repo vivaldi stable
-
Hi. The system cannot update from the vivaldi stable repository because it has an invalid key. I tried to import it, but the problem is still the same. Does anyone have any advice? Thanks
wget -qO- https://repo.vivaldi.com/archive/linux_signing_key.pub | \ gpg --dearmor | \ sudo dd of=/usr/share/keyrings/vivaldi-browser.gpg
still same problem
-
Ok, the package signatures for both stable and snapshot should now match the repositories. Plus now all Linux users can check if they actually get updates.
https://vivaldi.com/blog/desktop/minor-update-seven-5-0/ (Version: 5.0.2497.51)
https://vivaldi.com/blog/desktop/reading-list-vivaldi-browser-snapshot-2566-3/ (Version: 5.1.2566.3) -
The old key in
linux_signing_key.pub
got removed(I'd say prematurely) without a transition period.Only RPM repodata was already (re-)signed with KEY07.
The Debian files (repo and packages) still have (valid) KEY06 signatures.New packages (stable and snapshot) will get signed with KEY07.
So updates will start to work again as soon as there actually are some. -
@Ruarí creating new
Release.gpg
should silence the update error (no new packages required).Not sure if new installs are possible at all with current signature state.
GPG is stupid and emits warnings when the key for a perfectly fine signature is expired at check time.
This may lead to APT wrongly rejecting old/current packages. -
@becm Nope. I suggest you run apt update again first. I fixed it yesterday
-
It works perfectly on Ubuntu systems I have tested against and from others who have tried and informed me.
-
Sorry, did not check the file
Release.gpg
contents, was thrown by timestamp (2022-01-27).If APT can (still) cope with KEY06-signed packages they are at least not affected by the GPG behavior.
The issue here is thatlinux_signing_key.pub
only has KEY07, current package signatures are KEY06.
So if one follows the official howto, there will be a key mismatch on install.(what @Ruarí says )In the applied secure signature scheme (
signed-by=
), keys dropped to/etc/apt/trusted.gpg.d
by the installer/cron script are ignored, so this also affects updates. -
@becm said in Invalid key for repo vivaldi stable:
current package signatures are KEY06
The signature on deb packages do not matter in the slightest. No Debian-based system checks them by default. Only the repo meta-data is checked. That might be different for rpm.
-
FWIW and for others reading, I have of course checked this on real systems (Ubuntu and Fedora) and they update without issue on their default configuration. That said, even without such systems you can verify things are correct (signature wise) on the repositories because of the way both YUM/DNF and APT work. A single meta-data file is signed, "repomd.xml" on yum/dnf and "Release" on apt using dettached signatures ('repomd.xml.asc' and 'Release.gpg' respectively). These in turn have a cascade SHA sums to check everything else. Thus we can check if the signatures are setup correctly by fetching the relevant meta-data (and it its dettached signature) and checking with
gpg
directly.First fetch the public signing key and import it into GPG like so:
$ wget https://repo.vivaldi.com/stable/linux_signing_key.pub --2022-01-31 12:29:58-- https://repo.vivaldi.com/stable/linux_signing_key.pub Resolving repo.vivaldi.com (repo.vivaldi.com)... 23.111.9.47 Connecting to repo.vivaldi.com (repo.vivaldi.com)|23.111.9.47|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 3175 (3.1K) [application/octet-stream] Saving to: 'linux_signing_key.pub' linux_signing_key.pub 100%[=================================================================================================================================================================>] 3.10K --.-KB/s in 0s 2022-01-31 12:29:58 (3.54 GB/s) - 'linux_signing_key.pub' saved [3175/3175] $ gpg --import linux_signing_key.pub gpg: key C27AA466: public key "Vivaldi Package Composer KEY07 <[email protected]>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1)
(This is needed because although you will likely have the key already it will be stored in the system wide apt-key and rpm databases, not your current user's GPG installation)
You can now check that both YUM/DNF and APT are signed with this key.
YUM/DNF:
$ wget https://repo.vivaldi.com/stable/rpm/x86_64/repodata/repomd.xml https://repo.vivaldi.com/stable/rpm/x86_64/repodata/repomd.xml.asc --2022-01-31 12:11:09-- https://repo.vivaldi.com/stable/rpm/x86_64/repodata/repomd.xml Resolving repo.vivaldi.com (repo.vivaldi.com)... 23.111.9.47 Connecting to repo.vivaldi.com (repo.vivaldi.com)|23.111.9.47|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 2973 (2.9K) [text/xml] Saving to: 'repomd.xml' repomd.xml 100%[=================================================================================================================================================================>] 2.90K --.-KB/s in 0s 2022-01-31 12:11:10 (3.38 GB/s) - 'repomd.xml' saved [2973/2973] --2022-01-31 12:11:10-- https://repo.vivaldi.com/stable/rpm/x86_64/repodata/repomd.xml.asc Reusing existing connection to repo.vivaldi.com:443. HTTP request sent, awaiting response... 200 OK Length: 833 [application/octet-stream] Saving to: 'repomd.xml.asc' repomd.xml.asc 100%[=================================================================================================================================================================>] 833 --.-KB/s in 0s 2022-01-31 12:11:10 (1.34 GB/s) - 'repomd.xml.asc' saved [833/833] FINISHED --2022-01-31 12:11:10-- Total wall clock time: 0.2s Downloaded: 2 files, 3.7K in 0s (2.53 GB/s) ruario@ruario-slack:~/Downloads$ gpg --verify repomd.xml.asc gpg: assuming signed data in `repomd.xml' gpg: Signature made Sun 30 Jan 2022 06:54:14 PM CET using RSA key ID C27AA466 gpg: Good signature from "Vivaldi Package Composer KEY07 <[email protected]>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: CB63 144F 1BA3 1BC3 9E27 79A8 FEB6 023D C27A A466
(Note: The warning is exactly that 'a warning' [because no third party or you, the user has ever verified the owner]. This signature is good however from the perspective of it matching.).
APT:
$ wget https://repo.vivaldi.com/stable/deb/dists/stable/Release https://repo.vivaldi.com/stable/deb/dists/stable/Release.gpg --2022-01-31 12:22:45-- https://repo.vivaldi.com/stable/deb/dists/stable/Release Resolving repo.vivaldi.com (repo.vivaldi.com)... 23.111.9.47 Connecting to repo.vivaldi.com (repo.vivaldi.com)|23.111.9.47|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 3840 (3.8K) [application/octet-stream] Saving to: 'Release' Release 100%[=================================================================================================================================================================>] 3.75K --.-KB/s in 0s 2022-01-31 12:22:45 (3.76 GB/s) - 'Release' saved [3840/3840] --2022-01-31 12:22:45-- https://repo.vivaldi.com/stable/deb/dists/stable/Release.gpg Reusing existing connection to repo.vivaldi.com:443. HTTP request sent, awaiting response... 200 OK Length: 833 [application/octet-stream] Saving to: 'Release.gpg' Release.gpg 100%[=================================================================================================================================================================>] 833 --.-KB/s in 0s 2022-01-31 12:22:45 (1.18 GB/s) - 'Release.gpg' saved [833/833] FINISHED --2022-01-31 12:22:45-- Total wall clock time: 0.1s Downloaded: 2 files, 4.6K in 0s (2.70 GB/s) $ gpg --verify Release.gpg Release gpg: Signature made Sun 30 Jan 2022 06:54:13 PM CET using RSA key ID C27AA466 gpg: Good signature from "Vivaldi Package Composer KEY07 <[email protected]>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: CB63 144F 1BA3 1BC3 9E27 79A8 FEB6 023D C27A A466
If you still have problems I suspect it is most likely a caching issue. Either in APT/YUM/DNF [remember to use
apt update
for deb or,dnf clean expire-cache
ordnf clean dbcache
(I never recall exactly which]) or perhaps server side via our CDN. If the latter, then the above would also fail for you I would presume. -
I can get a new version issued for those that have manually configured their systems to check the signature of packages (for updates) in addition to the repo. This is not the default on either Ubuntu or Fedora but indeed I can imagine some have done this.
I will not just re-sign the 5.0.2497.48 stable build because that will cause further issues since there will then exist in this world two versions of 5.0.2497.48 (for each architecture).
That would be problematic with regards to CDNs and caching and in addition for third parties who repackage (like ArchLinux) as they often hard code a SHA sum for a given version in their repack scripts. If this changes a problem is assumed.
It will take several hours to rebuild chromium for all Linux archs however. I think this is ok because I do not think that many have configured their systems to check the package in addition to the repo and at this stage it is unavoidable anyway.
P.S. For snapshots, it will be resolved when we release a new one. I am not going to occupy the builders making a special version of the last snapshot just to resolve it for a minority of a minority. Those few who follow snapshots but had not upgraded before the signature expired and also have configured their systems to check both repo and package sigs on upgrade… can wait a bit
-
@becm said in Invalid key for repo vivaldi stable:
Sorry, did not check the file Release.gpg contents, was thrown by timestamp (2022-01-27).
That is just CDN caching of the directory listing. The file was updated yesterday.
We purge the cache on the files when they update but not the directory listings as few look directly at the contents in a web browser. Usually the individual files are fetched by the relevant update system (apt/yum/dnf). The only people browsing the directory listings are the occasional curious user.
-
When you fetch https://repo.vivaldi.com/archive/linux_signing_key.pub and try and import it into GPG (
gpg --import linux_signing_key.pub
), which key is it?What is the name?
-
In my case it looks like this:
-
@Lisio I think that your issue is caused by this configuration:
$ echo "deb [signed-by=/usr/share/keyrings/vivaldi-browser.gpg arch=$(dpkg --print-architecture)] https://repo.vivaldi.com/archive/deb/ stable main" | sudo dd of=/etc/apt/sources.list.d/vivaldi-archive.list
Which is somehow a valid idea, but will break if the key expires and is not updated in time, especially since automatic key transition strategies are not possible like it's done (thinking about it, each package could actually be dual-signed for a time and the key could be updated like this, but this would still lead to issues with machines that are not updated in time, e.g. because they are only used ever so often).
If you actually use this configuration (you can find it at `/etc/apt/sources.list.d/vivaldi-archive.list), you will have to execute this command again:
$ wget -qO- https://repo.vivaldi.com/archive/linux_signing_key.pub | gpg --dearmor | sudo dd of=/usr/share/keyrings/vivaldi-browser.gpg
Another idea is to simply edit this file and remove the
signed-by=/usr/share/keyrings/vivaldi-browser.gpg
part (but this will be less secure as it does not verify the signature then any more as @ruarí has explained).Vivaldi could probably change their approach to using new subkeys (signed by a main key) for the building machine instead of completely changing the main key, but possibly this would have the same issue (I think not).
Also, I don't know enough aboutapt
and its configurations to be certain how it could be done alternatively and whether it uses its own key store / user, but I believe that it should not be necessary to have such a configuration in order to verify the signature.
(I'd be happy to learn why the approach taken may actually be better and how it is supposed to work reliably, or if it is somehow possible to cross-sign the new key with the old one and make the update work again; feel free to educate me.) -
@jumpsq No, my config is rather old:
deb [arch=amd64] http://repo.vivaldi.com/stable/deb/ stable main
-
Sorry, I probably cannot help you then. I guess that also your
/etc/apt/soruces.list
file itself does not contain anything else.http
withouts
will probably not make the difference (at least the error absolutely does not indicate this), and neither do I see why adding the signing key to your user instead ofroot
should. But you may have a look at all of these (and runsudo apt update
from your user account instead), just in case. -
@lisio the error you are getting is for
https://repo.vivaldi.com/archive/deb
which would (effectively) to be a conflicting/duplicate entry tohttps://repo.vivaldi.com/stable/deb
.You can check if the keys are available for the generic sources configuartion:
apt-key list | grep [email protected]
should yield 2 entries (KEY06 and KEY07).
If you (also) have followed the manual tutorial at some point, this is likely the source for the 2nd (now failing) sources entry and the corresponding sources-file must be removed.
-
@lisio said in Invalid key for repo vivaldi stable:
In my case it looks like this:
What does "
find /etc/apt/trusted.gpg.d -name vivaldi\*
" return? I would expect something like this/etc/apt/trusted.gpg.d/vivaldi-C27AA466.gpg /etc/apt/trusted.gpg.d/vivaldi-B69735B2.gpg
Also, exactly what version (number) of Vivaldi are you running now?
-
@ruarí everybody who followed the manual repo setup in its current form is likely to get this error.
The filenames differ, so
vivaldi-archive.list
(…/archive/deb) stays untouched by package magic and keeps referring to an outdated/usr/share/keyrings/vivaldi-browser.gpg
(no KEY07).Luckily the package-configured
vivaldi.list
(…/stable/deb) should keep providing updates. -
@becm Yes I just arrived at this myself a few minutes ago. My manual instructions on the help page are problematic because when we update the key like now, it will not get automatically updated on their system.
In the example there, the signed-by= part is the issue. Compare this with a repo configured automatically in post install (the overwhelming majority of users). Here it would have configure the repo such that there is no "signed-by" part and hence APT will just check if the vivaldi repo can be verified against any valid signature it can find on the system (listed by apt-key or in /etc/apt/trusted.gpg.d). Given the recent stable packages will have placed both /etc/apt/trusted.gpg.d/vivaldi-C27AA466.gpg and /etc/apt/trusted.gpg.d/vivaldi-B69735B2.gpg it would not be an issue for such users.
I need to change those help instructions. I can only help affected users on a case by case basis. However, the manual steps were never the favoured way. For the longest time I avoided us having a help page on this (and I would still prefer not) as it is redundant. Install the package and it all happens for you. That all said, "manual step people" are most likely to be able to fix the issue themselves. So this is not the end of the world.
-
Removing the "signed-by" part or even just issuing the line to fetch the signature file again would fix this (albeit with the latter only until the next time we rotated the signatures).