Outdated version of the `zap` logger, with multiple wrappers within Gorouter, used in Routing Release

[peanball]

No. I couldn't find CVEs for zap.

Issue

The version of the zap logger used in routing-release and thus Gorouter is pinned to a version from 2016. The API has since changed significantly in newer releases. Performance characteristics may have as well.

Additionally, and potentially worse, there are two wrappers (lager + logger) that ultimately write into zap. The major issue with that is how the wrappers handle auxiliary data to be logged. The data is pre-processed without taking the active log level into consideration.

Each debug statement will actually pre-process and wrap data into zap.Field, just to never be logged in 99% of cases. There are means for lazy evaluation for such data, but they need to be handled explicitly, e.g. in such wrappers.

Affected Versions

Probably all version from 2016 onwards.

Context

As stated above, the zap library is significantly outdated. Furthermore, the wrappers are inefficiently handling auxiliary data when it ultimately will not be logged.

Traffic Diagram

N/A

Steps to Reproduce

N/A

Expected result

We have an up to date version of zap to get functional, performance and security improvements.

We don't waste additional cycles on preparing data that will ultimately not be logged.

Current result

See above.

Possible Fix

Remove the version pin for zap. Adapt, rewrite or remove the later + logger wrappers. Alternatively, one wrapper could remain if we don't want to tie ourselves to zap. A lot of the code is tied to zap however.

Very alternatively, we could use golang 1.21's slog feature. That also has a zap backend.

Considering that the rift between 2016 zap and current zap is huge, a lot of the logging code would need to be rewritten anyway. If we tackle this larger undertaking, we might also do it the best way available at the current time. Opinions are welcome.

Additional Context