Closed parsa closed 3 years ago
That's annoyhing, I just tried the above command on a clean machine and was unable to reproduce the issue.
A suitable version of 7zip was not found (required v18.1.0). Downloading portable 7zip v18.1.0...
Downloading 7zip...
https://www.nuget.org/api/v2/package/7-Zip.CommandLine/18.1.0 -> E:\vcpkg\vcpkg\downloads\7-zip.commandline.18.1.0.nupkg
Downloading 7zip... done.
Extracting 7zip...
Does it still repro? I ask only because it could have been an intermittent issue in the nuget service that is now resolved so it worked for me but not for you earlier.
same here OS: win10 x64
>vcpkg install curl
The following packages will be built and installed:
curl[core,ssl]:x86-windows
* openssl[core]:x86-windows
* openssl-windows[core]:x86-windows
* zlib[core]:x86-windows
Additional packages (*) will be modified to complete this operation.
Starting package 1/4: zlib:x86-windows
Building package zlib[core]:x86-windows...
A suitable version of cmake was not found (required v3.11.4). Downloading portable cmake v3.11.4...
Extracting cmake...
A suitable version of 7zip was not found (required v18.1.0). Downloading portable 7zip v18.1.0...
Downloading 7zip...
https://www.nuget.org/api/v2/package/7-Zip.CommandLine/18.1.0 -> C:\Users\Jane Wang\vcpkg\downloads\7-zip.commandline.18.1.0.nupkg
File does not have the expected hash:
url : [ https://www.nuget.org/api/v2/package/7-Zip.CommandLine/18.1.0 ]
File path : [ C:\Users\****\vcpkg\downloads\7-zip.commandline.18.1.0.nupkg.part ]
Expected hash : [ 8c75314102e68d2b2347d592f8e3eb05812e1ebb525decbac472231633753f1d4ca31c8e6881a36144a8da26b2571305b3ae3f4e2b85fc4a290aeda63d1a13b8 ]
Actual hash : [ a9dfaaafd15d98a2ac83682867ec5766720acf6e99d40d1a00d480692752603bf3f3742623f0ea85647a92374df405f331afd6021c5cf36af43ee8db198129c0 ]
I'm experiencing the same issue. Tried vcpkg commit: 9ad166279c913cf0becc56865d05ed5806fad8aa Fails at 7-Zip.Commandline/18.1.0 extraction.
This can be temporarily and foolishly 'fixed' by replacing the hash value in vcpkg/scripts/vcpkgTools (tool name="7zip" os="windows") with the actual hash. I'm pretty sure that it such an act ranks highly in the list of security sins.
I can confirm, same problem, on a clean Windows 10 x64 machine.
@hjabird Instead of changing the hash, probably a better idea is to bump the version to 18.05 which is the latest stable version and solves some Windows 10 bugs.
@Rastaban tried again on a clean VM and it does still reproduce. Same exact hashes. Also I my machine I just changed the hash in scripts/vcpkgTools.xml
and the issue went away and Boost installed just fine.
I can confirm the same failure as well.
To work around this I copied the original 7-zip.commandline.18.1.0.nupkg
(the one with the correct hash) that I had on hand from another install location into the vcpkg/downloads
directory. It was then able to install packages as normal.
This doesn't help though if you can't get your hands on the right file...
Thank you everyone for quickly jumping in and reporting this!
I've just pushed 068032bc to master, which downgrades the version of 7-zip to a previous version while we work on some internal changes to fix this more permanently for 18.1.0.
The root cause of the issue is that NuGet.org decided to modify the existing published nupkg files and inject signature files into them, which changes their hash. Our system to protect users from malicious files detected this change and correctly refused to use the un-validated executable.
Unfortunately, it isn't as simple as changing the expected hash, because existing users will still have the older file downloaded. We also can't just rename the file, because nuget.exe
demands that the file be named in a very specific way.
As mentioned above, we're working on fixing this properly as a high priority, but 068032bc will fix the issue for now.
Thanks again!
Since applying the hotfix I'm seeing a new problem
Expected C:\Users\bdavi\Git\vcpkg\downloads\tools\cmake-3.11.4-windows\cmake-3.11.4-win32-x86\bin\cmake.exe to exist after fetching
This didn't make sense to me because the file it's looking for exists. I dug into the code and discovered that fs::stdfs::exists
was returning false for the executable.
I created a brand new local C++ project and verified the same result, not just for the executable, but for all the files in the archive. However, if I wiped the folder and then re-extracted the files using WinRAR, the files suddenly visible as far as fs::stdfs::exists
was concerned.
Something about the 16 version of 7zip is setting file attributes so that even though they're visible in the command line, can be executed, and visible in explorer, the C++ library's filesystem
exists
function thinks they're not present. This actually feels like a bug in the C++ library, but it's blocking my use of vcpkg.
Thanks for the further investigation.
I was able to confirm some strange behavior (though not this particular issue) when using the old 7zip as well. I've pushed a different workaround (273b8ce3d0d3533f3b959a7ecf4b0aa1eef22cab) that's a bit more permanent by mapping the new hash in the tool back to the old hash.
The reason to map the new hash to the old hash is to improve compatibility for existing users which might git pull
but forget to ./bootstrap-vcpkg.bat
-- they'll see everything keep working as before, because they already have the old version downloaded. For new users, they will definitely be bootstrapping, so the new file's hash will get (hackily) mapped to the old hash and the check will pass.
A proper fix is still desirable, but this particular duct tape should hold for longer since it's using the same (latest available) version of 7zip as before.
This issue still appears for anyone who has not ran .\bootstrap-vcpkg.bat
since the patch.
It is not something I'd do when there is no update warning.
Why not increase the vcpkg version?
@ras0219-msft @Farwaykorse Yes, the version should be increased so at least a message to run .\bootstrap-vcpkg.bat
pops up.
@ras0219-msft The nuget versioning is wacky, 7zip versioning is format YY,MM
, i.e. 18.01
, and not number.number
.
Hello, I have the same issue, I am trying to run .\bootstrap-vcpkg.bat but it failed due to toolsrc/ folder not existing.
I got vcpkg 1.50 through VS 2017 Nuget Package Manager and by this way you don't get the toolsrc/ folder...
Thank you in advance.
This seems to be an issue especially when going back in time to get earlier versions of libraries.
This issue is still present in 2020.01 version
For me it was solved by running the command with admin privileges...
updating vcpkg to 2020.06.15- fixes the problem to me
I can confirm the same failure as well.
To work around this I copied the original
7-zip.commandline.18.1.0.nupkg
(the one with the correct hash) that I had on hand from another install location into thevcpkg/downloads
directory. It was then able to install packages as normal.This doesn't help though if you can't get your hands on the right file...
Thank you. This helped a lot!!! @derekseiple
Thank you everyone for quickly jumping in and reporting this!
I've just pushed 068032b to master, which downgrades the version of 7-zip to a previous version while we work on some internal changes to fix this more permanently for 18.1.0.
The root cause of the issue is that NuGet.org decided to modify the existing published nupkg files and inject signature files into them, which changes their hash. Our system to protect users from malicious files detected this change and correctly refused to use the un-validated executable.
Unfortunately, it isn't as simple as changing the expected hash, because existing users will still have the older file downloaded. We also can't just rename the file, because
nuget.exe
demands that the file be named in a very specific way.As mentioned above, we're working on fixing this properly as a high priority, but 068032b will fix the issue for now.
Thanks again!
This issue has been long solved for me, and I don't think the follow-ups describe the same issue. If my opinion as the person who opened this issue counts, this issue can be closed.
I agree, thank you parsa for your response! closing this issue now.
I solve the preblem 1)download this files https://raw.githubusercontent.com/boostorg/boost/boost-1.75.0/LICENSE_1_0.txt https://raw.githubusercontent.com/boostorg/boost/boost-1.75.0/boostcpp.jam 2)skip the hash test add skip code at the vcpkg_download_distfile.camke
Steps to reproduce:
vcpkg install --triplet x64-windows boost
(or any other package) Expected outcome: Boost (or any other package) would install Actual outcome: An error message complaining about hash mismatch for the installed 7-zip is displayedOutput:
Detail:
Full Output: