4 ms·
The executable appears to be packed using vanilla UPX. Decompressing it and grepping the symbol table reveals the presence /lib/libc.so.6, /lib/libm.so.6 and /l
by vezzy-fnord 11y ago
The executable appears to be packed using vanilla UPX. Decompressing it and grepping the symbol table reveals the presence /lib/libc.so.6, /lib/libm.so.6 and /lib/libpthread.so.0.
By method of exclusion, it cannot be musl because musl unifies everything into a single /lib/libc.so.
It most likely is not uClibc because uClibc is typically symlinked to /lib/libc.so.0 from /lib/libuClibc.
Considering that the soname of /lib/libc.so.6 has been reserved by glibc since the 2.x days (to differentiate it from the Linux libc days of libc4 and libc5), it is most likely indeed glibc in use.
It's obvious this program isn't making use of NSS or anything like that, so it's doable to use glibc for static linking, if frustrating.
- paulasmuth 11y agoAh turns out this binary actually isn't statically linked at all. It's just the UPX packer that you mentioned that adds a trampoline/stub (the decompression routine I suppose) around the actual binary [and that trampoline code is what's completely static]: ldd kerf-unpacked linux-vdso.so.1 => (0x00007fff5e7f1000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff1833aa000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff1830a4000) libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007ff182e5d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff182a99000) /lib64/ld-linux-x86-64.so.2 (0x00007ff1835d1000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007ff182870000) So using NSS shouldn't be an issue; and the binary actually does use it open("/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
- vezzy-fnord 11y agoRight, the reference to ld-linux(8) should have been a giveaway.
- jpollock 11y agolibreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007ff182e5d000) libreadline is GPL'ed, not LGPLed, Kerf is therefore in violation. https://cnswww.cns.cwru.edu/php/chet/readline/rltop.html https://cnswww.cns.cwru.edu/php/chet/readline/rltop.html Edit: The GPL doesn't allow any linking into non-GPL compatible software, dynamic or static. Readline has this license for exactly this reason, and they have forced software into the public with it before (ncftp comes to mind) http://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic http://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynam... Edit2: https://en.wikipedia.org/wiki/GNU_Readline#Implications_of_GNU_Readline.27s_GPL_license https://en.wikipedia.org/wiki/GNU_Readline#Implications_of_G...
- paulasmuth 11y agoIt is not statically linked but loaded dynamically at runtime (see my comment above). And I think the .so is not bundled by UPX/shipped with the binary either. I believe this usecase is explicitly allowed by the GPL, but IANAL, so happy to be corrected. EDIT: Looks like I stand corrected and this is NOT the case even if you are just dynamically linking a GPLed .so; check parent's links/ask a proper lawyer/please don't sue me ;)
- dkhenry 11y agoEven though its dynamically linked the GPL still applies. The LGPL is designed to allow you to link to the software without requiring you to use the GPL license. Also since you have made your binary available you are required to make the source code you have used to make this release publicly available. I don't think anyone cares enough to sue you, however you are clearly in violation.
- paulasmuth 11y agoI am not the author of kerf/the linked software ;)
- kcl 11y agoThe OSX version links against libedit. The Linux version is supposed to as well so if it isn't that's an oversight. Let me take a look.
- kcl 11y agoI've committed a Linux version that for sure uses libedit. It is decidedly not my intention to use libreadline.
- deleted 11y ago[deleted]