10

What defenses does an Open Source project utilizing the Collective Code Construction Contract (C4) have against unknown developers who may have intentions to merge malicious (but not immediately recognizable as such) code?

http://rfc.zeromq.org/spec:16/

A general answer will suffice but to learn more about my specific reasons for asking this please read these dev logs: https://getmonero.org/2016/06/05/overview-and-logs-for-the-dev-meeting-held-on-2016-06-05.html

  • 3
    Having looked at your links for a few minutes, I haven't yet learned what about C4 in particular complicates the general issue of people submitting secretly malicious code. Could you summarize the relevant parts of C4 in your question? The links are definitely helpful, but they're quite long, and I'm not sure what I should be looking for. – apsillers Jun 13 '16 at 13:59
8

Based on what I read the safety is that the process happens in the dev branch not master. Essentially no harm is done as long as someone spots the problem within a reasonable time period:

for i = 1 to 180 days # 6 months of 30 days each, this is a magic for loop that knows when a day passes { 1. new PR gets eyeball review 2. PR is merged to dev branch 3. if merge == crap, new PR made to address crap, goto 1. elseif, goto 4 4. if i == 180, merge to master. elseif, goto 1 }

https://forum.getmonero.org/4/academic-and-technical/2556/c4-discussion

The system allows ample time for review but is not perfect. Backdoors are always possible and commits from new contributors should always be looked at carefully even as they are assumed to be trustworthy IMHO.

The goal is to be seen as welcoming to new contributors.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.