Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no such thing as a “glibc based alpine image”

ariadne.space

Post reply on HN
Print view View original

41–50 of 204 posts

Re: There is no such thing as a “glibc based alpine image”

#41

Post by ariadneconill »

akerl_ wrote: post #40
ariadneconill wrote: post #35

Earlier quoted context omitted.

the only thing the proposed change does is encode something that is already factual: if you install that glibc package, you have a high likelihood of breaking your system. it's not like we are blocking it in apk-tools, and you can roll your own musl package with the conflict removed by simply building it with the `ALLOW_GLIBC_PKG` option.

It feels like you’re splitting hairs. No, you’re not blocking it in apk-tools, and yes, a user can work around the change you’re making to continue doing what they want. But your post directly says “I have also proposed an update to Alpine which will block the installation of the glibc packages produced by the alpine-glibc project”. So I’m not sure how describing it as “blocking this downstream project” could possibl…

I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system.

Do you not think that distributions should make even a little bit of effort to introduce friction toward scenarios known to break systems?

If apk-tools had a soft conflict option, where it printed a warning and required the user to acknowledge that warning somehow before continuing, that would also solve the issue as far as I am concerned, but it does not have such an option at this time, and we need to put our foot down sooner rather than later.

Edit: besides, nothing has been implemented. This is just one proposal, the point of having a conversation is to determine what the best option for solving this issue is.

Re: There is no such thing as a “glibc based alpine image”

#43

Post by sharikone »

ntauthority wrote: post #21
p2t2p wrote: post #16

Earlier quoted context omitted.

We had to stop using alpine because we have to resolve a DNS name that resolved in a 100 hosts. Musl fails to resolve that because it does not support “upgrade to TCP” and the response does not fit into single UDP packet so it gets truncated, so node fails to resolve the name. And not only node, normal Linux tools as well. And the author says it’s a feature, not a bug so for me it is kinda hard to take that thing ser…

Why is DNS resolution even part of the libc and not, say, the base OS, a service on the base OS, or if need be, an external library like c-ares? In fact, I thought Node already depended on c-ares, why is it failing on this?

Linux as a system is very ill-defined. I'd argue that GNU/Linux by definition contains glibc even if they are not in the same tree and musl based distributions are a variation which you could call "musl/Linux".

Re: There is no such thing as a “glibc based alpine image”

#44

Post by fanf2 »

tyingq wrote: post #38
p2t2p wrote: post #16

Earlier quoted context omitted.

We had to stop using alpine because we have to resolve a DNS name that resolved in a 100 hosts. Musl fails to resolve that because it does not support “upgrade to TCP” and the response does not fit into single UDP packet so it gets truncated, so node fails to resolve the name. And not only node, normal Linux tools as well. And the author says it’s a feature, not a bug so for me it is kinda hard to take that thing ser…

https://twitter.com/RichFelker/status/994629795551031296 Yikes.

That thread from 2018 refers to RFC 5966 which was obsoleted by RFC 7766 in 2016. RFC 7766 is much stricter saying TCP support is required. https://datatracker.ietf.org/doc/html/rfc7766#section-5

Re: There is no such thing as a “glibc based alpine image”

#45

Post by trissylegs »

ntauthority wrote: post #21
p2t2p wrote: post #16

Earlier quoted context omitted.

We had to stop using alpine because we have to resolve a DNS name that resolved in a 100 hosts. Musl fails to resolve that because it does not support “upgrade to TCP” and the response does not fit into single UDP packet so it gets truncated, so node fails to resolve the name. And not only node, normal Linux tools as well. And the author says it’s a feature, not a bug so for me it is kinda hard to take that thing ser…

Why is DNS resolution even part of the libc and not, say, the base OS, a service on the base OS, or if need be, an external library like c-ares? In fact, I thought Node already depended on c-ares, why is it failing on this?

It probably made sense in 1983.

https://github.com/dank101/4.2BSD/blob/master/include/netdb....

Re: There is no such thing as a “glibc based alpine image”

#47

Post by mwcampbell »

Aissen wrote: post #9
dbt00 wrote: post #2

I've definitely had my share of annoyances with musl-libc and would probably consider building my base images around distroless if that were something I were dealing with right now. In the meantime, it's kinda shitty of someone to casually squat on the alpine linux namespace. If you want to make a small distribution that also ships glibc, then it's not alpine. Don't call it that.

I've had to battle quite a few portability issues, but everytime it was a program incorrectly assuming some sort of behaviour from glibc and not really musl's fault.

Does it matter whose fault it is when one just needs to ship a product and keep it running reliably?

I'm conflicted on this. I'm currently running an Alpine-based container in production but am thinking about revisiting the choice of base image.

On the one hand, using a smaller base system and (especially) a simpler libc translates to a smaller attack surface, and less noise in static scans for vulnerabilities. So I could argue that using Alpine is the responsible choice from a security perspective.

But maybe I'm just rationalizing a desire to pursue the kind of software quality (simplicity, minimization of bloat) that only we developers appreciate and that often has hidden downsides. Then I read about such downsides, like the sibling comment about DNS resolution, and I wonder if the responsible thing to do as a pragmatic product developer (and future manager of such developers) is to banish Alpine from the stack, tolerate the relative bloat of something like Debian, and throw more (and more complex) tools at the problem of the larger attack surface and more noise in vulnerability scans.

Re: There is no such thing as a “glibc based alpine image”

#48

Post by Aissen »

faho wrote: post #27
Aissen wrote: post #9

Earlier quoted context omitted.

I've had to battle quite a few portability issues, but everytime it was a program incorrectly assuming some sort of behaviour from glibc and not really musl's fault.

I mean, okay, it's the program's fault. But it is part of the trade-off you make using musl, and one that I, personally, wouldn't decide in its favor. As the user, you have the choice to use musl and "battle quite a few portability issues" (whether that's the program's fault or not!) or to use glibc and not have to battle. If the benefits of musl outweigh that in your opinion, then go ahead. I don't see it.

Agreed. People knowingly using musl usually know the benefits.

Re: There is no such thing as a “glibc based alpine image”

#49

Post by ariadneconill »

mwcampbell wrote: post #47
Aissen wrote: post #9

Earlier quoted context omitted.

I've had to battle quite a few portability issues, but everytime it was a program incorrectly assuming some sort of behaviour from glibc and not really musl's fault.

Does it matter whose fault it is when one just needs to ship a product and keep it running reliably? I'm conflicted on this. I'm currently running an Alpine-based container in production but am thinking about revisiting the choice of base image. On the one hand, using a smaller base system and (especially) a simpler libc translates to a smaller attack surface, and less noise in static scans for vulnerabilities. So I…

alternatively you could just use a dedicated local resolver

Re: There is no such thing as a “glibc based alpine image”

#50

Post by im3w1l »

faho wrote: post #11
hhsbz wrote: post #8

Earlier quoted context omitted.

I think it's clear from the website that this is based on Alpine and not part of the project https://hub.docker.com/r/frolvlad/alpine-glibc/ Without context, I think what this guy is pissed off about is that this project enables people to use alpine to run proprietary software.

It doesn't outright state anywhere that it's not an official alpine product, and I don't know if everyone reads the site - many people will just copy the "FROM frolvlad/alpine-glibc" from elsewhere. In any case, the Alpine people would know, and they apparently think it's a problem. >Without context, But you have context here! It has issues with symbol versioning! There is "strange behavior and possible crashes, ". T…

  FROM frolvlad/alpine-glibc
That namespacing does make it look pretty unofficial to my eyes.
Post reply on HN