Better design breeds better habits. In Java, you can end up handling a DNS exception 20 layers up the stack, even if your call never actually triggers a DNS lookup, simply because some method deep in the call stack declares it as possible. The culture is to propagate or wrap exceptions rather than translate them into domain-specific errors near the source.
Rust makes handling and mapping `Result` locally more ergonomic, even though `?` makes propagation easy too. Rust, however, also makes it easy to lose the context during propagation and end up with useless `Error`.
I wouldn't say the bug is only in musl. Musl is probably the "worst" offender here (at least choose something other than "*"!), but the change in sshd was also a little suspect. i.e. the "let's find a user and take their salt (and hashing algorithm) and use it to compute and compare the hash to avoid timing attacks" change.
I haven't thought it through, but I suspect in an ideal world, sshd shouldn't have accepted the user password regardless of the outcome of crypt() if the user did not exist and it only pretended to go through the motions to avoid a timing attack.
Did look into their patch yesterday(?) which seemed to mitigate this issue which they (rightfully IMHO) consider caused by musl. But it seems their fix is to do a sanity check on the supposed hashed password char length, and thus still theoretically still allowing the possibility of those "!!!INVALID_PASSWORD!!!" suggestions to fall through....
Static linking makes distribution easier, but it's an absolute security nightmare.
With dynamic linking, you just upgrade the library on your system and you're done. With static linking, every binary that uses the library has to be rebuilt.
both alpine and musl are great in my opinion, and as far as I know theres no empirical evidence that it is more or less secure overall than alternatives. would you like to elaborate your opinion?
IMO only good thing about alpine is that it's a good environment to build stuff that links musl statically.
Never understood why Alpine is used to actually run anything in a container - if you statically link binary, then you don't need alpine as a base and if you don't what is the point? Don't @ me about image size, even without layer caching we're talking about tiny difference that is often dwarfed by size of your runtime.
Musl itself is a great example of taking "simple and lightweight" so seriously that everyone else gets to deal with the complexity. Slow allocator, underoptimized memcpy/string routines, limited locale support, no NSS, and endless glibc compatibility headaches.
But hey, at least libc is small. %%Proceeds to pull in megabytes of malloc, and other libraries to replace the slow parts of musl.%%
And now sshhole.com is a particularly spectacular example of what happens when "simple" meets the rest of the software ecosystem.
I have to admit that I am a bit disappointed in this kind of thinking. There's vulnerabilities everywhere as especially the past few weeks have shown.
One occurrence is not a statistic and should not be used as evidence - it's just an example of a vulnerability that due to various bad circumstances lead to a particularity bad outcome. This logic is in my opinion equally flawed as calling alpine safe now because this particular vulnerability has been fixed.
I'm not a big fan of blaming and I think it's just a result of bad circumstances, but it's interesting to see how some seem to blame musl, but one could argue further that musl documented the behavior of their API which was ignored by openssh and so on
The other day, I sent a friend a link to my project. He asked, “When can I use it?”
I was confused because the project was already available, with detailed setup instructions, an `llms.txt`, and everything else needed to get started.
Then he showed me a screenshot of him asking ChatGPT about it. Apparently, ChatGPT was using some outdated cached information or something, because it gave him a wall of text explaining that the project was still “coming soon” and wasn't ready to use.
If he'd just opened the landing page, he would've seen that the project was already available.
Are there plans to add http(s) support to knot? I was planning on hosting my own knot at home, but didn't want to expose my home IP (I use cloudflared for other services that need to be exposed)
This exploit depends on the deployment. With PHP-FPM, an OOM during request startup terminates the child, so the corrupted state wouldn’t survive for subsequent requests to exploit. The challenge used PHP’s built-in server, where the worker was reused.
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.
Alpine selling point was that it's small, which was selling people only for people that either don't understand docker layers or can't make Dockerfile correctly.
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`.
> A fully static binary can run in `FROM scratch`.
Not just `FROM scratch` but also in other contexts. For example:
I wrote my own password manager which lives on a USB drive. Since I compiled a static binary, I can execute it on any Linux machine.
Running static binaries in FreeBSD's Linuxulator is easier. The Linuxulator is a separate set of syscalls that get used when you attempt to run a Linux binary, so a static binary will "just work" for the most part (unless the program needs special filesystems like /proc or /sys). A dynamically linked binary means I need to make sure I have any necessary Linux libraries in the proper location and the Linuxulator's `ld` working properly. Updates to these libraries can then make something that used to work, suddenly stop working. Certainly not an insurmountable task, but there's so many fewer places where things can break when you're just running a static binary.
Well, `FROM scratch` implies that if there is something that works with linux syscalls (i.e. Linuxulator) then it generally runs. Unless, like you said, it needs special filesystems.
> which was selling people only for people that either don't understand docker layers or can't make Dockerfile correctly.
I don't think that's fair. Alpine-derived images are generally smaller, all things held equal. Of course if you do everything else right then it will matter less, but a proper multistage Dockerfile should still be smaller than the same thing built out of another distro (most of the time).
> which was selling people only for people that either don't understand docker layers or can't make Dockerfile correctly.
...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.
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.
Or people who needed a relatively full-featured build environment against musl without having to do bizarre incantations in e.g. a Fedora image to switch away from libc while still being able to link against other system libraries.
> people who needed a relatively full-featured build environment against musl
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.
You're not wrong, but both "nobody should be using musl" and "nobody's forcing you to use a full-fat distro image" often run into the reality that the choice of base image, security posture, and libc/linkage environment for distributables are, by policy or technical requirements imposed by third parties, not under the control of the person who is trying to make Docker images behave.
I agree and understand that, but I'm talking about purely technical reasons to use. IMO majority of alpine/musl usage is cargo cult. At my work, I'm yet to hear reason other than "its smaller" and "what is that? I just copy pasted it from X repo."
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.
Well, I got M4 iMac because I wanted a screen on my workbench with minimum cables and must be VESA mounted. I also needed a mac to build iOS apps. iMac was perfect fit.
Rust makes handling and mapping `Result` locally more ergonomic, even though `?` makes propagation easy too. Rust, however, also makes it easy to lose the context during propagation and end up with useless `Error`.
reply