-
-
Notifications
You must be signed in to change notification settings - Fork 246
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
Add Modrinth modpack support #1352
Conversation
Co-authored-by: Davide Ceschia <[email protected]>
Co-authored-by: Davide Ceschia <[email protected]>
Co-authored-by: Davide Ceschia <[email protected]>
* Change Maximum Value for Max Memory in Global Settings * Change Maximum Value for Max Memory in Instance Settings Co-authored-by: Davide Ceschia <[email protected]>
s/syncronizing/synchronizing Co-authored-by: Davide Ceschia <[email protected]>
CurseForge doesn't (or no longer) users the yarn property in the manifest to specify the fabric version. Instead they now include the version in id property, ex: `fabric-0.11.6`. When importing an instance we'll check for the yarn property first, for backwards compatibility, but will then try to extract it from the id if it's missing. For exporting we'll now include the loader version in the id and omit the yarn property, exactly like CurseForge. Fixes gorilla-devs#942 Co-authored-by: Davide Ceschia <[email protected]>
…s | Better progress update (gorilla-devs#962) * Changed updatePercentage() function to defaut Changed the function to what all the other Downloads use. - Checking if progress changed => less CPU load - Using parseInt() function to prevent errors * Applied concurrent download setting to FTB file-download on instance creation * Codacity means I should do that :/
* Added usual MacOS default menu New Features: - option to open About Page - Services Submenu - Hide Others - Show All * Changed requested Edits - Wrong quote on line 78 - Revert to original click lambda * …And another wrong quote * ...fixed wrong quote Wow, seems that this happend quite often :/ Co-authored-by: Davide Ceschia <[email protected]>
Co-Authored-By: Mr. Hallway <[email protected]> Co-authored-by: Mr. Hallway <[email protected]>
* Fixed Problem whit hidden accounts in modal Just had to add overflow: auto; and a padding to the parent element. * Moved CSS-Fix for Account Modal to container initialization Co-Authored-By: Mr. Hallway <[email protected]> Co-authored-by: Davide Ceschia <[email protected]> Co-authored-by: Mr. Hallway <[email protected]>
Co-authored-by: Davide Ceschia <[email protected]>
* Auto-detect CurseForge modpack loader type Currently all CurseForge modpacks are assumed to be using Forge, whereas they may actually be using Fabric. Instead of hardcoding which one is being used, we can parse the type from the manifest. Fixes gorilla-devs#961 * Support changes versions of fabric modpacks A few refactors were needed to enable this: - Created a utility for extracting the fabric version from a manifest - Revised the change version flow to properly parse fabric vs forge loader versions (previously it just assumed it was a forge modpack) - Reworked the CreateInstance flow to better support code-sharing Co-authored-by: Davide Ceschia <[email protected]>
* Add social links * Fix eslint
Honestly, that's Modrinths problem. It's just not our part to deal with potentially malicious executables. They could do that way more effectively and they can be uploaded as plain mods the same way. |
Good point. It's a reasonable expectation that the user has a functioning AV on their system. Be it a paid product or just Windows Defender, if something like that isn't running then that's on them. |
I think it is our responsibility to protect our users the best we can, we should wait for modrinth to implement some kind of filters and validation on what type of files can be uploaded before merging this. |
In the interest of getting this finished sooner, I've come up with another option we could implement while Modrinth do things on their side. |
imo it's not a big issue, if there's a malicious file you can report and modrinth will remove it |
Except you can't. At least, there is no official channel for reporting malicious content on Modrinth yet. To report something you'd have to go out of your way to find someone to tell, and not many people want to do that. The point of this conversation is how we can protect users. Sure, adding a report button to the Modrinth page is good, but that won't stop a user downloading a dangerous pack that hasn't been reported yet. We should be doing what we can to prevent that happening. |
|
My bad, I never signed into the website so I never saw that button. My point still stands though. Not many normal users will have a GitHub account, nor will they sign into the Modrinth website in order to find the report button. Most likely their only interaction with the platform is going to be through the launcher itself, not signed in through the website. |
This can be removed once Modrinth begin blocking potentially malicious scripts/binaries
.sh and .AppImage aren't on there @Pyroglyph |
An executable dosen't even need a specific extension (see Linux). It could be any extension and still be executed. Another question would be how those files would be executed in the first place |
It can, but extension are used to identify, what type of executable it is from a glance. |
Ok Linux you can use any extension for literally anything as long as you include the shebang |
That's something I hadn't really thought of. The only way I can think of is if there is also a rogue mod included in the pack. And if that's the case then the bad actor could easily have made that mod a dropper or made it do what the script/binary would have done anyway.
Considering the above, I agree. I suppose this stuff really is for Modrinth to deal with, as I don't think we can do anything to effectively combat it on our side. While we wait for that to happen, I'll continue to work on the rest of the PR. |
This reverts commit ab04524.
Looks like it's not necessary anymore (modrinth/knossos@371f14d) |
[ x ] TODO: Swap reading dependencies for reading manifest |
@Pyroglyph Something is wrong i can feel it |
Purpose
Currently, GDLauncher does not support downloading mods/modpacks hosted on the Modrinth platform. This feature has been requested in issue #768.
I'm aware of GDevs' other project ferium which already supports Modrinth, and also the
gdlib-refactor
branch (which I assume may eventually succeed GDLauncher?), but that branch is far from completion.Approach
This PR allows users to search for and install mods and modpacks hosted on Modrinth in the same way that they can currently be installed from CurseForge and FTB.
The implementation is highly based on the existing CurseForge/FTB installer code so it adds no new dependencies, which I see as an advantage.
Open Questions and Pre-Merge TODOs
Learning
I have read the Modrinth API docs (linked below).
Resources