-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vcpkg 2018.11.23-nohash #2733
Milestone
Comments
@ras0219-msft will add this to next image update, Unfortunately we started distribution of new image yesterday and it is already late to get into this train. Next one should not take too long. As you see I am updating documentation, and you are welcome to contribute too :) |
IlyaFinkelshteyn
pushed a commit
to appveyor/website
that referenced
this issue
Nov 8, 2018
craftwar
added a commit
to craftwar/obs-studio
that referenced
this issue
Nov 12, 2018
craftwar
added a commit
to craftwar/obs-studio
that referenced
this issue
Nov 12, 2018
Updating vcpkg:
|
New Windows images deployed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of installing packages, vcpkg downloads several external executables such as
nuget.exe
and7-zip
.7-zip
specifically is downloaded from NuGet.org as a NuGet package and then unpacked locally.To protect users from malicious executables, the vcpkg system has hashes checked in for every file that is externally downloaded. Unfortunately, NuGet.org has just modified all existing packages to include signature files inside the zip, which changes the hash.
We have fixed this issue in Vcpkg master[1], however since appveyor uses an older copy it will not have these fixes until the next image update.
These are the possible mitigation strategies I see:
git pull && ./bootstrap-vcpkg.bat
in the vcpkg tool folder. This avoid minting a new image but requires adding startup time to every build. If you want to pull a specific commit with the fix, use 068032bc548817a04709970f76268a6d7b1767c7.A longer-term mitigation against issues like this in the future would be to recommend in the appveyor docs on vcpkg that users explicitly pull new versions before running their build.
[1] microsoft/vcpkg#4663
The text was updated successfully, but these errors were encountered: