github.com/tmthrgd/go-hex has been unmaintained for ~7 years (last commit 2019). We'd love to use bun but our SBOM/supply-chain scanning flags it as an abandoned dependency. Since bun uses only two API-compatible functions from it afaik, I'd like to propose to replace it with the standard go library encoding/hex.
Where it's used (quick search in the repo)
The dependency is imported in internal/hex.go - aliased as fasthex, using:
fasthex.EncodedLen(...)fasthex.Encode(...)
Every other hex reference in the codebase (again quick search in the repo) already uses stdlib encoding/hex. It's listed as a direct dependency in the root go.mod and as // indirect across the dialect/example modules.
Why we'd want to replace it
- It's currently unmaintained: if a defect/vulnerability were found, there's no upstream to patch it. (There are no known CVEs today — currently this is only a maintenance/supply-chain concern)
- A dependency could be droppen: rather than swapping one third-party lib for another -
encoding/hex is maintained by the Go team and patched through normal Go releases.
- AFAIK it would be API- and behavior-compatible:
EncodedLen and Encode have identical signatures and semantics, so the SQL output should be unchanged.
The only tradeoff I can see
go-hex provides SIMD-accelerated encoding, so stdlib encoding/hex may be slower when serializing large []byte/bytea blobs. I guess for most workloads this is is probably negligible, but maybe someone can include a benchmark on a representative blob size if maintainers want to quantify it before deciding.
Happy to open a PR if this direction is acceptable.
github.com/tmthrgd/go-hexhas been unmaintained for ~7 years (last commit 2019). We'd love to usebunbut our SBOM/supply-chain scanning flags it as an abandoned dependency. Since bun uses only two API-compatible functions from it afaik, I'd like to propose to replace it with the standard go libraryencoding/hex.Where it's used (quick search in the repo)
The dependency is imported in
internal/hex.go- aliased asfasthex, using:fasthex.EncodedLen(...)fasthex.Encode(...)Every other
hexreference in the codebase (again quick search in the repo) already uses stdlibencoding/hex. It's listed as a direct dependency in the rootgo.modand as// indirectacross the dialect/example modules.Why we'd want to replace it
encoding/hexis maintained by the Go team and patched through normal Go releases.EncodedLenandEncodehave identical signatures and semantics, so the SQL output should be unchanged.The only tradeoff I can see
go-hexprovides SIMD-accelerated encoding, so stdlibencoding/hexmay be slower when serializing large[]byte/byteablobs. I guess for most workloads this is is probably negligible, but maybe someone can include a benchmark on a representative blob size if maintainers want to quantify it before deciding.Happy to open a PR if this direction is acceptable.