Explore the possibilities of code signing for improved security / integrity verification

Code signing

Description

Marking as both a bug and an enhancement because it may become really scary one day.

First of all, I must admit that I am a total newbie to this concept, and I'd like to thoroughly understand anything (and, most importantly, why it works or doesn't work) before implementing it.

This is disquieting not mainly because the patcher executables may be tampered with, but because every patch can contain self-updating binary hacks.

Everyone with write access to the JSON files of a patch can have code execution in the context of the game process. While this openness is certainly one of the main aspects about this project, it can just as easily be abused.

The main problem here is that we want to keep a low barrier of entry for this whole patching thing on the technical side too (even though this is hardly used), yet also want to ensure security somehow.

Once we have a working system in place, we can also have patches that come with self-updating plug-in DLLs.

Prerequisites

• Probably requires Flagged Revisions on the wiki side, combined with a way to automatically sign a patch file upon flagging, to really work.
• If automatic signing based on wiki logins even is a good idea in the first place.

Implementation

• Provide two separate versions of thcrap on thpatch.net: A regular version with all the code signing enabled, and a developer version that doesn't have these features. The latter will have a big "this version may pose a security risk, only use it if you know what you're doing warning.

Start by investigating how thcrap patcher executables, patch JSON files, and self-updating plug-in DLLs are distributed and executed. Review the proposed Flagged Revisions and automatic-signing workflow, then define a security model that preserves a low barrier for developers while verifying trusted patches and clearly separating regular and developer versions.