deb: no PIE/RELRO hardening for built binaries; static CGO_ENABLED=0 builds hit statically-linked-binary #75

New issue

Open

opened 2026-07-19 21:46:05 +02:00 by heiko · 0 comments

heiko commented

2026-07-19 21:46:05 +02:00

Owner

Binaries produced via plain go build are neither PIE nor
RELRO-hardened, so lintian flags two warnings on every packaged Go
binary:

W: <pkg>: hardening-no-pie [usr/bin/<bin>]
W: <pkg>: hardening-no-relro [usr/bin/<bin>]

Setting CGO_ENABLED: 0 in the project's env: section (forcing a static
binary) avoids those two specific findings, but trips a new, harder
one instead:

E: <pkg>: statically-linked-binary

which is strictly worse (an error, not a warning) -- confirmed live
while testing go.schlittermann.de/ius/joker-dmapi-client (cmd/joker):
switching to CGO_ENABLED=0 turned three W: into one E:, and lintian
aborted the pack run.

Current workaround in use

cert-proxy-client/cert-proxy-server already ship both parts of a
working combination:

env: { CGO_ENABLED: 0 } in .gogogo.conf, and
a hand-written debian/.lintian-overrides suppressing
statically-linked-binary (and, incidentally,
copyright-file-contains-full-apache-2-license, which is now fixed
separately, see the license-detection fix for nested cmd/ layouts).

This works, but every project has to discover and hand-roll this
pattern itself; gogogo pack populate doesn't scaffold a
lintian-overrides stub, and there's no built-in guidance that
"CGO_ENABLED=0 requires suppressing statically-linked-binary".

Suggested fixes (either or both)

Support -buildmode=pie as a build option (where the target
supports it), so dynamically-linked binaries can be hardened without
needing to go static at all.
When populating debian/ scaffolding (or when CGO_ENABLED=0 is
detected in the project's env:), also scaffold/append a
debian/.lintian-overrides entry for statically-linked-binary,
so static-linking projects get a clean lintian run out of the box
instead of having to reverse-engineer cert-proxy's approach.

Binaries produced via plain `go build` are neither PIE nor RELRO-hardened, so lintian flags two warnings on every packaged Go binary: W: <pkg>: hardening-no-pie [usr/bin/<bin>] W: <pkg>: hardening-no-relro [usr/bin/<bin>] Setting CGO_ENABLED: 0 in the project's env: section (forcing a static binary) avoids those two specific findings, but trips a new, harder one instead: E: <pkg>: statically-linked-binary which is strictly worse (an error, not a warning) -- confirmed live while testing go.schlittermann.de/ius/joker-dmapi-client (cmd/joker): switching to CGO_ENABLED=0 turned three W: into one E:, and lintian aborted the pack run. ### Current workaround in use cert-proxy-client/cert-proxy-server already ship both parts of a working combination: - env: { CGO_ENABLED: 0 } in .gogogo.conf, and - a hand-written debian/<pkg>.lintian-overrides suppressing statically-linked-binary (and, incidentally, copyright-file-contains-full-apache-2-license, which is now fixed separately, see the license-detection fix for nested cmd/ layouts). This works, but every project has to discover and hand-roll this pattern itself; `gogogo pack populate` doesn't scaffold a lintian-overrides stub, and there's no built-in guidance that "CGO_ENABLED=0 requires suppressing statically-linked-binary". ### Suggested fixes (either or both) - Support -buildmode=pie as a build option (where the target supports it), so dynamically-linked binaries can be hardened without needing to go static at all. - When populating debian/ scaffolding (or when CGO_ENABLED=0 is detected in the project's env:), also scaffold/append a debian/<pkg>.lintian-overrides entry for statically-linked-binary, so static-linking projects get a clean lintian run out of the box instead of having to reverse-engineer cert-proxy's approach.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

heiko/gogogo#75

No description provided.

Rows
Columns