Create initial Github CI flow

[m0j0hn]

Summary: Initial Github CI flow

What changed: Add initial Github CI flow

How tested: Github CI

[m0j0hn]

NOTE: WIP, needs some tidying up before merge - I welcome feedback about what we can trim out of this initial merge.
Note this is an initial version - it is incomplete, from a CI/CD perspective, but enables building branches on push and merge, and we can add release hooks as required.
Please take a look at the TODO tags in .github/workflows/main.yml for open issues

[ArneBab]

This looks like a good start. Thank you!

It will need some additional tightening of security before we can merge it:

• Without additional checking for user rights, there should be no automatic runs on PRs, because these allow everyone to run arbitrary code by simply filing a pull-request.
• There should be no permissions granted to the CI run to avoid exposing the github token (no permissions: entry).

[m0j0hn]

Thanks for the comments, let me look into this

[theoldbatosai]

Digging this one up.

The first way to control arbitrary code execution is to set '.github/workflows' as only modifiable by code owners. If a PR comes up with a "customized" workflow, an approval will be required. That's only the first step, but this is pretty well documented:
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

GitHub’s standard pull_request workflow trigger prevents write permissions and secrets access to the target repository by default.
And push is only triggered when we merge something.
You only get access to these if you already have write permissions on the repo.
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

Do you want me to take a stab at this or is @m0j0hn still around?

[ArneBab]

If you could take a stab that would be great! Thank you!

[theoldbatosai]

I can't figure out a way to take over this PR. I think I have to clone his repo and do my own PR. Or am I missing something?
Also, once I have something decent, I will need a core dev to set the restrictions on the .github directory.

[ArneBab]

@theoldbatosai you’ll need to clone this repo and then pull the branch m0j0hn:FREENET-7179, then you can work directly on the branch and file a new PR from your repo (just mention this PR in your PR so your PR will be found from here).

I’ll ping nextgens once you’re ready — he’s the one with the most experience on CI workflow security.

[Thynix]

@ArneBab You mentioned in your mailing list post about 1495 that this blocks release. Is that because you want to build the release with GitHub CI instead of locally?

[ArneBab]

@Thynix this blocks the release of Freenet 0.8, not of 1495. I’m sorry if that was unclear.

For the new point release we should have CI in place again so contributors can directly see whether all tests succeed.

See the blockers in https://github.com/freenet/wiki/wiki/Roadmap

[torusrxxx]

Is this still needed?