| 16 Oct 2025 |
 dramforever | # This is security-sensitive code, and glibc vulns happen from time to time.
# musl is security-focused and generally more minimal, so it's a better choice here.
# The dynamic linker is still a fairly complex piece of code, and the wrappers are
# quite small, so linking it statically is more appropriate.
| 18:31:29 |
| dramforever | trying to make the security sensitive programs minimal | 18:31:44 |
| dramforever | i guess | 18:31:47 |
| dramforever | fb-re2 https://github.com/facebook/pyre2/compare/main...dramforever:pyre2:fix-py3-type | 18:35:03 |
| dramforever | ideally someone actually familiar with python should take a look but this should be correct | 18:35:27 |
| dramforever | this is one of those "how did this ever work???" things | 18:35:43 |
 matthewcroughan | I mean, reading the news on the musl website indicates that it too has pretty bad vulns from time to time | 18:36:09 |
| matthewcroughan | And the speed of their website is concerning | 18:36:24 |
| dramforever | the speed feels like they compile a fresh copy of musl every time i load a page | 18:38:20 |
| matthewcroughan | It's more like it is running on a disposable vape, running mus | 18:39:00 |
| matthewcroughan | * It's more like it is running on a disposable vape, running musl | 18:39:02 |
| matthewcroughan | https://bogdanthegeek.github.io/blog/projects/vapeserver/ | 18:39:11 |
| matthewcroughan | For real though, the real website hosted on the disposable vape, is much faster | 18:39:32 |
| matthewcroughan |
Versions 0.9.13 through 1.2.5 are affected by CVE-2025-26519, an input-controlled out-of-bounds memory write primitive in iconv when the input encoding is EUC-KR and the output encoding is UTF-8, which could potentially be used as a vector to achieve arbitrary code execution. All users of software which may use iconv should patch (1, 2).
| 18:40:19 |
| matthewcroughan | Are we applying that patch though ? | 18:40:23 |
 rosssmyth | clock speed is half the ones I use at work, but the flash and ram are about the same | 18:41:03 |
| rosssmyth | nice | 18:41:05 |
| matthewcroughan | The vape you use at work? | 18:41:26 |
| matthewcroughan | Ah yeah looks like we are | 18:42:09 |
| matthewcroughan | dramforever: NIX_DONT_SET_RPATH = true is set in pkgs/by-name/mu/musl/package.nix, does this somehow impact your patch from earlier? | 18:42:58 |
| matthewcroughan | > aarch64-unknown-linux-musl-ar rc lib/libc.a obj/src/aio/aio.lo obj/src/aio/aio_suspend.lo obj/src/aio/lio_listio.lo obj/src/complex/__cexp.lo obj/src/complex/__cexpf.lo obj/src/complex/cab…
┃ > aarch64-unknown-linux-musl-gcc -std=c99 -nostdinc -ffreestanding -fexcess-precision=standard -frounding-math -fno-strict-aliasing -Wa,--noexecstack -D_XOPEN_SOURCE=700 -I./arch/aarch64 -I.…
┃ > -Wl,-e,_dlstart -o lib/libc.so obj/src/aio/aio.lo obj/src/aio/aio_suspend.lo obj/src/aio/lio_listio.lo obj/src/complex/__cexp.lo obj/src/complex/__cexpf.lo obj/src/complex/cabs.lo obj/src/…
┃ > aarch64-unknown-linux-musl-ranlib lib/libc.a
┃ > collect2: fatal error: cannot find 'ld'
| 18:44:00 |
| matthewcroughan | Okay, so given this.. | 18:44:02 |
| matthewcroughan | gcc is expected, but it can't find ld by the name ld I guess | 18:44:16 |
| matthewcroughan | But this also seems to happen with llvm | 18:44:27 |
| matthewcroughan | Ah right it's only called gcc because of the way we wrap things right? | 18:45:16 |
| matthewcroughan | it's the gcc-wrapper | 18:45:19 |
| dramforever | rpath is completely irrelevant when static linking | 18:46:45 |
| dramforever | including my patch | 18:46:49 |
| matthewcroughan | alright, makes sense | 18:47:02 |
| dramforever | wait, it shouldn't be using ld at this step | 18:49:21 |
