This is part of #3050, but thinking about this logically, the deprecation of v3 happens in just 3 days, so unless we want to have .NET 9 testing done in the next 3 days (unlikely?), it's not a great idea to let this break.
This will include a new ./TShock.Installer executable that will be for users without the dotnet runtime. This program will download the dotnet runtime, extract it, and then run ./TShock.Server for them using the downloaded runtime.
Note: only tested on osx, likely a no-go for linux/windows until more testing occurs.
Now, this requires some explanation.
Initially, we had the extract workflow, which did work. The problem is
that it can't commit to general-devel due to branch protection. If we
added a bypass that let it, though, it would enable anyone with write
access to this repository to write to general-devel (you can privilege
escalate easily).
Since we don't want that, this machine is setup:
1. TShock now triggers a workflow execution on a separate repo,
hakusaro/tshock_i18n.
2. On hakusaro/tshock_i18n, a modified extraction script exists.
3. The modified extraction script, targeting tshock, downloads and runs
itself.
4. @cardinal-system, a github user I control, creates and signs a commit
and pushes it back to tshock, bypassing branch protection (because is
allowed to).
Now, nobody except me can modify the code that controls the system that
enables @cardinal-system to commit to tshock, preserving that security
element.
But how is the workflow in hakusaro/tshock_i18n triggered? Through
another workflow of course.
The issue is that triggering requires using...a PAT. Who's PAT? My PAT.
Github just launched fine-grained PATs, so I created a fine-grained PAT
scoped to only the hakusaro/tshock_i18n repo, and only workflow
dispatches.
There are other methods that could be used to technically perform this
triggering using a classic PAT, but they require the `repo` scope, which
would give anyone with write-access the ability to write to
hakusaro/tshock_i18n, which is clearly not-desired.
I was originally kinda stuck, thinking I'd have to make a fine-grained
PAT on @cardinal-system but that isn't supported yet (you can't scope a
fine-grained PAT to another user's repo yet -- only all of your repos or
the org's repos, not a collaborator's repo). But the new fine-grained
PAT system enables creating a PAT that just has a small, isolated set of
things tied to one user.
This is the safest option, I think.
The only catch is that the trigger PAT will expire on October 20, 2023,
so it has to be rotated yearly, like the nuget token
(https://github.com/Pryaxis/TShock/issues/2669).
Fun stuff.
This removes shims in-place to fetch monomod from outside of nuget,
since monomod has pushed the applicable versions to their primary nuget
repositories, and because the dev builds add unnecessary complexity to
the CI pipeline if kept in place.
This also adds remote raspberry pi debugging with default install details. More testing is required as MonoMod may not be working for arm64 still
CI might not work yet either
Okay, now we're at problem 74 with github actions. Basically, github
actions doesn't send secrets to forks because duh, that makes sense. So
even if you make a super restricted token you still can't send it to
forks because github still doesn't understand how to make a security
platform when they just copy paste azure pipelines into github and then
say "well looks good to me" and ship fucking arbitrary code execution to
the entire fucking world and then try to retroactively fix all of their
mistakes and fail miserably in the process
Look, let's just be real here: GitHub needs to redo the entire
permission model for GitHub. There is no way to create a secure
combination of the following elements: post comment, edit comment, and
post status check.
If you want to be able to post comments, you have to authorize a token
or app to have full authority to do literally anything that the user can
do on a public repo. Full stop.
If you want to post a status check, you have to give the user write
access to the entire repo, which makes the first issue a problem.
You can't just explicitly make a token that says "only allow this user
to post and edit its own comments" and "allow this user to post status
checks" because write access on the repo implies authority over all
other issues/PRs opened by other people.
Now Cardinal's token is restricted to just status checks, and we're
using a different action.
Thanks a ton for the huge mess Github.
This change uses Cardinal's PAT for GitHub Actions CI. The way this
works is very convoluted, but it makes sense in theory.
1. Cardinal is a member of the Pryaxis org, in a group called "untrusted
robots." She has write access to Pryaxis/TShock, so she can create
status messages. This is because GitHub only allows status messages to
be created if a user has write access.
2. Cardinal has a PAT, and that PAT only has access to creating
repository status messages.
3. Danger requires permission to post comments and update CI status.
4. Cardinal's PAT is only authorized to create repo status messages, and
cannot privilege escalate.
5. GitHub implicitly gives everyone the ability to post comments on
public repositories.
Thus, this really interesting and weird flow should mean that Cardinal
can post comments and update status messages, by having write access but
functionally being unable to use it.
At least, that's the theory.
This commit adds Danger via GitHub Actions. Dangerfiles are ruby files
that have a DSL for interacting with GitHub. They can do arbitrary
things. See: https://danger.systems/reference.html
The point of this commit is to automate the process of asking people to
update the changelog. This is a really really annoying thing that we
have to do too often. Editing a pull request will automatically re-run
the check.
Truly trivial commits can be marked as trivial easily by using the
hashtag trivial in the PR body. This is really just useful for actually
trivial things. Most commits actually do need to have associated
changelog entries.
