Post-Judging QA #412
Replies: 7 comments 19 replies
-
I don't think #123 is invalid. I believe the label Invalid should be reserved for issues that are false. At the very least this is a Non-critical/Low. Although it seems similar to issue #232 my issue does not mention other proposals, only malicious admins and also accidental overwriting of quorum parameters in the same block (leading to surprise by the proposer). Given commentary by sponsor @davidbrai (in #232) , the impact is probably low enough to downgrade this to Low Risk but in that case I feel that perhaps my QA report score should be reassessed. As I mentioned above I believe "Invalid" should be reserved only for those findings that are factually false. |
Beta Was this translation helpful? Give feedback.
-
M03 - Lack of zero address check (#318 and other dup instance) In all earlier judging this issue has always been marked QA. I think in this case also this should be downgraded to QA |
Beta Was this translation helpful? Give feedback.
-
#284 I think there is some confusion, this is agreed as valid by Product team and also this is possible to happen. Request you to kindly check |
Beta Was this translation helpful? Give feedback.
-
I will review the issue soon, but this contest have an overwhelming amount of Low/QA issue submitted as High/Med risk. I decided to judge those as invalid if they are obviously low risk or known, otherwise it would be encouraging people to submit all Low / QA item as individual issue and see what sticks. |
Beta Was this translation helpful? Give feedback.
-
I think there may be some confusion. I'm not talking about hijacking of the admin account. I'm talking about the "rug pull" scenario. The whole point of providing source code for people to review in the DeFi space is to increase the confidence that users can have in the application.
If the possibility exists, in code, that a rug pull could happen then it should be fixed, in code.
Otherwise we might as well have centralised apps with closed source, and just trust people to do the right thing.
But perhaps I misunderstood what you meant in your reply above.
…-------- Original Message --------
On 20 Sep 2022, 16:01, gzeon wrote:
> I wouldn't mind there being a little more consistency on the "untrustworthy admin" criterion. In many contests I see "setFee to 100%" bugs which, because they are not prohibited by an untrustworthy admin, are labelled as Medium because one could do that.
>
> In the case of NounsDAO and [#123](#123) an untrustworthy admin could set the minimum votes higher whenever a particular user makes a proposal, and then immediately change it back in the next block. Since it could happen, who's to say it won't one day? We shouldn't necessarily be taking the real-world trustworthiness of the NounsDAO project into account. The code should prohibit things that could cause harm in this way.
The admin is the gov timelock I think the risk is really low compared to a EOA or multisig
—
Reply to this email directly, [view it on GitHub](#412 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAA5TLVKGV63Z3CKWX7KANLV7FHMPANCNFSM6AAAAAAQK3MXOQ).
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi @gzeoneth , my L-05 is the same as M-03. https://github.com/code-423n4/2022-08-nounsdao-findings/blob/main/data/0xDjango-Q.md |
Beta Was this translation helpful? Give feedback.
-
🧑⚖️ Post-judging QA
The judge for this contest is @gzeoneth
Reminders
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions