0x457
Joined 4 years ago
Joined 4 years ago
I won't deny that there is a use for portable binaries that don't depend on specific version of glibc, but its such a niche.
Doesn't mean that there isn't another exploit chain that can be used though. Challenge also had 4 workers total, so pining one worker wasn't that hard.
Yeah, I called this out as the main appeal of alpine. IMO no one should be using musl, but its another story.
> or people who had a test/deploy/debug cycle on environments that necessarily had no layer cache (ephemeral VMs, one-shot kubernetes clusters, OpenWRT routers that lost the layer cache on reboot). Or people with network-constrained traffic from registries or mirrors thereof.
Debian slim is ~30 MB compressed, and distroless/static is ~2 MiB. Small images aren’t unique to Alpine. With a fast local mirror, the extra download is negligible.
> Or people in environments that took container security findings (perhaps too) seriously and were tired of triaging endless reports for random dependencies in "FROM ubuntu" containers, and wanted a default required-by-policy base image that didn't come with the world.
1) Nobody’s forcing you to use a full Ubuntu image.
2) Alpine images still get plenty of security findings, often in the same dependencies your application needs regardless of the base image.
3) Nix is the best container builder anyway.
Alpine’s connection to static linking is mainly that it provides a convenient musl build environment. A fully static binary can run in `FROM scratch`.
Changed my lab to use the same alpine + php = tada working exploit.
You can still easily buy Bluray player and open source your discs with ARM (not CPU/SoCs, different one)