Skip to content
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

[liblzma] Workaround source repo having been disabled #37957

Conversation

SchaichAlonso
Copy link
Contributor

@SchaichAlonso SchaichAlonso commented Apr 3, 2024

https://github.com/tukaani-project/xz has been disabled.

Use bminor's fork of xz until the liblzma project publishes a new official repository, as proposed by @MichaelCurrie in a comment on #37839 .

Fixes #37893

  • Changes comply with the maintainer guide.
  • SHA512s are updated for each updated download.
  • The "supports" clause reflects platforms that may be fixed by this new version.
  • Any fixed CI baseline entries are removed from that file.
  • Any patches that are no longer applied are deleted from the port's directory.
  • The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
  • Only one version is added to each modified port's versions file.

https://github.com/tukaani-project/xz has been disabled.

Use bminor's fork of xz until the liblzma project publishes a new official
repository as proposed by @MichaelCurrie in a comment on microsoft#37839
Copy link
Member

@BillyONeal BillyONeal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have been explicitly asked by security folks to not change the upstream for liblzma at this time.

In particular, trying to grovel around for different mirrors leaves customers exposed to the original risk that caused the xz repo to be suspended and additional risks related to needing to trust whomever is operating the mirror

@Neumann-A
Copy link
Contributor

I mean it could be changed to the real upstream if github is not re-enabling the repo which it should have done at this point at least in archive/read-only mode.

What are the security folks doing to unblock vcpkg users without an asset cache?

@allenweiyan1985
Copy link

allenweiyan1985 commented Apr 4, 2024

We have been explicitly asked by security folks to not change the upstream for liblzma at this time.

In particular, trying to grovel around for different mirrors leaves customers exposed to the original risk that caused the xz repo to be suspended and additional risks related to needing to trust whomever is operating the mirror

idk

what's there to trust
any existing fork of xz on github will do.

tarball that has to hash up to a very specific sha512 otherwise it won't even extract.
upstream can't control what tag we pull out

@SchaichAlonso
Copy link
Contributor Author

I mean it could be changed to the real upstream if github is not re-enabling the repo which it should have done at this point at least in archive/read-only mode.

I browsed through all discussions yesterday and found some report the git.tukaani.org repository had bandwidth issues. Where we obtain the file from, for now, isn't really relevant, as the hash verifies the authenticity of the file, while the bmirror github account was the proposed one on the other thread.

What are the security folks doing to unblock vcpkg users without an asset cache?

Asset caches are not supposed to be a reliable source of data. If unused for a "while" (which varies between CIs and repository configurations) the asset cache contents will perish silently, if overstressed, the contents might perish, too. Caches usually aren't backup-ed, either, as their contents represent re-fetch-able data. Therefore, if a project is moved, or the CI is redeployed, the asset cache will be gone.

It's just a matter of time until asset cached liblzma tarballs drop out of the cache.

@GordonSmith
Copy link
Contributor

We have been explicitly asked by security folks to not change the upstream for liblzma at this time.

In particular, trying to grovel around for different mirrors leaves customers exposed to the original risk that caused the xz repo to be suspended and additional risks related to needing to trust whomever is operating the mirror

This port used to point to https://github.com/xz-mirror/xz (e9e1c40) which was archived just after the 5.4.4 tag (conveniently)?

stevecotton added a commit to stevecotton/wesnoth that referenced this pull request Apr 7, 2024
Setting up vcpkg tries to build xz from source, which fails because the
entire xz repo has now been made private or taken down. The vcpkg team
have been advised not to switch to an alternative repo [1], so for now
our Windows builds will always fail.

Turn those builds off, so that we don't get familiar with seeing red
status markers on all PR's CI results.

[1] microsoft/vcpkg#37957 - second comment is
the vcpkg team's "We have been explicitly asked by security folks to not
change the upstream [to a different repo] for liblzma at this time."
stevecotton referenced this pull request in stevecotton/wesnoth Apr 7, 2024
Setting up vcpkg tries to build xz from source, which fails because the
entire xz repo has now been made private or taken down. The vcpkg team
have been advised not to switch to an alternative repo [1], so for now
our Windows builds will always fail.

Turn those builds off, so that we don't get familiar with seeing red
status markers on all PR's CI results.

[1] `https://github.com/microsoft/vcpkg/pull/37957` - second comment is
the vcpkg team's "We have been explicitly asked by security folks to not
change the upstream [to a different repo] for liblzma at this time."
stevecotton referenced this pull request in wesnoth/wesnoth Apr 7, 2024
Setting up vcpkg tries to build xz from source, which fails because the
entire xz repo has now been made private or taken down. The vcpkg team
have been advised not to switch to an alternative repo [1], so for now
our Windows builds will always fail.

Turn those builds off, so that we don't get familiar with seeing red
status markers on all PR's CI results.

[1] `https://github.com/microsoft/vcpkg/pull/37957` - second comment is
the vcpkg team's "We have been explicitly asked by security folks to not
change the upstream [to a different repo] for liblzma at this time."
stevecotton referenced this pull request in stevecotton/wesnoth Apr 7, 2024
Setting up vcpkg tries to build xz from source, which fails because the
entire xz repo has now been made private or taken down. The vcpkg team
have been advised not to switch to an alternative repo [1], so for now
our Windows builds will always fail.

Turn those builds off, so that we don't get familiar with seeing red
status markers on all PR's CI results.

[1] `https://github.com/microsoft/vcpkg/pull/37957` - second comment is
the vcpkg team's "We have been explicitly asked by security folks to not
change the upstream [to a different repo] for liblzma at this time."
@Pentarctagon
Copy link

This has already impacted us over at https://github.com/wesnoth/wesnoth given that the vcpkg cache gets rebuilt every few days due to the Windows runner image frequently updating (#26601 (comment))

@jimwang118 jimwang118 added the category:port-update The issue is with a library, which is requesting update new revision label Apr 7, 2024
stevecotton referenced this pull request in wesnoth/wesnoth Apr 7, 2024
Setting up vcpkg tries to build xz from source, which fails because the
entire xz repo has now been made private or taken down. The vcpkg team
have been advised not to switch to an alternative repo [1], so for now
our Windows builds will always fail.

Turn those builds off, so that we don't get familiar with seeing red
status markers on all PR's CI results.

[1] `https://github.com/microsoft/vcpkg/pull/37957` - second comment is
the vcpkg team's "We have been explicitly asked by security folks to not
change the upstream [to a different repo] for liblzma at this time."
@JackBoosY JackBoosY mentioned this pull request Apr 8, 2024
@JackBoosY
Copy link
Contributor

Since there are so many ports that depend on liblzma, I think we need to fix this ASAP.
I agreed that use fork is not a good idea.

@MichaelCurrie
Copy link

I agree with @JackBoosY that his PR should be applied immediately - 5.4 was not backdoored; we should not leave vcpkg liblzma in a broken state for over a week now. #38037

@13oat
Copy link

13oat commented Apr 8, 2024

From official website, https://tukaani.org/xz/

The repository on GitHub is temporarily unavailable but the mirror at git.tukaani.org is up to date:
git clone https://git.tukaani.org/xz.git

could we use https://git.tukaani.org/xz.git instead?

@JackBoosY
Copy link
Contributor

From official website, https://tukaani.org/xz/

The repository on GitHub is temporarily unavailable but the mirror at git.tukaani.org is up to date:
git clone https://git.tukaani.org/xz.git

could we use https://git.tukaani.org/xz.git instead?

But

I browsed through all discussions yesterday and found some report the git.tukaani.org repository had bandwidth issues. Where we obtain the file from, for now, isn't really relevant, as the hash verifies the authenticity of the file, while the bmirror github account was the proposed one on the other thread.

@BillyONeal
Copy link
Member

Thanks for the workaround attempt :)

See #37841 (comment) : the repo should be public again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-update The issue is with a library, which is requesting update new revision
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[liblzma] Unable to download "xz" caused install falied
10 participants