Modification of EIP process to account for security treatments

Process Improvement
21

Not joking at all. And this workflow if it ships makes my argument a bit stronger.

I am a bit concerned about the low barrier to post a CVE, which is mostly busywork if not done through tooling like github. But that would be a signal that someone posting the security notification thinks its worth the effort of following the CVE process. And I am assuming there is interest and desire in the CVE community to keep it high signal so it doesn’t devolve into NNTP levels of spam.

That is what I am hoping for by offloading the decision of “what is a security issue” to another team, it is a team that has vested interest in making their signal of “this is a security threat” high. (and then the ordinals CVE hit…)

1 Like
22

Ugh it seems a tidal wave of generative-AI spam is already headed for CVE pipelines and FOSS maintainers alike:

23

I opened an issue on EIPIP about one possible way of publishing documents that update finalized documents modeled on how IETF RFCs do it:

It’s not a perfect solution but I think it might be enough for everyone to get what they want

24

Maybe… just maybe the answer isn’t to provide authority to specific authors and rather provide authorities to groups and roles. This way the people who fill the roles and groups can continue to provide authoritative answers to “who determines it’s a security issue” rather simply.

I wonder if any other groups have tried this before and it worked for them?

2 Likes
25

As I understand it, at least one editor actively doesn’t want the editors to have that role. IMHO that’s unfortunate, but apparent.

So the challenges are defining a group that would collectively take on the role, and keeping that group viable and trusted. This is hard. We’re talking about money, as @Dexaran noted, so there are incentives to behave badly as well as imperatives to make a real effort to get this right. (At least a moral one not to have people losing badly, and a self-interested one to make sure this ecosystem is trusted enough to succeed as a platform).

I contribute to a security specification for Solidity smart contracts that might be something of a model for a set of criteria to measure against, making the decision less about one person’s personal motivations and more objective. @SamWilsn is right that if this were easy to solve we would have automated the whole thing years ago - and we haven’t because it isn’t. Under all the turtles, we rely on consensus-building and honest response to challenges as a proxy for truth, the Ethereum way.

But some - an increasing amount - is automatable. There is also a lot that people will agree on even though they have disagreements of varying intensity. Having a mechanism that captures at least the bulk of that with a more opinionated stance than “DYOR :person_shrugging:” as @bumblefudge has proposed seem valuable. It still needs some humans to take some responsibility, and without understanding how we get that, I well understand @SamWilsn’s reluctance…

1 Like
26

Are the EIP/ERCs consider the same as a pseudo-legal deed? (read covenant without endorsement). Here are some SEPARATE suggestions as to what a huddle of lawyers have come up with over the centuries:

  1. For each and every EIP/ERC have append-only Corrigenda section - this reflects that the early specs might not have enough eyeballs or some quirky EVM implementation might have unanticipated outcomes (cf historical Intel hardware floating-point bug)

  2. Incise within the Security section an instrument for opt-in register of contracts to be notified in case there are future Deed of variations … this does shift away from the presumption that the EIP is treated as atomic doc.

  3. Have a separate opt-out registry (including originating authors) of contracts/people/orgs to be consulted if there needs to be changes, this is most flexible as could be either a revised later EIP or just some side-notes on implementation/operations. However this creates longer term technical debt but could also be useful for forks to evaluate/compare then reversion before the final call.

ECH appears to be a volunteer activity (correct me if wrong) so hiring experts would be a major change of ethos. On the other hand, with the recent split in EIP/ERC, there may be space for Application Specific Knowledge (ASK) domains in law, accounting/auditing, and secOps/cyberSec. Think of it as a functional constituency or a roster of volunteers available to call upon. However, it does bring up another thorny question of remuneration (having experts like lawyers on contingency is not cheap). 2&3 may be doable within github with a bit of one-off scripting.

1 Like