You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But for the .json and .json.asc, it's just a https to github with no fallback. Just a gut feeling is that the github https should be the default not the fallback. Reasoning is that it maintains an accurate download count, and that the .json is fundamentally more theoretically attackable. For example, it could potentially crash the client by deserializing a large number of libraries idk. Again just a gut feeling.
I verified that this will work, because if you scroll down in that discord convo linked above, sending him the json worked, meaning that his installer was correctly able to fetch the .jar from the same https://github endpoint.
The text was updated successfully, but these errors were encountered:
Our security model doesn't require https, given the GPG signatures.
This crash https://pastebin.com/MrVQ0kb6 from https://discordapp.com/channels/208753003996512258/222120655594848256/679408095033688077 demonstrates that some people just have completely broken https certs. Minecraft's launcher gets around this and allows us to download from github though.
We use http for http://impactclient.net/releases.json, with a fallback to the https://api.github.com endpoint
But for the .json and .json.asc, it's just a https to github with no fallback. Just a gut feeling is that the github https should be the default not the fallback. Reasoning is that it maintains an accurate download count, and that the .json is fundamentally more theoretically attackable. For example, it could potentially crash the client by deserializing a large number of libraries idk. Again just a gut feeling.
Anyway, let's add like, idk, something like http://githubproxy.impactclient.net/Impact-4.8.3-1.13.2.json (note the http!) that proxies https://github.com/ImpactDevelopment/ImpactReleases/releases/download/4.8.3-1.13.2/Impact-4.8.3-1.13.2.json and same for .asc. We would NOT do this with the .jar, since that isn't fetched by the installer, and instead by the launcher.
I verified that this will work, because if you scroll down in that discord convo linked above, sending him the json worked, meaning that his installer was correctly able to fetch the .jar from the same https://github endpoint.
The text was updated successfully, but these errors were encountered: