Page MenuHomeVyOS Platform

GPG signature warning, default 'no' still goes ahead and starts installing
Open, LowPublicBUG


I just got a GPG signature error while installing 1.2.0-rc11, fine, was planning on simply restarting add system image to see if that would help.

marlinc@r1:~$ add system image
Trying to fetch ISO file from
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  352M  100  352M    0     0  1273k      0  0:04:43  0:04:43 --:--:-- 3381k
ISO download succeeded.
Checking for digital signature file...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   836  100   836    0     0   2123      0 --:--:-- --:--:-- --:--:--  2121
Found it.  Checking digital signature...
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: assuming signed data in `/var/tmp/install-image.11577/vyos-1.2.0-rc11-amd64.iso'
gpg: Signature made Mon 17 Dec 2018 10:47:55 PM UTC using RSA key ID A0FE6D7E
gpg: Can't check signature: public key not found
Signature check FAILED.
Do you want to continue anyway? (yes/no) [no]

As you can see the default action is no, so I simply pressed enter, expecting to be dropped to the shell.

Instead the install continues:

OK. Proceeding with installation anyway.
Checking MD5 checksums of files on the ISO image...OK.
What would you like to name this image? [1.2.0-rc11]: ^C
ERROR: Signal received. Exiting...


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

syncer triaged this task as Low priority.
syncer edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.

I can confirm that this problem also exists in VyOS 1.1.x when trying to upgrade to 1.1.8. I consider this a pretty big security vulnerability, and this should be fixed in 1.1.x, not just in 1.3 or 1.2.

I can confirm that this is broken everywhere "get_response" is used, where the default should be "no". GPU signatures are ignored, disks are deleted, etc. I'll work on making up a sane replacement.

dmbaturin set Is it a breaking change? to Unspecified (possibly destroys the router).
erkin set Issue type to Bug (incorrect behavior).Aug 31 2021, 7:00 PM