Replace PolyMC with successor #196480
Comments
|
PlaceholderMC is now PrismLauncher |
|
PolyMC is not compromised, no malicious code has been introduced to the project. Why not check the commits yourself before believing what are now competitors to the project? |
|
The owner has removed access from a ton of contributors without valid reason and is overall acting like an egotistical nut. It may be worth discussing leaving PolyMC as is, but it is definitely necessary to package the replacement. The pull request mentions speaking to the PolyMC maintainers to see if they will continue to maintain it or switch to PrismLauncher. |
I did I don't consider it safe to support, as I'm concerned about every maintainer suddenly being removed in what appears to be an outburst by this developer for no apparent reason (the CoC wasn't new), I therefore consider PolyMC to be compromised, and indeed a OVE has already been put as a known vulnerability for the package. As it is vulnerable and there is a fork by the old maintainers that fixes the issue mentioned in the OVE, this is a valid substitute, so I went ahead and removed PolyMC entirely in my PR. If the maintainers wish it to stay maintaining PolyMC I'll undo that and leave it with the OVE only, however my presumption is that they are likely to want to jump ship |
|
Slightly incorrect, the lead dev came back after 3 years or something is what I was told in the server then the leader kicked all of the maintainers for leftist views (basically he is homophobic). After this the maintaners are making prismlauncher. However PolyMC is not compromised; the lead dev is looking for new maintaners right now actually. (All the old maintaners have switched pretty much) I might have gotten something wrong but this is my experience. |
I don't necessarily think that can be right Here's a screenshot from the PolyMC commit history, filtered by user, showing that there was commits far more recently than 3 years- and scrolling down shows even more commits and maintainer activity. This can't have been a "I've come back from a 3-year hiatus" thing as the dev was there all along |
|
Assuming that PolyMC continues development as normal, I disagree with the categorization of this as a security vulnerability. Plenty of single-dev applications are permitted. Making exception for drama, political, or ideological reasons sets a bad precedent. |
|
It seems fairly unlikely that development will continue "as normal", given that all the other active developers were removed from the project. I disagree with categorizing this as ideological or political, it is a pragmatic response if you care about the security of your users.
If in the long term polymc development picks back up and the remaining dev regains some trust, maybe it's safe. |
|
To my (biased and personal) taste, I wouldn't want to support a maintainer who has very clearly expressed their very hateful biases, and who subsequently ousted the people who worked on the majority of the codebase. In a more pragmatic sense, 'firing' the entire development team is not a normal track for development by any metric, much less for as flippant as a reason as they did, so I agree with LunNova here. It is highly unlikely for development to continue on PolyMC as it did in the past, especially since the community has been pretty dead-set on dropping it as soon as possible. Should the project managed to somehow claw back trust and actually pursue active development, then maybe there would be some justification to package it again (despite the problems with the aforementioned developer), but as it stands there just isn't a reason to not switch to Prism Launcher since it's the project with active maintainership behind it. |
|
A cursory look at the two users pushing to keep it shows they have never interacted with nixpkgs outside of this issue, so their comments may not be in good faith. |
|
This comment is not in good faith, Just because we haven't interacted with the the project doesn't mean we're bad actors. I came here to inform you that you're acting with bad info. I didn't come here to flame or disturb you. |
So a few points ought be made here. First, regardless of how likely or unlikely it is for development to continue as normal, the point is that so long as PolyMC is maintained and up to date, with no security issue, removing it in favor of Prism sets a bad precedent for any future such disagreements between devs. Even if we assume that PolyMC is going to become deprecated that is not a good reason to whimsically replace it with it's hard-forked successor. It would be acting in bad faith to PolyMC to do so, and I prefer it when my repositories are as neutral as possible. If PolyMC becomes an actual, rather than simply speculative, security threat then we can rehash this issue. There are plenty of other single-dev projects that are out there that are not treated in this way. Ones that also get access to your accounts. That's to say nothing of the fact that PolyMC never gains access to any of your credentials or information to my understanding. |
|
The OVE mentions that PolyMC downloads code from a server at runtime and runs it. Because of this, we need a higher level of trust in the PolyMC team than we need for most single-developer projects. It is insufficient to trust that the code currently in the github repository is secure, we also must trust that the maintainer will not put a compromise in the runtime-downloaded stuff. |
|
I believe it is better to remove PolyMC for the time being and see how things develop. A singular (and arguably minor) developer ousting an entire team for what appears to be a disagreement over ideologies/politics is not exactly invoking hope that the same dev will act in a trustworthy manner in the future. As Jason mentioned PolyMC uses a external server to aggregate various pieces of information from multiple sources (modloaders, required libraries, mojang, etc.) so in theory this developer has now the ability to push arbitrary code to users. While malicious code could have been introduced before this, having had multiple developers that vetted for the meta server helped ensure that its contents are safe/sane. |
Even as such, simply removing PolyMC rather than replacing it is better. I want to reiterate that it sets a bad precedent that we would hand over something to a faction in such a split. It's also worth noting that the metadata server, and such, can be changed. Again though, the assumption is being made that the PolyMC dev is untrustworthy, and while I don't think he is nice, I've not seen anything that would suggest that he is untrustworthy. |
I don't see how that is better in any way. Then there's no alternative at all in nixpkgs, since MultiMC also isn't packaged (I assume for good reason due to its distribution policy). And that alternative definitely exists. |
|
Nixpkgs was in a weird situation with the `multimc` package when it
existed. It might be reasonable to have a `devlauncher` package along with
a `multimc-bin` package? I have a binary MultiMC package in my dotfiles
based on someone else's.
…On Wed, Oct 19, 2022, 9:19 AM 2xsaiko ***@***.***> wrote:
Even as such, simply removing PolyMC rather than replacing it is better.
I don't see how that is better in any way. Then there's no alternative at
all in nixpkgs, since MultiMC also isn't packaged (I assume for good reason
due to its distribution policy). And that alternative definitely exists.
—
Reply to this email directly, view it on GitHub
<#196480 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB7X32PMLK4D2XVKJSQBUL3WD7YMLANCNFSM6AAAAAARHP3TKM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
To slightly elaborate, my understanding (which shouldn't be taken as fact)
was that the MultiMC developers were against the Nixpkgs package using
their branding, but weren't as against it as for other distros since it was
at the time non-trivial to build MultiMC without branding and official
binaries wouldn't easily run on NixOS.
…On Wed, Oct 19, 2022, 9:47 AM leo60228 ***@***.***> wrote:
Nixpkgs was in a weird situation with the `multimc` package when it
existed. It might be reasonable to have a `devlauncher` package along with
a `multimc-bin` package? I have a binary MultiMC package in my dotfiles
based on someone else's.
On Wed, Oct 19, 2022, 9:19 AM 2xsaiko ***@***.***> wrote:
> Even as such, simply removing PolyMC rather than replacing it is better.
>
> I don't see how that is better in any way. Then there's no alternative at
> all in nixpkgs, since MultiMC also isn't packaged (I assume for good reason
> due to its distribution policy). And that alternative definitely exists.
>
> —
> Reply to this email directly, view it on GitHub
> <#196480 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB7X32PMLK4D2XVKJSQBUL3WD7YMLANCNFSM6AAAAAARHP3TKM>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
|
See #160960 about the efforts to add a |
That PR packages a highly impure script that installs multimc into your home directory and enables its auto-updater. |
|
Indeed it does, and I would vastly prefer to package Prism Launcher for this reason. However discussion about a compiled |
I don't see how this sets a bad precedent. This situation is not a simple disgreement between developers, in which case it would make sense to keep two packages. This is a case of one bigoted developer removing the majority of other developers from a project. With the majority of active developers switching, there is no reason as of right now to keep the PolyMC package maintained, especially if the current maintainers will be switching to PrismLauncher. If PolyMC does continue to be developed and is not entirely replaced by PolyMC, and you or somebody else is interested in maintaining the package at this point, then it would make sense to discuss adding it back. |
|
Framing this as a "faction" that "split" is misleading, I think intentionally. PolyMC's (relatively inactive) project owner suddenly removed access from almost every major contributor, claiming to be purging "queer ideology" and becoming "public about hating [that] shit". They then (to the best of my knowledge) proceeded to ban every member from the PolyMC Discord server who was open about being trans or supporting human rights. Most of the estranged maintainers formed a group (Prism Launcher) to fork and continue development on the project. PolyMC is as good as defunct at this stage. |
|
@Ashdemai Why did you react with a thumbs down? |
I strongly believe that whatever happens to polymc and whether we package multimc or not we should package Prism. The other 2 have marked disadvantages. When we package Prism, there are then 2 questions:
For the first question I am up in the air. While my PR does remove PolyMC, I think it could be added back if people still want to maintain it. I've mentioned in my PR that the current maintainers should say if they want to maintain it <inclusive or> if they want to maintain the new Prism Launcher package. I'll go with consensus on that one while giving the current maintainers priority in whether they want to keep or axe it. I don't really want to argue over it: It's not something I'm maintaining and it's not something that I really want to. For the second question I am referring to an entry in the 22.05 docs that states that people who want to use MultiMC should use PolyMC. As there is a security vulnerability, I think that we should give Prism Launcher as the alternative rather than PolyMC. I don't like recommending users packages which are marked as insecure in nixpkgs, and I don't imagine any of you do either. As the entry is in the 22.05 manual, this will require backporting. If MultiMC is packaged and backported, we could instead remove the manual entry. Keeping a recommendation to use an insecure package when there is an alternative without the issue seems strange to me. |
|
The current status of these various projects isn't immediately obvious, so I thought I'd summarize it. I definitely don't think only looking at the current status is enough to make a decision (historical context is very important), but it's important to know.
|
|
Looking at past precedent in Nixpkgs, the situation with PolyMC and Prism Launcher seems similar to the situation with nMigen and Amaranth. That resulted in legal threats made by a nMigen developer against Nixpkgs, Amaranth being packaged, and nMigen being removed with no alias. |
My understanding is that "switching the package out" would mean...exactly what you just said. I'm also not sure how that "prevents Nix from taking any side"? But if it helps you to think of it that way, sure. |
That's what my PR does currently- with the addition of an error note if you try to install PolyMC telling you that prism is a successor. I'm not sure what should be done differently there for your wishes to be fulfilled, unless you would prefer me not to tell former PolyMC users that an alternative exists? I apologize if my wording was confusing- I can see how what I said could have been taken to mean that I was aliasing prismlauncher to polymc. Don't worry, this isn't the case. Nobody will unknowingly install prismlauncher because of my PR |
|
I think so long as there's no active security issue with PolyMC, it doesn't make sense to suggest people to Prism. |
|
But there IS an active security issue:
|
|
I'm not sure I want a developer that hateful and impulsive to have RCE on my machine. |
|
The "RCE" isn't an RCE, it's a OVE, which is issued solely on the basis he is the only maintainer. If he managed to get more maintainers, would we reinstate PolyMC? And the RCE applies to prism as well. |
|
RCE stands for remote code execution, "RCE isn't an RCE, its a OVE" does not make sense. The OVE is an identifier for the RCE and github hijack/takeover issue. The RCE is present by design in all similar launchers, it is the combination of the RCE and the volatile sole developer controlling the metadata server which is a big issue. I like the idea of having the metadata repo as an optional input to the package so we could reduce that attack vector, and using it locally, but that would require some significant patches or upstream changes. |
Yes, this is not an issue of security, but one of trust. |
|
Putting in funny magic numbers and calling it an “OVE” does not mean anything. I understand why some might feel that there is some privacy concerns regarding to PMC right now, hence the PolyMC package should be left as is and prism launcher should get its own package without making a big fuss out of it. |
Unless there are is someone willing to maintain it I think it should be removed, at least until someone is found to maintain it again. The people who maintained the PolyMC package will probably move on Prism and leaving PolyMC unattended might cause problems in the future because the meta server is out of our control. |
|
The people who maintained PolyMC itself have already moved on to PrismMC, and the guy who kicked everyone else out of PolyMC has already stated he's unable to maintain it by himself.
This isn't just privacy concerns; the server that PolyMC uses by default to download libraries automatically is also compromised. The same guy who booted everyone else off also has control of that metadata server. We should treat this the same way as we'd treat a social engineering attack or RAT which granted the attacker absolute, sole control over both the repo and an update server. In either of those cases, we would be calling it a vulnerability, even if PolyMC itself hadn't been changed, because a malicious actor could use that access to do malicious things (i.e., direct PolyMC's automatic update system to download a 'library' that has malicious code in it). |
|
Again though, the point is to remove it until such point that PolyMC is actively maintained. |
@Continous This is not the point I was making. I was saying that there is precedent for packaging a version run by developers after they split from the formal owner of the project. I also don't think rehashing the nMigen situation is particularly desirable. |
Even if PolyMC starts being actively maintained again--there's no reason to trust that project anymore. It is currently under control of someone who is, by all appearances, not trustworthy. |
|
Ok, I switched to Prism, as official Minecraft launcher has been broken since 2021 unable to install any new clients past 17.1.
|
Being unable to trust maintainers means being unable to trust the package. I feel like we should've learned this after the npm hacktivism thing, but apparently it bears repeating. |
On personal note: I installed PolyMC, it is working fine, parts of it are more current than in Prism. I will be observing both projects, but unless there is technical necessity, there is no point (strictly for me) switching the base. From the looks of it - creating the technical difficulty (including this "bug") was part of the Prism's agenda, which speaks against using it as the correct procedure is advertising and forking, - not replacing. This discussion is closed from my side, reason being not productive. Happy coding. |
|
The guy who took over PolyMC kicked all of the other maintainers out and started making changes. This is an immediate threat, because the same permissions that allow you to change the ToS and code of conduct also allow you to change everything else. To claim otherwise is like claiming that RCE proof-of-concept demos don't count as RCE because they "only" pop calc.exe. Linux had, has, and will have tons of CVEs, yes. The linux kernel team generally fixes those issues as soon as they can, and issues CVEs to warn the community while they are working on a fix. The fix for a "the current owner of the repo is doing shady shit" vulnerability is to switch to a different repo, which the original maintainers of PolyMC did by switching to Prism. I'm curious which features are "more current" in PolyMC than in Prism, seeing as it had a dev team of one guy when the fork happened. Looking at the commits since the "remove leftoids" one, there's been a number of bugfixes, and...the ability to edit the image and position of the cat icon in the toolbar. Unless the ability to put Big Floppa on your minecraft launcher is a killer feature, I don't think that helps your case. |
Owner, root.
Owner, root.
Even rm -rf. Owner, root.
|
|
...so you see the problem here, then? If one person kicks all other maintainers out, they have essentially privilege-escalated. They are now root. That is the problem. |
Minecraft 1.19.4 works for me. |
|
It's not people "kicking themselves out". One guy kicked everyone else out. Those who got kicked out forked the repo because the repo was owned by a guy who thought it was acceptable to kick everyone out so he could make changes without anybody else stopping him. |
Its exactly "People have been kicking themselves out since Pontius Pilatus. Earth still rotates." How is this drama related to ability to run the minecraft client I purchased? |
|
There is a valid technical reason. The technical reason is "our supply chain is compromised". If the root cannot be trusted and has removed all other contributors' permissions, that's a security issue. |
|
I'm a nixpkgs maintainer of PrismLauncher and the person who PRed to replace PolyMC with PrismLauncher. We replaced PolyMC due to the risk it poses as a project that downloads code at runtime with metadata controlled (without any package update or way that someone running PolyMC can vet the changes) by a maintainer who suddenly removed all other maintainers from the project. We believe this is an intolerable risk in the supply chain (effectively RCE if the maintainer willed it) and additionally that not removing the package would lead to people using it without being aware of the risks. If you'd still like to run PolyMC, you are welcome to override the src attribute of our package, but we won't be maintaining it in nixpkgs. I'm aware this isn't the resolution you wanted, but we're not going to reinstate PolyMC. Please, both of you, stop arguing in the issue comments. |
Issue description
As discussed in #196460, the PolyMC minecraft launcher project appears to have been compromised and its meta-data server cannot be trusted anymore. The package has been marked as vulnerable, however there is not yet a suitable replacement launcher complete with meta-data server to make it usable.
Non-compromised PolyMC maintainers have started a spin-off fork at PlaceholderMC.
Discord discussion for PlaceholderMC: https://discord.gg/hX4g537UNE
Leaving this open as a tracking issue for the moment.
The text was updated successfully, but these errors were encountered: