Setting up permissions for collaborators to perform releases

[ccd0]

To perform a release, you need access to three things:

• this Github repository
• the repository on 4chan-x.net
• the Chrome webstore (for stable branch releases)

I'm not sure who will be interested in helping with releases if I'm not available and who won't be, but I've invited some people as collaborators here. Next step for those interested is setting up access to 4chan-x.net. For that I'll need SSH public keys from everyone to add to authorized_keys on the 4chan-x.net server. I'll have to investigate what will be needed to get Chrome webstore stuff working, if that's even possible. If it requires paying Google $5 or whatever, and if you're not interested for that reason, I can handle the webstore uploads, possibly with some delay (I only release stable builds to the webstore, so it won't be needed as often anyway.)

[paradox460]

You can use either (preferably both) of my keys, available at https://github.com/paradox460.keys. I also will sign most commits with my GPG key at https://github.com/paradox460.gpg

The ssh-ed25519 one is my modern preferred one, but I've got access to both still

[pentargency]

Thanks, I like 4chan X a lot and being able to directly improve it will be better than maintaining some personal fork. I'll remove my 4chan-xl fork for simplicity's sake.

My SSH pubkey:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDSi4FaDRBVYzmjbYNoM1h+k/r/Sb/0u2fVA8IKG+ibmOvuVJyAK6XFgxSVToY/V2Go5naP6MzmZX8MVRGOx1UYlpDC5NVTAjghw2dcizh3Xds8nczneNXsTU3GgRzJ1xxZoNuwRHFMZZNPx+SI3Kgv8PYZ7dw7CCepirDUqM3hhSuvMiZRUXStHN+reUiLJ6KvZ/kQiItLmzk9fLlPbaoBigpWylJuoAmTrCC1EfH6JkmLCqP8Ns8ZI63ObwlYmSVBmCAJwhh8K/K743i78jjfe9GLBSo0t6Uv+RwLTKJkVV/VdETHGMvMzjv6pB0JMXf8lPUxxr8h+ngbiT6M/jaDbM9XeJxZeK7yR2MkJaDP3DUWlWnsq6SKPx8g30g/Vy7uBy6/qfWC7z+1l1Vqa63WKO3iDQYKTCLtaDbtASEtG6v9iaOI0wQDyJrUBzl9NN8LvfpqJwLz7MS0d6C97AsOiig4Rn2A7IV4eLQ9j9UFdG4f592hjtCxo+Vycn4F1qs= [email protected]

I don't mind the $5 itself, but I don't want to link a real phone number with this identity for the on-login 2FA requirement - this is what stopped me initially. If this needs to happen in the future, I'll get a new physical security key to circumvent the phone number requirement.

I'm not sure how much active management of the project you want to perform. I'm accustomed to working fairly autonomously, but don't want to fuck your stuff up by just taking actions. Beyond making sure releases contain useful, tested changes that are relevant and unproblematic for the extension, do you have any "philosophies" here surrounding features and releases? I am a general fan of a maximalist 'kitchen sink' approach to software in terms of options & features, which seems to align with what's going on here already. If pulls or features could be useful, not harmful to the project, and won't get in the way if unwanted, I'm prone to include, fix/test, and release to beta when some have accumulated (or when a fix has got to go out). If beta doesn't blow up after a bit, to stable. Does this all align? If so, I can just begin working on all this stuff in my downtime.

[paradox460]

For webstore, might it be possible to have uploads triggered by Github Actions? You could put your creds or whatever in the repo secrets, and then the action could just run on releases getting tagged

[ccd0]

Might be possible, but right now I can't even upload stuff there myself without manually logging in. Any automatic tool for that is likely to break.

[ccd0]

Beyond making sure releases contain useful, tested changes that are relevant and unproblematic for the extension, do you have any "philosophies" here surrounding features and releases? I am a general fan of a maximalist 'kitchen sink' approach to software in terms of options & features, which seems to align with what's going on here already. If pulls or features could be useful, not harmful to the project, and won't get in the way if unwanted, I'm prone to include, fix/test, and release to beta when some have accumulated (or when a fix has got to go out). If beta doesn't blow up after a bit, to stable. Does this all align?

The flow of releases you've described is pretty much what's done already, yes.

On kitchen sinks, 4chan X is kind of a "kitchen sink" by its nature, although we should be careful not to make it too bloated. Usually the fact that someone took the effort to make a working pull request is a sign something is important enough to someone to be worth including. Still, we should discourage things that significantly increase the size of the extension, would require a lot of maintenance work, harm security or privacy, are too dependent on third-party servers, or would put undue stress on the archives. Probably most of that is common sense.

It's worth noting some security policies I've been following. It was once the case that HTML injection attacks were easy to find in 4chan X if you just looked through the source code thoroughly enough. To prevent this sort of issue, HTML generated by 4chan X needs to be easy to check at build time. Strings are assumed unsafe by default, and strings deemed safe are marked as such by turning them into an object of the form {innerHTML: 'safe HTML goes here'}, which can be used to set the innerHTML property of an element by $.extend. The code that generates such objects is then kept to a minimum. 4chan X also avoids creating vectors for third parties to inject HTML into the site; for example, in posts loaded from archives, the markup-related HTML tags are added by 4chan X by parsing the BBCode-style tags sent by the archive.

4chan X does not use eval or equivalents to execute arbitrary code at runtime. Sometimes it has to insert scripts into the document to execute something in the document context (this is done by the function $.global), but $.global is always called with functions that it converts to strings, never with strings, and certainly never with something generated with data only available at runtime. Any feature for which 4chan X would have to execute user-provided Javascript is rejected. The issue with such features is that if an exploit manages to execute Javascript on 4chan, it would be able to silently modify a user's settings. If Javascript was executed based on a user's settings, then malicious code could use those settings to persist itself. The only exception made is for javascript: links, such as in the header or "Sauce" links; these are deemed less dangerous because the user has to click on them, and browsers display the URL of the link on hover.

Another security issue we have to worry about is prototype pollution. As it stands now, 4chan X has a lot of code that could easily create prototype pollution vulnerabilities if someone made a mistake. These will need to be converted to ES6 Map (probably after/during the migration away from CoffeeScript). Until then, be very careful with code that uses objects as dictionaries, and be sure to always create new objects used for these purposes with $.dict which calls Object.create(null).

[ccd0]

Just realized that since the .crx files are signed by a private key under my control, that I need to set up a method to sign those releases, either manually or automatically. Maybe it could work as follows: Contributors would release a build on this repository, and the builds folder would contain a userscript version and a Chrome extension version, uncompressed and unsigned. We probably only need one version of each, because there isn't much difference between them, and I could easily write a script that converts one to the other. It would probably be most convenient for the original version to be the version that pulls updates from the beta channel, since that's what I use normally and what I would expect developers to use normally, and that way I don't have to switch back and forth between different copies of the script when developing. Plus those who would install directly from the repository would most likely want updates from the beta channel. Then, possibly after a quick manual code review to make sure nobody was doing anything malicious, or possibly automatically, I could produce all the necessary builds and upload them to 4chan-x.net, and also to the Chrome store, if applicable. At the same time I would update the beta and stable tags. Thoughts on this plan?

[paradox460]

Thats probably going to be the safest way for you to do it without exposing your signing keys.

Would still probably be good to have the nightlies/tagged beta channel releases automatically built by an Action. Even if they're unsigned CRX, its useful for side-loading. I'm not sure what capacity auto-update is for sideloaded CRX these days, but that might also be an option.

[ccd0]

I'm not sure that unsigned CRX exists. Maybe you're thinking of unpacked CRX extensions, which is exactly what the tagged versions (uploadable by contributors) would include. I could link to these from the changelog.

I'm also thinking about getting rid of the "noupdate" builds on the grounds that the right way to turn off updates is to uncheck the relevant setting in your userscript manager, or alternately remove the update URLs yourself. If nothing else, I think I'll stop linking them from the changelog. I suspect a lot of people have installed builds from the changelog not realizing that they're the builds with the update functionality turned off.

[saxamaphone69]

Regarding the uploading to Web Store stuff, does anything used by these extensions help?

• https://github.com/openstyles/stylus/pull/1407
• https://github.com/PlasmoHQ/bpp
• https://github.com/violentmonkey/violentmonkey/blob/master/.github/workflows/release.yml#L50
• https://github.com/refined-github/refined-github/actions/runs/5033653036/workflow