go.mod: update influxdb-client-go to v2.14.0

[come-maiz]

The diff in influxdb-client-go:
influxdata/influxdb-client-go@v2.4.0...v2.14.0

[come-maiz]

We are packaging geth for debian: https://collective.flashbots.net/t/geth-go-ethereum/4873#p-10032-debian-packaging-1

For this we are reviewing the whole chain of dependencies, reporting issues and proposing updates where things haven't been touched in a while. Frequent dependency updates makes it easier to audit the changes, to test for any possible regressions, and to have a relation with the other projects.

In this case, the most recent influxdb-client requires https://github.com/oapi-codegen/runtime/ which was renamed some time ago. By updating this dependency, in addition to the usual benefits, we will be able to add the runtime library without any redirections. Everything is easier for the maintenance in Debian if the dependencies are fresh.

[fjl]

Hi @come-maiz, I do not fully understand your concerns regarding Debian packaging. Please elaborate on the build process used. If possible, please also link to packaging scripts that you are working on.

In order to produce a working geth package, the go-ethereum source is meant to be built with the exact versions of the dependencies listed in go.mod. Please do not build geth with other versions of the these modules.

For Ubuntu, we offer source debian source packages via launchpad.net. These packages contain a snapshot of the source code of all dependency packages. If you want, we can produce a source snapshot like that for use by Debian for each release.

[come-maiz]

Thanks for your words @fjl.

This project I'm working on is to get Ethereum binaries and libraries into the debian archive.

This is the intent to package bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890541
This is the wiki were I track our progress: https://collective.flashbots.net/t/geth-go-ethereum/4873#p-10032-debian-packaging-1

The launchpad packages are appreciated. They are not enough to be maintained in the debian archive. For this we have to get all the dependencies packaged and reviewed first, and not bundle, vendor or duplicate anything. This project started because for Flashbots research we need reproducible builds and risc-v support, and going through debian gives us also transparency, more maintainers and reviewers, more testers, and many other things that I can't predict and I'm sure will come :)

The thing with this PR is that if I package influxdb-client-go v2.4.0, I will have to package github.com/deepmap/oapi-codegen. In may 2024, this project was renamed github.com/oapi-codegen/oapi-codegen. So I would have to package the old version, a migration, and the new version. Which of course it's ok if I have to do it, not too complicated.

I want to do it differently, and also build a relation with the downstream libraries, upstream binaries and meta maintainers. By keeping the dependencies fresh, it will be easier to prevent a supply chain attack because the diff will be readable. We can also start noticing which dependencies are trustworthy, which need support, and which are suspicious. We can also start reducing the number of our dependencies to what's actually necessary, split big projects, collaborate differently. We are doing this bottom-up review and having these conversations as we find old and risky dependencies. Saying hi, meeting the humans, seeing who wants to walk together.

Those were a lot of words, and of course I have more :D Let me know if you have any questions.

[fjl]

I still think packaging all dependencies separately for Debian sounds like a nightmarish effort. Yes, one could in theory review all the diffs of all dependencies. But in practice, this is unlikely to happen.

Also, if you submit the dependencies to upstream, they will be kept up-to-date. But in some cases, we depend on older versions and go-ethereum will be incompatible with newer versions of dependencies. The Go module system will always select the oldest-possible version (MVS) but Debian does it differently. So in the end, when you build Geth with Debian and run the resulting binary, you are not running a tested mix of library versions.

[come-maiz]

If all the diffs of all the dependencies are not reviewed, then there's no way to ensure they are safe. Not everybody has to review everything, but some of us will have to do it.

The bigger issue I see is that geth has too many dependencies and they are too old. This doesn't have to be a nightmarish job, it can be good vibes and collective, this is what a community of maintainers brings. Along the way we can reduce the number of dependencies, split out autonomous projects, remove technical debt, I'm happy to assist.

I think I can make sure that the debian package uses the same dependency versions from the latest stable upstream. It's how this all started, looking into reproducible builds for the images that will run in TEEs for the Flashbots buildernet. I will ask about this to my Debian mentor.

We can also make some work between geth's CI and debian's CI to catch any integration issues.

[fjl]

I disagree that we have too many direct dependencies. We have been diligent about this, there are no unnecessary ones.

Regarding upgrading dependencies, it is not in our intention to always update everything to the latest version. We have been running this project successfully for a long time by sticking to known working dependency versions. For most libraries, upgrades are not necessary and do not provide any benefit, it's just work to update them and make matching compatibility changes in go-ethereum.

I'm just writing all this to you to give you a perspective for how we operate. You opened a PR to update a library for dependency reasons, and I'm fine with merging this if it's all you need, but I have a hunch this PR is just the start and you will want to add future library updates as well. You should just know we will only update dependencies if there is a real, tangible benefit to doing so. A dependency just having a newer upstream version is no reason for us to update.

[fjl]

For the wider picture, I think it could also be worth looking into an alternative to running full Geth inside of the TEE.
I doubt you need to run RPC requests in TEE, and you probably won't be reporting influxdb metrics from there either.

I don't know the details of FlashBots buildernet, but if it is just about block validation, it could use our zkvm guest program (cmd/keeper), which has way fewer dependencies. Or if it's about another core protocol function, we could look into creating a command-line frontend for it that performs the desired operation.

[come-maiz]

I know your operation is risky, when a security upgrade comes, it will come on top of many other changes. I see your development process, and I appreciate it has worked for you, so I won't insist on this. You are right that if I take care of maintaining and auditing geth and it's supply chain, I will be proposing more library updates before their changelog becomes unreviewable. For now I will explore keeper and packaging your current dependencies and see how that becomes. Thanks for the review and discussion @fjl :)