[CHORE] Adding to greasyfork

[artillect]

Since greasyfork is generally the main place to get userscripts for kbin, it'd be a good idea to get it posted on there. You can set up the greasyfork page to sync with this repo to automatically handle updates. It could also help get a little bit of the load off of GitHub when people install it or update kes.user.js, but all of the mods would still have to be loaded from GitHub.

We could also set up the mods as library scripts on greasyfork (also synced with the files here), which could open up this up to being more of a standard API for kbin addon packs (and further reduce the load on GitHub as well), but that's a bit of a crazy idea.

[aclist]

Interesting, didn't know it autosyncs. The main reason I avoided it was because I figured it would have to be a standalone thing, be separately managed, and doesn't provide proper support channels and stuff to actually keep track of the codebase in a standardized manner. Also got turned off by the ad spam, hahah. I agree that it helps users "find" the tool through their manager and sync.

[aclist]

One thing I'd like to pick your brain about is, would this open up the possibility of increased ambiguity with unsanctioned, potentially harmful copycat scripts? What if someone creates a malicious KES clone and posts it on greasyfork under a similar name? What's to stop users from inadvertently finding that one when browsing through their extension search menu? If we could say, "official KES sanctioned by the KES team is only available at this GitHub repository," it might allow us to skirt this issue, since anything on greasyfork or other userscript pages would be de facto not the sanctioned version.

What I'm getting at here is there is basically no "filter" with userscript pages, it's just a collection of scripts and it's caveat emptor for the user. Whereas it should be a lot harder to make a malicious repository.

Figured I should elaborate on that here, since that's at least part of what went into my decision to prefer a git repository with standardized entry point page.

I think we could also look at the possibility of checksums. Although not every user is liable to use them, at least we can point to a single source of truth and say, the X.X.X release has the checksum YYYY, anything else is invalid. For starters, I'll go ahead and use the GitHub releases feature to link releases to a specific tag, and list the checksums there.

[JasonMaloney]

What if someone creates a malicious KES clone and posts it on greasyfork under a similar name?

What if you don't post it to Greasy Fork, and someone else does? Better to protect the project name.

[aclist]

I'm totally open to whatever you guys wanna do, just throwing out fringe scenarios to do defensive design, as is my wont.

[artillect]

Since there's always gonna be a risk of malicious actors, I agree with @JasonMaloney, I think we should beat them to the punch. That way, when you search for KES on greasyfork, it'd be the first thing that comes up.

I like the idea of checksums, that'd be nice for people who are a bit more worried about what they're installing.

[aclist]

Well, I went ahead to set up the official account and encountered this:

Code uses an unapproved external script: <name>

This applies for all of the external requires. Rationale is described here: https://greasyfork.org/en/help/external-scripts

• Content delivery networks (CDNs)
  This option is out.

• Scripts with subresource integrity hashes
  I mentioned adding this before as a general security upgrade. I think it should be possible to add these hashes without it screwing up other -monkey variants, but I'm not sure. This seems like the most seamless approach since you are self-signing the dependencies.

• Greasy Fork libraries
  Seems like way overkill to host every mod separately in addition to this one. Maintainability nightmare.

• Injection of scripts from the origin host
  If we reverted to using the github.com TLD instead of raw.githubusercontent.com, this should theoretically work. However, we switched to the second one because the first one is just performing a redirect, so wanted to save a few cycles there. Also, this feels slightly less robust than using the integrity hashes.