We have a kick-off call Monday, September 30th at 3 PM EDT with Trail of Bits to start the audit. The scope is the same as the OP, here are the engineer details:
Sefan Edwards and Sam Moelius will begin the review going 9/30 - 10/11
Josselin, Sam, and Dominik will then complete the review from 10/15 - 11/1
Each week will have a summary report which will allow us to start working on found issues during the audit. I hope to set up a channel in the new discord with all auditors and relevant Status CCs for quick communication on issues found.
I’m working on their plans w.r.t. @rachel’s question about branch management. Will update with details there when I get them.
So for comms during the Audit, ToB would like to create a specific channel in their slack and invite members to it. There reasoning is a-few-fold:
they can bring in resources of experience easily when needed, as everyone in the company uses that slack as their main comms
they want to maintain chat history of the review
they asked first
The question now is who would like to be included into this? Your goals would be to keep up with the discussion and real-time findings, ask appropriate questions as well as answer any clarification needs they may have when doing things.
I know we all LOVE having extra chat clients open and watching them, but this is a short term thing, and quite important.
In the past audits with ToB, they cloned a repo to a private repo within the github.com/trailofbits org to keep discussion private until we publicize the finalized report. The only thing here would be to decide which exact branches they do this with, or if it’s even a reasonable thing to do.
Tags are a snapshot at a specific point in time, so they’re perfect for this use case. “We need you to help us test v1.0.5” means they can check out the v1.0.5 tag and know that will never change.
This way they can use our repository, and we can create a separate private repo under the status-im organization where only issues are created to track security concerns (and, as a result, we control access so we can invite whomever we find pertinent.)
Edit: I should say that tags should be used as a snapshot as a specific point in time. As long as we treat tags as immutable, we’re good.
For status-protocol-go HEAD is fine, some parts of the codebase are not used by v1 by status-react, only by status-console-client (different client), so those strictly speaking don’t need to be audited, I can provide more details if necessary.
Not sure I understand this, but the commit above is not even merged in the develop branch nor is ready, it turns out there’s more work to do as we currently store the master key and that needs changing. (This might require a change in status-go as well as we need to store the address of the key 1581).
The PR is ready now https://github.com/status-im/status-react/pull/9096 , I need some input from someone from the keycard team, as I don’t own one myself and can’t test the functionality with the keycard (as far as I can see, it should still work, but without testing it I can’t be sure), no change in status-go was necessary.
The commit hash can only be used though once merged in develop, as there might be some extra changes + we rebase against it, so it’s likely to change.