Reproducible Builds

Hi!
Right now I am just a consumer of open-vsx. For some dumb reasons I just assumed that Open-VSX had reproducable builds. I noticed that at the end just binaries are uploaded.

It would be awesome to strive for something close to f-droid.org to prevent supply-chain-attacks through the Open-VSX Store. Yeah, you need to trust every publisher (thanks for implementing that!) - still you have no real way to trust them.

* On the one hand you need to trust the code (for small extensions you could manually look through the code - gets complicated for bigger repos).
* On the other hand you need to trust that the published code matches the compiled version.
* Also you need to trust the dependencies.

With this Feature Request I am just tackling trusting the binary matches the source. I think the anecdote of [lzma](https://github.com/tukaani-project/xz/commit/e93e13c8b3bec925c56e0c0b675d8000a0f7f754) shows that the attacker there only included the trigger for the vulnerability into the published binary, not into the source code. So state-actors might be afraid of this level of transparency if they can avoid it.

I acknowledge that having every app reproducible is a far way to go. I guess this are some steps in between like for example:
* [ ] Make a check if the binary is equal to one released by either a trusted GitLab CI Runner or a trusted GitHub Actions Runner (some random self-hosted runner is not trusted). Mark binaries accordingly in the UI.
* [ ] If a project automatically buildable with yarn is found, allow to download Artifacts from a CI controlled by you. (Maybe only for more popular extensions?; Are the build-actions typically named the same in packages.json across projects?)
* [ ] If this is to expensive in processing power, find a sponsor for them.
* [ ] Test a few projects on what the biggest hurdles for reproducibility are.
* [ ] Write documentation on how to build projects in a way that is reproducible with your infrastructure.
* [ ] Mark reproducible builds as reproducible in the UI.
* [ ] Require extensions to be reproducible.

Issues I think about are:
* How to know which Git-Tag matches which released version?
* Non-reproducible build-sections
* For zips, there seems to be https://salsa.debian.org/reproducible-builds/strip-nondeterminism/

Thanks for reading through this long bug report. I really hope there can be progress in creating a more secure Open-VSX.

Best,
Thomas

Begin by reviewing the extension publishing flow and the UI that displays binaries, then inspect how GitHub Actions and GitLab CI artifacts are handled. Compare a few yarn-buildable projects and document reproducibility hurdles, trusted-runner checks, and source-to-artifact matching before defining a focused first milestone.

Written by the indexing model from the issue text.