10 ms·
Alpine Linux 3.9.0 Released
- jillesvangurp 8y agoI'm curious to know why they switched back to openssl from libressl. Are there compatibility issues or have the issues that caused libressl to be created been addressed now in openssl?
- _ikke_ 8y agoThis post[0] contains some of the reasons: - better upstream support from projects - To my understanding, various of the issues in OpenSSL that made us switch to libressl have been resolved. (for example memory management) - libressl failed to retain compability with OpenSSL - libressl breaks ABI every 6 months, OpenSSL does not - FIPS support [0]:http://lists.alpinelinux.org/alpine-devel/6308.html http://lists.alpinelinux.org/alpine-devel/6308.html
- izietto 8y agoA more organic reasoning about it here: http://lists.alpinelinux.org/alpine-devel/6073.html http://lists.alpinelinux.org/alpine-devel/6073.html
- viraptor 8y agoIt sounds weird that FIPS is relevant to Alpine. They're not going through the certification process, so does it matter?
- Nursie 8y agoThere are situations where you want to be able to say you're using a FIPS certified crypto library, but that you're not going to get the whole thing certified. I went through that with an IBM product I was working on years ago. It involved taking out any crypto implementations already in the code (I believe we had a reference DES implementation doing something with passwords) and switching to FIPS certified TLS libs. At the end we got to say we were FIPS compliant (NOT certified), which was important for some government contract or other.
- windexh8er 8y agoAlso interesting is that the PCI SSC is now recommending FIPS 140-2. While not likely relevant to the decision in Alpine, it may be relevant downstream with regard to choosing Alpine to develop on. PCI Standards Security Council - Secure Software Standards v1.0 (Jan 2019) https://www.pcisecuritystandards.org/document_library?category=sware_sec#results https://www.pcisecuritystandards.org/document_library?catego...
- Nursie 8y agoOh interesting. That said I've only ever taken devices through PCI-PTS, not worked on PCI compliant software so I have no idea how much of a departure this is from common practice. The one thing that would concern me about widespread adoption of FIPS-certified tech is that (IIRC) FIPS 140-2 essentially forbids PFS modes (DH/DHE) on TLS, presumably for traffic audit purposes in secure government environments.
- entity345 8y agoOpenSSL is the de facto industry standard. To me this list explains why one should stick to OpenSSL.
- koolba 8y agoThat logic might hold for a container platform meant to run other peoples code, but it’s one of the best reasons to not use it in other contexts like load balancers.
- entity345 8y agoMy logic is that you probably want a proven, up-to-date crypto/TLS library with a 'standard' API whatever the application.
- jeremycw 8y agoI thought heartbleed proved this appeal to authority wrong causing liressl to exist in the first place.
- entity345 8y agoOpenSSL is continuously scrutinised and has resources and pressure to fix issues. A less ubiquitous library is not as scrutinised (so who knows what vulnerabilities lie within?) and has probably not the same resources/pressure to fix. Forks are often political before anything else. Fragmentation is not a good thing.
- koolba 8y agoI’m not suggesting you fork it yourself, write your own, or use Joe Schmoe’s SSL library. There are other major implementations such as Amazon’s s2n that have many eyeballs on them daily. Diversity of infrastructure components confers similar resistance as DNA diversity in the wild. https://github.com/awslabs/s2n https://github.com/awslabs/s2n
- 8y ago
- technion 8y agoI'll add I saw a number of Docker image discussions where people asked about TLS 1.3 support, and the answer was "blocked in Alpine, which is blocked in Libressl".
- mises 8y agoFrom what I understand, libressl was a fork of openssl resulting from a bunch of people who were pissed about heartbleed. Not being so dependent on one library is good, but that doesn't necessarily mean that the alternatives are better. Openssl is still more established, and from what I understand (anecdotally), openssl is faster (an important consideration for a distro like alpine). With that said, libressl is likely more secure (which means it may be an option to go along with alpine's hardened kernel). https://en.wikipedia.org/wiki/LibreSSL https://en.wikipedia.org/wiki/LibreSSL
- IcePic 8y agoNice to see someone go "lets choose the faster lib over the more secure one" for a security lib. No way that could ever go wrong in the long run. Or if it already did. Not commenting on the choice from alpine, just comment on this post.
- deleted 8y ago[deleted]
- hendry 8y agoWonder why they use grub over the simpler syslinux option?
- wener 8y agoAlpine use syslinux,will use grub if you install with uefi enabled flag.
- hendry 8y agosyslinux supports UEFI I think: https://www.syslinux.org/wiki/index.php?title=Install#UEFI https://www.syslinux.org/wiki/index.php?title=Install#UEFI So I wonder what is the rationale for using Grub for bootloading UEFI systems.
- hestefisk 8y agoFrom the web site: “ container requires no more than 8 MB and a minimal installation to disk requires around 130 MB of storage. Not only do you get a fully-fledged Linux environment but a large selection of packages from the repository.” I remember in 1997 when I could boot Linux off a 1.44MB floppy and get a fully a fully functioning Linux environment even with network support in a blitz. If 130MB is considered “lean”, what happened to our Unix principles of minimalism and clean design?
- tyingq 8y ago> I remember in 1997 when I could boot Linux off a 1.44MB floppy I installed slackware in the early 90's. The kernel was on one floppy, then the barest rootfs was on a 2nd and 3rd floppy. I believe the whole install spanned 13 1.44MB floppies. That's not so different from say, current day Openwrt in overall size, which can still fit into 4MB of ROM if needed.
- Diederich 8y agoRemember the letter groups? A, AP, N for networking, X for basic X11. (: Good times.
- hestefisk 8y agoAh yes, Slackware disk sets. I actually got the installer on a CD-ROM from Walnut Creek but had to resort to floppies because Slack didn’t recognise my optical drive (those days it was attached via an ISA mounted sound blaster card, not on the motherboard itself!). The distro I was referring to above was LOAF (and tomsrbt), Linux On A Floppy.
- elcomet 8y agoIt would be interesting to see a tree map of the sizes in Linux, like how big are the drivers, the network stack, ... Maybe 99% of those 130Mb are the drivers, a lot were added to the kernel since 1997 I guess
- 8y ago
- fuzzy2 8y agoJust out of curiosity: > Firefox is only available on x86_64 due to Rust. Could someone explain the reasoning behind this? I’m not familiar with whatever restrictions Rust may impose.
- scriptdevil 8y agohttps://www.reddit.com/r/rust/comments/9oe4yp/alpine_linux_is_looking_for_help_with_rust_and/ https://www.reddit.com/r/rust/comments/9oe4yp/alpine_linux_i... They only have rust packages for X86_64
- fuzzy2 8y agoAh, I see. Wouldn’t have thought making Rust work is so troublesome! Thanks.
- _ikke_ 8y agoThe issue is porting Rust to other architectures, which is not trivial. Work is being done to get there, just not in time for v3.9.
- inferiorhuman 8y agoHuh? Linux on arm, i686, mips, ppc all have rustup installers. I'm not sure if that formally makes them "Tier 1" platforms but it does mean that they're pretty darn well supported by rust. Are the Alpine folks having problems because they're not using GNU libc?
- _ikke_ 8y agoYes, that most likely plays a role. I wasn't too sure, so I left it out of my answer.
- wyldfire 8y agoThe challenge might be bootstrapping. rustc makes a habit of capitalizing on just-introduced features, and they only require that you have the prior release. So to build rustc 1.x, you have to build 1.(x-1) first. Also -- packaging. rustup might be available but the distros generally prefer their own native packaging system.
- rcarmo 8y agoThis great. I recently filed an issue to upgrade smokeping, and it's now closed. :)
- Leace 8y ago> Switch from LibreSSL to OpenSSL Glad that this happened. OpenSSL looks a lot better than when the entire drama started and it was quite hard to even build OpenSSL from source on alpine.
- jakobgm 8y agoGreat! Especially happy to see Tesseract OCR v4.0 [0] now being in the mainline repository. Tesseract was the main motivation for changing my web stack to docker a couple of weeks ago, and I had to use a separate builder image [1] in Alpine 3.8. Now it is just: > apk add tesseract-ocr [0] https://pkgs.alpinelinux.org/package/v3.9/community/armhf/tesseract-ocr https://pkgs.alpinelinux.org/package/v3.9/community/armhf/te... [1] https://hub.docker.com/r/inetsoftware/alpine-tesseract/ https://hub.docker.com/r/inetsoftware/alpine-tesseract/
- sevensor 8y agoHow suitable is Alpine as a desktop distribution? It seems like a low-GNU distribution with an emphaisis on static linkage. Is that a correct assessment? I'm very happy with Arch, I stopped my distro-hopping six years ago when I landed on it, but I worry that I'm getting complacent because Arch is just so easy to use.
- sdfasdslk 8y agoStatic linkage is a beautiful prospect, beckoning with promises of less time in dependency hell.
- sevensor 8y agoAlthough that sounds nice, dependency hell has never been a problem for me under Arch. Sometimes AUR-installed packages go out of date, but then you rebuild them and everything is OK again.
- pjmlp 8y agoAs someone that lived through the introduction of dynamic linking and threading into UNIX, it is kind of ironic to see the return to the past being celebrated with joy.
- fao_ 8y agoDynamic Linking was actually heralded against by many of the foundational minds of UNIX. Because the flaws outweight the benefits. Do not quote me on this, but IIRC Plan9 does not have dynamic linking for this very reason. http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/
- pjmlp 8y agoPlan 9 was a middle step for Inferno, the OS HNers keep forgetting about. Dynamic linking is everywhere on Inferno, implemented by the same Rob Pike of that email thread. Also many seem unaware that Go supports dynamic linking for a couple of versions already. The only thing missing is building plugin libraries on Windows.
- oweiler 8y agoNo Docker image yet? https://hub.docker.com/_/alpine https://hub.docker.com/_/alpine
- r6by 8y agoFollow Glider Labs GitHub Docker Alpine issue: https://github.com/gliderlabs/docker-alpine/issues/480 https://github.com/gliderlabs/docker-alpine/issues/480
- artellectual 8y agoMuch awaited release. I've been running my entire application line up on Alpine it's been awesome! I wish more Cloud / Hosting providers have default Alpine Images. I've been using alpine's APK packaging system to manage software builds and release cycles. So for those who are curious my CI builds the software into packages automatically versioning them and marking the build versions, storing the packages in my GCS bucket and then automatically runs apk add --upgrade on my package. All orchestrated with Terraform and LXD, no docker / Kubernetes involved whatsoever. Now there is also apk-autoupdate which I look forward to exploring and seeing how it can simplify my build process.
- w323898 8y agoStill no EFI install media?
- g33k247 8y agoHas anyone used this on an RPI? What was your use case?
- Human_USB 8y agoI use it on an rPi and LOVE it. The system will boot quickly, and unless I `ibu`, I just reboot to clear my changes. I use the rPi for dnscrypt-proxy2.
- ksec 8y agoJust wondering how many are using Alpine in Production? I have heard problems of LibreSSL ( no longer matters ) and muslc. But no one has came out and state they are using it happily in production on X number of Servers.
- tpxl 8y agoMy company is using Alpine on (at least) 6 kubernetes nodes in production. I'm happy with it so far, but we're just running a java app (albeit high traffic).
- tracker1 8y agoProbably my favorite distro for dockerizing apps that need more OS. 130mb isn't exactly tiny, but it's a lot smaller than other more common options. I'll sometimes do builds in a larger distro (debian or ubuntu server), then deploy into alpine.