vscode: code .rpm package failing update. Needs to be signed

Rather than skipping the gpg check, I recommend skipping the vs code update until this is fixed: $ sudo dnf update -y --exclude "code"

skip gpg check for now, hopefully next time they don’t forget to sign their package try sudo dnf upgrade code --nogpgcheck

Updating the .rpm package code on Fedora 31 fails because the package is not signed.

cat /etc/yum.repos.d/vscode.repo output:

[code]
name=Visual Studio Code
baseurl=https://packages.microsoft.com/yumrepos/vscode
enabled=1
gpgcheck=1
gpgkey=https://packages.microsoft.com/keys/microsoft.asc

change value for gpgcheck=0 and update now!

Signed software exists for a reason. All of the workarounds assume it was a mistake (which it probably was), but by circumventing the GPG check you are essentially taking food from a total stranger and eating it. Best of luck with that, but the best answer on here is Ender672’s answer of skipping the update until this is fixed properly.

@ricardojohnny Bad security practice. It’s better to wait until it is signed.

Signed 1.40.1 should be available now.

I confirm this on Fedora 31

I’ve removed the unsigned version of the package and am working on publishing a signed version. Sorry everyone, thanks for your patience

As @natiiix mentions above you would expect signed packages coming off a CI server especially from a large organisation like Microsoft who has abundant resources to ensure this.

That is also the very reason I don’t feel comfortable skipping the GPG check - call me paranoid but this is quite the red flag in my opinion.

Workaround works @wotmshuaisi . Hopefully it doesn’t bite me in the butt 😛

skip gpg check for now, hopefully next time they don’t forget to sign their package try sudo dnf upgrade code --nogpgcheck

Thanks @ender672

That was not @ender672 's post. The consensus of the current discussion is that that command is bad security practice. ender672 recommended a different command that is the safe way to go until this potential security vulnerability is fixed. Please be careful people, and know what you are doing.

Ok, my metaphor stands corrected. The person is verified, but the food is not. All the TLS certificate proves is that it came from a verified authentic URL. The code itself can still be compromised. All the ins and outs can be debated, and yeah, it’s probably a mistake, but it is bad practice and there is no real reason to trust the update when you can just ignore this version in dnf or if you need to install it from scratch, specify an earlier GPG verified version.

I installed the previous version. I assume there will be a new signed version out quite soon? sudo dnf install code-1.40.0-1573064644.el7

It seems resolved with no package version change, just the repo update.

It’s working as it should for me now., To complete my Fedora 31 upgrade earlier I just did this sudo dnf --disablerepo code upgrade I changed disablerepo to enablerepo after the GPG signature was in the package A good exercise for me, I learned that dnf repos are in /etc/yum.repos.d and not /etc/dnf/dnf.conf.

If a package is stopping you from updating your system with the typical “dnf update”, then please by all means “–exclude” it. Excluding a package allows the update process to continue while Microsoft figures out what went wrong. In all likelihood they just forgot to sign it, as difficult as it is to believe. In the worst case, somebody put malicious code in the Visual Studio repo and y’all just blindly install it ignoring the GPG signature … that’s not worth it.

skip gpg check for now, hopefully next time they don’t forget to sign their package try sudo dnf upgrade code --nogpgcheck

Thanks @ender672

Getting this error on fedora 31 as well, thanks for the workaround @wotmshuaisi

Can confirm the issue is not yet resolved - running Fedora 30 KDE Plasma Spin. Had to use @wotmshuaisi’s method but this is not a solution I want to be using…

Same problem here for initial install, holding off…

@RMacfarlane - this works. Thanks!

@NicoGim absolutely, that is a fair and valid point. Of course, I still trust “genuine Microsoft” over “random binary (as far as we know)” 😃

but by circumventing the GPG check you are essentially taking food from a total stranger and eating it.

There is a level of trust in the repository being served from an https: URL. So, provided that dnf/yum properly validates the TLS certificate, or if you validate it yourself while downloading the package by other means, you can be sure that the repository server is at least nominally controlled by Microsoft. This is, of course, weaker than proof that the package is signed by the official GPG key of the release team.

For those of you who, like me, thought it was smart to uninstall Visual Studio Code before upgrading it, because for some reasons you couldn’t get “yum update” to work, and you don’t want to install unsigned package on your computer, browse this site directly: https://packages.microsoft.com/yumrepos/vscode/ Download code-1.40.0-1573064644.el7.x86_64.rpm, it’s the version just before the latest one, it is signed and works well. Or use yum/dnf directly as @aweibell suggested.