Move canonical core-geth pointer to ethereumclassic org#1678
Move canonical core-geth pointer to ethereumclassic org#1678realcodywburns wants to merge 4 commits intomasterfrom
Conversation
Removed GitHub Labs entry from the UI configuration.
✅ Deploy Preview for ethereumclassic ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
realcodywburns
added
the
scrutiny required
There was a problem hiding this comment.
Pull request overview
This PR updates the website’s canonical references for the CoreGeth client to point at the ethereumclassic/core-geth GitHub repository and removes the ETC Labs GitHub link from the global footer social links.
Changes:
- Removed the
etclabscoreGitHub organization link from the footer social items. - Updated the CoreGeth client entry to link to
ethereumclassic/core-gethfor repo, releases, and support.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
content/ui.global.yaml |
Removes the ETC Labs GitHub footer/social entry. |
content/development/clients/index.yaml |
Updates CoreGeth links to the ethereumclassic org (repo/releases/issues). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
+1 — fully support this move.
To put a finer point on the governance gap Cody describes: etclabscore/core-geth went 21 months without a release (v1.12.20 in June 2024 to v1.12.21 two days ago), yet the codebase was sitting on Go 1.21 (EOL since August 2024), with 20 known vulnerabilities (9 with confirmed call traces via govulncheck), including 4 named CVEs in the cryptographic subsystem.
These vulnerabilities were raised to the current maintainer on multiple occasions — through both the project Discord and repository issues (e.g., etclabscore/core-geth#692) — without resolution. When v1.12.21 was finally pushed two days ago (etclabscore/core-geth#694), an independent security review has already confirmed it is still missing fixes for CVE-2025-24883, CVE-2026-26315, and potentially CVE-2026-22868 and CVE-2026-26313. This isn't intended as a personal criticism, but it does illustrate the structural risk of placing sole responsibility for the network's primary client on a single maintainer. When that single point of contact is unavailable — or rushing patches without adequate review — the entire community's security posture suffers.
White B0x Inc., on behalf of the Ethereum Classic DAO LLC, has already begun submitting security patches to ethereumclassic/core-geth.
Every one of these patches is submitted for proper multi-maintainer review — the standard that should apply to the network's primary client.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
Would like to hear @diega 's take as he's involved directly. My main concern are the implications on decentralization, as having a completely separate maintainer from the community org has advantages, a separation of concerns, if you like. It needs more discussion, and a formalization of duties of maintainers / approvers. |
|
I think this goes in the wrong direction. |
|
it is not appropriate to ask network participants to pull from random dev repos. This repo is a neutral location and the most appropriateplace for the code to live. core geth is the reference client and the software that the network recommends users download and run. All ci/cd pipelines can be run here and users can find ecips and history. |
|
nack - having client code in different locations helps separate concerns and prevents centralization. Unifying client code under the ethereumclassic org may give people an undue sense of 'officialness', and the governance process determining what code is included certainly need further discussion. Do not merge this. |
IstoraMandiri
left a comment
IstoraMandiri
left a comment
There was a problem hiding this comment.
Needs further discussion
|
ethereumclassic/core-geth#33 Scrutiny required as this move seems to be part of the Olympia discussion. What are the true intentions of this PR? 
|
This PR updates the website to point to ethereumclassic/core-geth as the canonical client repository, replacing the current link to etclabscore/core-geth and remove the link to the etclabscore repo from the footer.
Rationale
The ETC core geth client is a community asset. Many other core ETC repository — ECIPs, the website, community calls — lives in the ethereumclassic org where changes require review from multiple maintainers before merging. The client is the exception, and that exception creates a governance gap.
The recent v1.12.21 security release illustrates the gap concretely. It was a valid and necessary fix, but it was merged to the production client without prior visibility to other contributors or community maintainers. For a security patch that's an understandable tradeoff. As a general operating model for the canonical client, it isn't.
Moving the canonical pointer to the community org establishes that:
Scope
This PR changes the website link. CI/CD pipeline migration to watch the ethereumclassic org repo is a follow-on coordination item and does not block this change. The intent is to establish the governance standard; the technical migration is low-lift and can follow.
This is not a personnel change. The Coop's role maintaining the client and the bootnodes is unchanged. This is about where the community's official reference to that work lives.