Security process

[jankapunkt]

As already mentioned in the old discussion this project is highly security relevant:

What you gonna do? Issue is also, that this is a security relevant product. If you have a not trustworthy contributor/maintainer which puts malicious code into the product, then alot of companies will be hackable. But on the other hand, we can have a critical community and make it necessary to have x approvals before the maintainers can actually merge into master. I would also agree that new maintainers need to disclose their identities and who their employers are, so that making them to be maintainers does not mean to make a malicious anonymous able to taint the code.

I agree a lot with this. How do we want to ensure a high security in this project at all stages?

Also: assuming there is funding, do we want to get an independent security audit for certain releases?

[jankapunkt]

We should also think about signed commits, so we can reduce the hypothetical chance of someone bringing malicious code into the repo using the account of one of the maintainers.

[jankapunkt]

Another thing would be: https://docs.github.com/en/organizations/keeping-your-organization-secure/requiring-two-factor-authentication-in-your-organization

[oklas]

Inserting malware on behalf of a maintainer is only one of the attack vectors.

This hypothetical situation is possible in different ways. If malicious user have access to maintainer account, then signed commits will help. However, if it does have access to the maintainer workstation, then the malicious user will probably be able to sign the code. Two-factor authentication complicates this if the workstation is not a phone. (At this point, I first thought there was a reason not to enable the phone function in the Mac or any laptop)

Another question is whether there will be an opportunity for all people to contribute pr. Who should sign the pr?

The most important thing is that whoever contributed the code may not seem malicious at first glance, as a rule, the vulnerability is discovered by the hacker and not the developer. Otherwise, this code would not have appeared and we would not have known such a phenomenon as vulnerability.

I would also like to mention the importance of maximizing the effectiveness of taking action if a vulnerability is identified. One the idea I suggests in #25.

Of course code review by maintainers and all the possible verifications must be perfomed.

[jankapunkt]

What about using a static code analysis (semmle / Codeql)? It's provided by GitHub itself (like dependabot) and just one step away from setting up.

[jankapunkt]

@HappyZombies @jwerre any thoughts from your ends on this? I could easily setup CodeQL for static analysis for vulnerabilities, that's a no-brainer imo. For the rest I think we should discuss this tightly in coordination with #36

[jwerre]

This was one of my biggest reservation with using this package at all. I don't think we should be going crazy inviting maintainers to this project—it should be pretty tight. Requiring 2FA and signed commits sounds like a pretty reasonable approach.

[HappyZombies]

@jwerre and @jankapunkt for the time being, I will be requiring two factor authentication for members in the organization. We can look into signed commits at a later point (could be our next area of focus), same for static code analysis (since I am certain a whole bunch of issues will be occurring). We can add this stuff in our next release we have.

I think we are at a good point to release what we have in development right now, I can talk about it more in #36

[HappyZombies]

Closing in favor of #121