[liblzma] update to version 5.6.0#37199
Conversation
|
@carsten-grimm: Thanks for your quick PR! :) |
ports/liblzma/portfile.cmake
Outdated
| -DBUILD_TESTING=OFF | ||
| -DCREATE_XZ_SYMLINKS=OFF | ||
| -DCREATE_LZMA_SYMLINKS=OFF | ||
| -DENABLE_NLS=OFF # avoid issues with installing language specific man files |
There was a problem hiding this comment.
Can't we disable the man files (which we don't want) instead of NLS (which should at least be an option IMO).
There was a problem hiding this comment.
I do not see an option for disabling the man files, but I can certainly try to write a patch that disables them.
There was a problem hiding this comment.
I have a solution to re-enable nls. It requires gettext on linux to generate some .gmo files for the tools feature. I can add a cmake message to inform users that they need gettext if the tools feature is enabled.
There was a problem hiding this comment.
It became a pattern in autotools ports to have a non-default feature nls which depends on gettext-libintl and on host gettext[tools] (and sets config options).
There was a problem hiding this comment.
Interesting, I will try adding the suggested nls feature tomorrow. I am reverting to a draft as that might lead to changes that should be re-reviewed.
There was a problem hiding this comment.
I have added the nls feautre. Everything builds now and I can see the locale files in the package when building with the feature turned on. Let me know if I missed something.
There was a problem hiding this comment.
The feature was removed again after the discussion below.
dg0yt
left a comment
There was a problem hiding this comment.
I tested with mingw ... Maybe it is easier omit nls for now. It is only supported for NLS of the tools, but not for the lib. And I found that the vcpkg cmake wrapper for Intl has a bug which breaks builds for static linkage with external libintl when it depends on external libiconv (as in x64-mingw-static).
ports/liblzma/vcpkg.json
Outdated
| "gettext", | ||
| { | ||
| "name": "gettext", | ||
| "host": true, | ||
| "features": [ | ||
| "tools" | ||
| ] | ||
| } |
There was a problem hiding this comment.
| "gettext", | |
| { | |
| "name": "gettext", | |
| "host": true, | |
| "features": [ | |
| "tools" | |
| ] | |
| } | |
| { | |
| "name": "gettext", | |
| "host": true, | |
| "features": [ | |
| "tools" | |
| ] | |
| }, | |
| "gettext-libintl" |
There was a problem hiding this comment.
Thanks for looking into this @dg0yt .
Sorry, I am slighlty confused: Should I
(a) implement the change that you suggested or
(b) remove the nls feature?
If it is (a), I could mark mingw as not supported for nls.
If it is (b), I could remove the feature and turn ENABLE_NLS always off, as before.
There was a problem hiding this comment.
Basically you can choose between a and b, both lead to a valid state for this port.
But reviewers might or might not complain in case of a. They won't complain about b.
And in the meantime, I try to fix/update gettext. At least you gave me a test port.
There was a problem hiding this comment.
Thanks for clarifying. In this case, I will go with (b) to avoid controversy and keep the scope of the pull request to the update to 5.6.0.
dg0yt
left a comment
There was a problem hiding this comment.
LGTM but somebody else must approve.
Resolves #37839 Reverts #37199 See https://www.openwall.com/lists/oss-security/2024/03/29/4 Note that the version database is unmodified, only the baseline is changed. Because vcpkg builds liblzma from cmake sources downloaded from github and this backdoor required modifications only present in the release tarballs, it is our belief that vcpkg customers are not affected by this problem. However, we are reverting this version out of an abundance of caution as the threat actor clearly has broad access to liblzma infrastructure, and because we believe customers will start flagging this package by version as being a problem.
|
Warning, some people attack me because I have requested the XZ update. |
|
The official XZ team announcement is here: Important to know: There is no problem with contributors here like @carsten-grimm. But several people mix all because I have requested the XZ update in vcpkg. @gowthamgts has participated on HN against me badly and I have commented on two places where he has commented (on my SCRAM request publications):
You can look here the original comment:
You can follow my announcements here:
The good point, people speak about SCRAM "Salted Challenge Response Authentication Mechanism" security ;) Badly, some people or projects like only old unsecure mechanisms, some would like security improvements. |
|
@teo-tsirpanis has done a PR about the new XZ version (5.6.2) here: cc: @carsten-grimm. Linked to:
Official XZ links: |
Fixes #37197.
./vcpkg x-add-version --alland committing the result.The update to version 5.6.0, includes the following changes
lzmadecandlzmainfoare handled in the same manner as the existing toolsxzandxzdecnls was disabled to sidestep an issue with installing the man pagesa new featurenlswas added to enable native language support. This was necessary to handle a new optional dependency ongettextso that the existingtoolsfeature continues to work.I have successfully built
liblzma:x86-windows,liblzma:x64-windows,liblzma:x64-linux,liblzma[tools]:x64-linux,Note that
toolsis not supported onwindows.Requested by @Neustradamus
EDIT 1: added nls feature
EDIT 2: removed nls feature again