Steps to Reproduce:
Does this issue occur when all extensions are disabled?: n/a
Most likely causes:
[root@rhel8 ~]# dnf install code
Updating Subscription Management repositories.
Dependencies resolved.
==========================================================================================================================================================================
Package Arch Version Repository Size
==========================================================================================================================================================================
Installing:
code x86_64 1.39.1-1570750844.el7 code 77 M
Transaction Summary
==========================================================================================================================================================================
Install 1 Package
Total download size: 77 M
Installed size: 77 M
Is this ok [y/N]: y
Downloading Packages:
code-1.39.1-1570750844.el7.x86_64.rpm 5.6 MB/s | 77 MB 00:13
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 5.6 MB/s | 77 MB 00:13
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
package code-1.39.1-1570750844.el7.x86_64 does not verify: no digest
Error Summary
-------------
Workaround (with RPM in current directory):
[root@rhel8 ~]# rpm --nofiledigest --nodigest --install code-1.39.1-1570750844.el7.x86_64.rpm
What is FIPS and why do we want to support it?
https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards
https://kennethghartman.com/fips-140-2-in-a-nutshell/
FIPS is a standard for cryptographic operations that is generally required for US Government machines.
RHEL 8 builds of VS Code should use at least sha256 checksums.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1728031
Thanks, I'll pass this on to the linux admin team
They got back to me, this is done at rpm creation time, not signing or upload so it would be in our codebase:
https://stackoverflow.com/questions/24062375/how-to-build-the-rpm-package-with-sha-256-checksum-for-files
https://starlab.io/adding-sha256-digests-to-rpms/
I was wondering why this was closed.
It might have to be a separate RPM from the RHEL7 RPM.
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding
:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
How is this a 'feature request' and why has it not been resolved?
It was apparently deemed not a priority. Shame. I had to create a whole workaround on my RHEL 8 machine.
This is killing me also - Microsoft, bringing their lack of security knowledge and patch management to the entire stack - Cannot run a simple yum / dnf update because their packaging is well below even a standard junior coders punch out these days!
Here's my workaround:
rpm-fips --verbose --upgrade $(find /var/cache/dnf/ -iname '*code*.rpm') --nodeps
Where rpm-fips is an alias for rpm --nodigest --nofiledigest.
There is a special place reserved for ppl like you my friend - Legendary stuff! Too many organisations are pushing 1.X releases these days and touting how fast to market they are, its got to stop!
The issue got 4 up votes in 6 months, so it clearly is not a priority compared to other issues. If you have expertise in this area we would welcome a patch to fix it. This is where the rpm is built:
To build it:
yarn gulp "vscode-linux-x64-build-rpm"
I believe you run this before that to build the right VS Code bits:
yarn gulp vscode-linux-x64-min-ci
You guys use Ubuntu Xenial, right? 16.04 ?
Our minimum is 14.04 whose EOL is April 2022 https://code.visualstudio.com/docs/supporting/requirements
Okay, I'll see if I can work with that.
Okay, as far as I can tell, we'll have to build the RPM with rpm-v4.14 or later. This sucks. However, I believe an RPM built with rpm-v4.14 is still backwards-compatible with some earlier versions. I did some rudimentary testing with the rpm package from RHEL6, RHEL7, and RHEL8 - checking it in RHEL6, RHEL7, and RHEL8. Check command is rpm --checksig --verbose <rpm>:
RHEL 8 (rpm-v4.14):
rpm-4.14.2-37.el8.x86_64.rpm:
Header V3 RSA/SHA256 Signature, key ID fd431d51: OK
Header SHA256 digest: OK
Header SHA1 digest: OK
Payload SHA256 digest: OK
V3 RSA/SHA256 Signature, key ID fd431d51: OK
RHEL 6 (rpm-v4.8):
rpm-4.14.2-37.el8.x86_64.rpm:
Header V3 RSA/SHA256 Signature, key ID fd431d51: OK
Header SHA1 digest: OK (ea671092fba8a91b8aaf3475e89904bd91ac19e3)
V3 RSA/SHA256 Signature, key ID fd431d51: OK
MD5 digest: OK (19d282636e4d5fe51ac060c1bac2d797)
Given this, how likely is it that we can get a signed VS code RPM, built with rpm-4.14, for testing?
Ubuntu 14.04 LTS (the one we're using) only provides rpm-4.11.x (4.11.1-3ubuntu0.1 [amd64, i386]).
Ubuntu 16.04 LTS provides rpm-4.12.x (4.12.0.1+dfsg1-3build3), which is still too old.
Ubuntu 18.04 LTS provides a new enough rpm-4.14.x (4.14.1+dfsg1-2).
The newer Ubuntu versions will probably break a few things, so building with them is not recommended. (In fact, I think building in Ubuntu 16.04 LTS has a high chance of breaking dependencies in RHEL7.) It may also be possible to get rpm-v4.14 in Ubuntu 14.04 LTS, with some trickey.
checking it in RHEL6, RHEL7, and RHEL8
We only support RHEL7+ FYI.
You guys use Ubuntu Xenial, right? 16.04 ?
To clarify, if you meant our build machines we build the product rpm with 16.04:
I'm also not that concerned about actual rpm support in 14.04, the deb needs to work until EOL though.
Given this, how likely is it that we can get a signed VS code RPM, built with rpm-4.14, for testing?
If you make a (draft?) PR I can do a product build out of it and let you know the result and/or paste in a link to the signed rpm.
Ubuntu 16.04 LTS provides rpm-4.12.x (4.12.0.1+dfsg1-3build3), which is still too old.
I can't seem to find where build deps are installed, maybe they're just all included with that image? 馃 We may need to add a step to https://github.com/microsoft/vscode/blob/d62c642e3f148c2957116b42eb933990dd89e9ec/build/azure-pipelines/linux/product-build-linux.yml that installs the needed versions.
I was using RHEL6 because it's the oldest RHEL I have (that I'm willing to spin up), having rpm-v4.8. I forgot RHEL6 wasn't supported, though, thanks for the reminder. One less thing for me to worry about 馃槃.
I'll see if I can get a fake PR later today - not for merging.
Most helpful comment
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!