2024-11-01 02:46:47 how do you check what the release version is of the installed kernel on Alpine? 2024-11-01 03:44:29 orchardstreet22: 'apk info linux-edge' or 'linux-lts', depending on what you're using 2024-11-01 03:45:02 You can also check the _running_ kernel with 'uname -r' 2024-11-01 06:47:42 Hello, is there any way I can make udhcpc start faster during boot? Right now it spends couple seconds with the message "udhcpc: broadcasting discover" 4 times until it starts. I read on the wiki that you can add async run level which I did and moved chronyd to it which made my boot faster, but when I did the same with networking it still starts as if it was in boot, any way I 2024-11-01 06:47:44 can make udhcpc start faster? 2024-11-01 07:06:51 OK moving it to async run level solves it but it still prints the output and I need to press enter to get to login prompt after wich it continues to print to my tty. Is there a way to supress the output and get swtraight to login prompt? 2024-11-01 10:42:21 I'm getting this error on firefox 'Cannot play media. No decoders for requested formats: application/vnd.apple.mpegURL' , any idea if I could fix installing some package? 2024-11-01 12:11:28 is unrar in repo? only find it in the bash-complertion package 2024-11-01 12:11:50 It is not, since it's not free to redistribute 2024-11-01 12:12:03 bsdtar can handle rar files though 2024-11-01 12:14:32 thanks! 2024-11-01 12:26:18 ikke: unrar is redistributable 2024-11-01 12:26:24 it's just non-free 2024-11-01 12:27:03 bsdtar can handle a subset of rar files 2024-11-01 12:27:11 a lot of them don't work in practice 2024-11-01 12:36:36 is there a way to get gpg-agent to forget previous successful pinentry, without killing it? 2024-11-01 12:42:02 nvrmnd, found it 2024-11-01 15:03:16 damn, epr from repo is nice epub reader, so cozy 2024-11-01 15:04:40 cozy? 2024-11-01 18:12:18 hi, i have current months' irc log (html version) available here, https://m.insteps.net/irclogs/alpine/ , will move to better named domain soon, suggestion to improve welcomed 2024-11-01 20:04:52 vkrishn: looks really cool 2024-11-01 20:12:34 WhyNotHuge: I'm so confused, uname -r returns linux-lts-6.6.58-r0, I thought I was supposed to be on r1 on Alpine 3.20.03 as of now 2024-11-01 20:12:47 i mean WhyNotHugo 2024-11-01 20:14:54 there is not enough space 😂 2024-11-01 20:19:15 :) 2024-11-01 21:40:28 I'm having issues with fusermount3 when running a flatpak. It seems to be to do with the desktop portal 2024-11-01 21:41:05 I'm getting `fusermount3: failed to access mountpoint /tmp/xdg_runtime_dirs/1001/doc: Permission denied 2024-11-01 21:41:40 I can't seem to chmod this `doc` directory, I assume it's been made and is managed by the portal 2024-11-01 21:41:47 any ideas on how to debug this? 2024-11-01 22:58:20 orchardstreet22: did you reboot after installing the update? 2024-11-02 01:37:08 hey, is anyone using QEMU with a Windows host? I can't get a standard network (QEMU bridge to tuntap guest device) to work and wonder if I'm missing something 2024-11-02 02:02:42 Did you install the virtio drivers in the windows VM? 2024-11-02 02:03:50 http://www.linux-kvm.org/page/Virtio <- these to be more specific. 2024-11-02 04:35:31 durrendal: thanks, I did. 2024-11-02 04:36:06 Turns out it was a nftables issue, the default NAT setup needs these extra rules -> https://forums.gentoo.org/viewtopic-p-8752687.html?sid=993eeba614dd1db9d8dce9c0eb625bf6#8752687 2024-11-02 04:36:28 Needs more setup, but Alpine really is a great desktop distro 2024-11-02 12:58:58 Hey, I am currrently trying to understand the supply chain risks in Alpine Linux to understand the threat model and the use cases it is and is not appropiate for. Currently it seems builds are made with registry.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci:latest 2024-11-02 13:00:28 lrvick: That's just for CI purposes 2024-11-02 13:00:47 But doesn't the CI sign the builds? 2024-11-02 13:02:06 and the keys are just made with abuild-keygen on each CI node, so they are extractable keys and not stored in a TPM or TEE unless I missed something? 2024-11-02 13:04:57 Our builders are separate from our CI infra 2024-11-02 13:05:04 CI is just for testing merge requests before merging them 2024-11-02 13:05:35 Ah, that is helpful. Is there any transparency on the builders and how they are managed then? 2024-11-02 13:06:24 E.g what build images they use, how they are hash locked, etc? 2024-11-02 13:07:00 We do not use docker for the builders 2024-11-02 13:08:31 They are lxc containers 2024-11-02 13:08:39 https://pkgs.alpinelinux.org/package/edge/main/x86_64/aports-build 2024-11-02 13:12:38 If I am asking questions that are well documented somewhere please by all means RTFM me, but to clarify... 2024-11-02 13:13:07 So the build machines run aports-build, which in turn build and sign all packages, including new copies of aports-build. 2024-11-02 13:14:18 presumably these machines are themselves running alpine, which then run alpine lxc-containers, which then run aports-build? 2024-11-02 13:14:38 is this setup maintained by hand, or via automation of some kind? 2024-11-02 13:16:26 lrvick: maintained by hand 2024-11-02 13:19:09 Okay. Is it then accurate to say build-machine maintainers ssh to the build machines, and thus have plaintext access to the global package signing keys from their personal workstations? 2024-11-02 13:26:26 I guess to ask bluntly, are there are any mitigations in place today (or even planned) to prevent the compromise of a personal ssh key of an alpine build-machine maintainer being able tamper with any alpine package without detection? 2024-11-02 13:36:22 lrvick: At the moment, there are not a lot of controls in place, except that the people having access is very limited (2 or 3, depending on the arch). 2024-11-02 13:36:34 We do have plans to redesign the builder architecture 2024-11-02 13:40:01 This conversation is fascinating. Does there exist any monitoring or out of band logging and alerting that would catch such tampering? 2024-11-02 13:40:49 I am working on exporting syslog, but not in place everywhere yet 2024-11-02 13:41:00 Is MFA enforced on the SSH keys that access the build systems? (Such as the use of ed25519-sk with yubikey presence?) 2024-11-02 13:41:27 So this is stemming from an article that came out comparing the distro I founded for supply chain integrity (stagex) to other distros. Given that we are OCI-native, comparisons to Alpine being the most popular distro in corporate containerized environments are unavoidable, but I do want to make sure they are accurate and fair to alpine. 2024-11-02 13:41:43 hello, is there any recomendded way to have per user services in alpine ? 2024-11-02 13:42:11 Stagex is also musl based, so we borrow a lot of patterns from alpine. 2024-11-02 13:42:33 aktina: not at the moment, openrc is working on implementing it 2024-11-02 13:43:19 durrendal: no 2024-11-02 13:43:28 But we are 100% bit for bit reproducible, and we mitigate single points of failure in our supply chain by ensuring all packages are reproduced by 2-3 people independently, and each signed by 2-3 maintainers as proof of this, so there is no SPOF in any single computer or person. 2024-11-02 13:44:07 but it is unlikely stagex will ever be as popular or widely deployed as alpine, so if there is a way to get similar protections into alpine that would be a major win for the internet at large which heavily depends on it. 2024-11-02 13:44:08 lrvick: How does that scale? 2024-11-02 13:44:22 ikke heavy automation 2024-11-02 13:44:32 We receive 60 merge requests per day 2024-11-02 13:44:50 We build for 8 architectures 2024-11-02 13:45:09 The latter is the most challenging for verifying reproducability 2024-11-02 13:45:45 well if builds were reproducible, then every PR could build by 2-3 build machines in paralell, which could be immutable machines with non-extractable TPM based keys with remote attestation. 2024-11-02 13:46:04 granted that woudld be more expensive, but I don't see it being a slowdown if running in paralell 2024-11-02 13:46:14 We are limited in the HW that we have 2024-11-02 13:46:26 Which is all donated to the project right ikke? 2024-11-02 13:46:29 Yes 2024-11-02 13:46:55 If companies knew how vulnerable they were based on the setup they just described, I bet getting hardware donated would not be that big of a problem 2024-11-02 13:48:14 Currently stagex already has quite a bit of donated hardware from 4 orgs because we made it clear supply chain integrity is a hard requirement for merging packages, but in total fairness we only have about 300 packages and one architecture. We also only do the expensive reproduction step at release time, not PR merge time 2024-11-02 13:48:16 lrvick: what if the machine with the tpm keys broke? Do you loose your signing keys? 2024-11-02 13:48:53 TPM backed keys* 2024-11-02 13:49:45 Well you have a couple of options for that. If it is truly an immutable remotely attestable machine, then you could generate keys on first boot, load them into the TPM and PCR lock them, then export the keys via a shamirs-secret-sharing split, each share encrypted to a different maintainer 2024-11-02 13:50:08 so when you bring online a new build machine, a quorum of maintainers must submit their shares to the machine to reconstitute the key 2024-11-02 13:50:11 but no single party controls it 2024-11-02 13:50:38 this is how an OS I desgined, quorumos works, and keyfork, an open source project by my org, Distrust. 2024-11-02 13:51:33 if the OS of the build machine is reproducible, then any maintainer could locally build the same machine image, and verify the hash of the PCR that the TPM is certifying, matches the hash you get locally 2024-11-02 13:51:49 thus all maintainers can prove the machine is running the image they expect and that it has no means to exfiltrate the key 2024-11-02 13:52:08 thus you have a system that can only be controlled by a voting quorum, vs a single person. 2024-11-02 13:53:03 Though in stagex we opted not to do this, and instead have a 1/1 pairing of build machine and signing key, and just require a minimum number of build machines (controlled by different people) reproduce and sign the packages 2024-11-02 13:53:19 I think that that scales better 2024-11-02 13:53:20 but we only get away with that because we are 100% reproducible and full source bootstrapped 2024-11-02 13:53:30 lrvick: how do you bootstrap gcc? 2024-11-02 13:53:42 and rust 2024-11-02 13:53:45 from 256 bytes of x86 assembly 2024-11-02 13:53:51 all the way up 2024-11-02 13:53:58 Probably takes a lot of time 2024-11-02 13:54:14 about 2 days to bootstrap everything from source 2024-11-02 13:54:24 but once 2-3 people have reproduced the bootstrap packages 2024-11-02 13:54:29 we do not have to touch them or revisit them often 2024-11-02 13:54:47 We bootstrap each release (every 6 months) 2024-11-02 13:55:28 lrvick: how many arches are you building for 2024-11-02 13:55:30 ? 2024-11-02 13:55:30 I didn't realize alpine had full source bootstrapping? 2024-11-02 13:55:36 not full source 2024-11-02 13:56:12 right now only x86_64, though once we get our new ReprOS build automation system underway, we plan to add arm64 and riscv next. 2024-11-02 13:56:28 but because of paralell builds, we don't expect this to slow us down 2024-11-02 13:56:32 The problem is I don't see that approach scaling if you have to redo that for a lot of arches 2024-11-02 13:57:06 the bootstap path for various arches already exists thanks to the Gnu Mes, Stage0, and live-bootstap projects 2024-11-02 13:57:15 we just containerize their bootstrapping work for each arch 2024-11-02 13:58:11 stage0-1 can stay x86 even, but stage2 is where we pivot to x86 -> x86_64 cross compiler to bootstrap the rest of the distro 2024-11-02 13:58:25 but we can pivot to making that a multiarch image at that point with a cross compiler for each arch 2024-11-02 13:58:30 should be no problem. just more wall time 2024-11-02 13:59:16 Also, nothing stopping alpine from using our stage0-2 images, they are distro agnostic. Our ReprOS and AirgapOS images are also distro agnostic. 2024-11-02 13:59:30 you could bootstrap alpine with stagex if you wanted 2024-11-02 14:00:27 or copy our approach. We copy plenty of stuff from alpine so no shame there :) 2024-11-02 14:02:01 but imo, without reproducible builds bootstrapping does not really solve any trust problems 2024-11-02 14:02:26 and it seems with your number of packages and arches, getting to 100% reproducibility as a retrofit woudl be a massive effort 2024-11-02 14:02:33 yes, it would 2024-11-02 14:03:51 We could start with main just to make it tracktable 2024-11-02 14:04:00 I would then circle back and suggest that the biggest value thing you could do is sign commits, sign reviews, and do quorum administration of the build machines and build keys so no single human can tamper with them, and make those remote attestion proofs public. 2024-11-02 14:04:17 that is something that could be done as a standalone project in a vacuum 2024-11-02 14:04:21 in much shorter time 2024-11-02 14:04:33 then can start the long tail of reproducibiltiy 2024-11-02 14:04:51 and then others can use the same image as the builders to reproduce alpine. more the better 2024-11-02 14:05:55 One thing we certainly want to do is separate the signing keys from the builders 2024-11-02 14:06:27 what is the threat model there? 2024-11-02 14:07:55 Not all HW has TPM 2024-11-02 14:08:59 There is absolutely no path to removing single human points of trust without either remote attestation, or reproducibility. You have to pick one, ideally both 2024-11-02 14:09:05 but that order is probably the most within reach 2024-11-02 14:09:27 -most- hardware has TPM2 in it thesedays 2024-11-02 14:09:45 as Windows requires it now, which was a fun forcing function 2024-11-02 14:10:39 But even if the hardware does not have a TPM, but has a USB port, you could get away with using a Nitrokey etc and people physically provisioning the machine in person into a tamper evidient storage 2024-11-02 14:11:20 but having deployed servers in bank vaults with multi-party physical controls a few times... I promise a TPM is a much cheaper option and much easier to prove the integrity of at a distance. 2024-11-02 14:12:26 most server motherboards have TPMs, though most baremetal server providers like hetzner disable them by default 2024-11-02 14:12:37 but you can order a crash cart, get bios access, and turn it back on in many cases 2024-11-02 14:13:01 We use donated HW. And not all archictectures provide TPM 2024-11-02 14:14:17 You could emulate or cross compile in those cases, or simply start by providing the high integrity path for the architectures most widely used in high risk environments: x86_64/arm64 2024-11-02 14:17:12 The number one thing I would put on a risk register for you guys would be the fact that someone could threaten a single person on your team to tamper with a rust binary, and tamper with the firmware and binaries that gate access to billions of dollars. Now, you could say it is insane that alpine is used for use cases like this, and it is, but it is also sadly a reality. There is 2024-11-02 14:17:14 a -massive- target on alpine, and a lot of major supply chain attacks recently, some of them involving coercion. 2024-11-02 14:17:20 do it to protect yourselves personally, if for no other reason. 2024-11-02 14:18:56 I for one would be happy to help unblock this if I can. If keyfork or repros or bootproof can be useful to you guys, great. Or happy to discuss design decisions and see what you come up with independently. 2024-11-02 14:20:23 Feel free to add some comments to https://gitlab.alpinelinux.org/alpine/tsc/-/issues/82 2024-11-02 14:21:55 https://docs.distrust.co/qkm/ may be useful. This is how we do ceremonies (with 100% reproducible OS images verified by the whole team) to generate critical signing/encryption keys ensuring no single person an ever acess them, but also ensuring we have offline ways to backup and recover. 2024-11-02 14:22:43 then we can collaborate to load these keys onto airgap laptops we purchase and provision with witnesses locally, or remote enclaves we all verify remotely 2024-11-02 14:23:16 but then we have reasonably proof no single human can tamper with or extract the keys, or tamper with the software that controls the keys 2024-11-02 14:23:50 these tactics should be very general purpose and apply to a broad set of use cases. Feel free to rip them off, use them as-is, or use them for reference for your own designs 2024-11-02 14:24:05 but would like to see more distros applying these sorts of tactics if possible 2024-11-02 14:25:31 will take a look at that issue. Indeed I have comments I ant to make already :) 2024-11-02 14:27:33 Note that as a project, we don't have any capital. Any purchose must by covered by individual members, which limits our options 2024-11-02 14:30:07 But I'm certainly interested in improving our posture 2024-11-02 14:38:16 As a reference our tactic for getting most of our capital was pointing to companies that build mission critical software, that their supply chain has single points of failure in single computers or humans, and that if they pay us, we could dramatically reduce that risk. That resulted in stagex being funded from 3 orgs from day one, including paying for reproduction machines 2024-11-02 14:38:18 hosted/donated by several different individuals/orgs. 2024-11-02 14:38:20 is there a rough sketch diagram flow how signing is done ? 2024-11-02 14:38:34 When no one wants to trust each other by design, then we all have to bring our own hardware and pay for it 2024-11-02 14:38:37 or have our employers do it 2024-11-02 14:39:11 asking me? 2024-11-02 14:39:39 it could be added to issues/82 2024-11-02 14:41:51 We only get away with our tactics because we are reproducible, which dramatically simplifies things. One person makes a release PR with every package they generated on their own hardware, and the digests they got for every package in the tree. A second maintiner builds/bootstraps from 0 and gets the same set of digests for every container, and adds a second set of signatures. 2024-11-02 14:42:26 we try to have 3+ though 2 is always a hard minimum 2024-11-02 14:42:40 so we never had a single human trusted at any point from the first release 2024-11-02 14:43:17 but for alpine a retrofit tactic is required, so in that instance something like keyfork is probably a major accelerator. 2024-11-02 14:43:54 keyfork can generate a key, split it into m-of-n shares, and encrypt each share to a different yubikey or nitrokey, which can be distributed to each administrator. 2024-11-02 14:44:29 then any time you generate a new signing key or something on an immutable machine, you can have the generation routine encrypt a copy to that split key before it loads it into a TPM 2024-11-02 14:44:34 so you have a disaster recovery story 2024-11-02 14:44:57 then any M members of the admin team could come together to restore the same key to a new TPM as needed to bring online a new build machine 2024-11-02 14:45:21 while having strong evidence no single admin has ever had plaintext access to the keys 2024-11-02 14:45:48 for this scheme to work, you don't need the whole distro to be reproducible 2024-11-02 14:45:51 I assume this must run on the builder? 2024-11-02 14:45:59 To have access to the TPM chip 2024-11-02 14:46:00 but you -do- need the OS image that runs the builder to be reproducible 2024-11-02 14:46:08 yes ideally 2024-11-02 14:46:37 And the yubikeys? 2024-11-02 14:46:41 or nitrokeys 2024-11-02 14:46:56 each member of the admin team would provision those in advance 2024-11-02 14:47:03 and contribute their public keys to the ceremony machine 2024-11-02 14:47:16 ceremony machine boots up, generates quorum key, and encrypts shares to each admin public key it was born with 2024-11-02 14:47:41 so each admin only controls one share via the nitrokey they set up themselves 2024-11-02 14:48:35 total hardware cost for the ceremony could be a $150 laptop purchased at a retail store with witnesses, or running a TPM capable cloud machine remote for a few minutes. + cost of nitrokeys/yubikeys 2024-11-02 14:48:40 can be very very cheap 2024-11-02 14:49:32 doing it on the TPM capable cloud machine would require you implement a tpm2 remote attestation, and have a reproducible OS image on that machine, but stagex has you covered there if you wanted. 2024-11-02 14:50:03 though bootproof, the remote attestation story, is still early. Though we do ship tpm2 tools so yu cuold get away with a shell script calling those + keyfork if you wanted 2024-11-02 14:50:36 QuorumOS would make this much easier but that is not open source yet (soon, putting pressure where needed ;) 2024-11-02 14:51:43 lrvick: say I have a baremetal machine, no cloud provider. How do you attest that it's running a specific image? 2024-11-02 14:52:19 That is tricky, but solvable 2024-11-02 14:52:27 you need to confirm the root of trust with other people somehow 2024-11-02 14:52:33 the TPM2 endorsement key 2024-11-02 14:52:36 Because that's 99% the case for us 2024-11-02 14:52:52 maybe multiple people visit that machine in person or confirm the endorsement key of that TPM out of band and pgp sign it 2024-11-02 14:53:01 but you will need a one time trust bootstrapping with multiple people for baremetal 2024-11-02 14:53:06 That's also challenging 2024-11-02 14:53:15 Physically visiting the HW 2024-11-02 14:53:56 with a machine in a datacenter none of you have access to, you could each visit an admin panel for the machine remotely and confirm the EK yourselves 2024-11-02 14:54:10 or you all independently verify the EK with the hardware seller or provisioner 2024-11-02 14:54:18 but you need some method to confirm that EK 2024-11-02 14:54:42 with cloud providers, they all have endorsement key APIs now, so it is actually much easier with cloud 2024-11-02 14:54:46 But you do see the challenge 2024-11-02 14:54:50 It's not trivial 2024-11-02 14:54:50 since they own all the hardware and know what hardware they own 2024-11-02 14:55:30 its trivial with cloud, but with baremetal hosted physically by people this is really suboptimal without reproducible builds 2024-11-02 14:56:14 without reproducible builds you are forced to trust a single system somewhere. It is easiest to form trust if no admin has physical access to that system, and it is hosted by a neutral third party 2024-11-02 14:56:17 say hetzner, etc 2024-11-02 14:56:21 Yes, our build HW is not provided by cloud providers. We used to have ARM servers hosted ad a baremetal provider, but that arrangement has ended and now we are hosting it soemwhere at a sponsored location 2024-11-02 14:56:50 can you get a neutral third party, say a datacenter tech, to confirm the EK out of band to multiple people? 2024-11-02 14:56:51 For x86_64, it's easy to get resources from could providers, for aarch64 doable, but other arches are nearly impossible 2024-11-02 14:57:23 No cloud provider provides s390x, ppc64le, loongarch64, riscv64 2024-11-02 14:57:46 but zooming out to your actual problem 2024-11-02 14:57:52 if you sacrificed a bit of performance for security 2024-11-02 14:57:58 you could do builds of those in qemu 2024-11-02 14:58:23 We prefer native hw as much as possible 2024-11-02 14:58:41 not just for performance 2024-11-02 14:59:58 threat modeling is a series of tradeoffs. What security win does running on native hardware give you that outweighs removing single human points of failure? 2024-11-02 15:02:43 even if there is a compelling argument there, which I am doubtful of, that forces you to have no remote attestation solution those architectures, 99.999% of your risk comes from real world high risk deploymentts of alpine in public and private infrastructure, which use overwhelmingly x86_64, and sometimes aarch64. 2024-11-02 15:03:14 so again even if you only had high accountability deployments for just those two, that is a very very worthwhile effort 2024-11-02 15:04:33 then you can decide if you want to deal with the rest via reproducibile builds over time, or emulation 2024-11-02 15:08:32 I haven't found anything, but just to be sure: does alpine take monetary donations? 2024-11-02 15:09:47 witcher: We do not have an entity that can take donations. Individual members may take donations 2024-11-02 15:10:13 ikke: is there by any chance a list of who takes donations? 2024-11-02 15:10:15 I would note that TPM2 is not the only hardware mechanizim available to you for remote attestation. PPC64 and others have tamper evidient secure boot hardware available that can be used to unlock keys in a nitrokey or similar 2024-11-02 15:10:50 or some hardware can let you burn a hash of a key into a fuse array, and that hardware will refuse to use anything not signed by that key, etc 2024-11-02 15:10:55 i roughly know who works on alpine but i'm sure there are people i'm unaware of 2024-11-02 15:11:10 then you can have any remote attestation logic you want in your boot rom using coreboot or similar 2024-11-02 15:11:35 anyway, if there is any arch you struggle with after x86_64 an aarch64 and really need baremetal, I can possibly help 2024-11-02 15:12:49 afk for a while 2024-11-02 15:14:14 qemu build performance is garbage and saying you sacrifice "a bit of it" is being disconnected from reality 2024-11-02 15:15:20 it has tons of other drawbacks too such as not being able to reliably run tests for things 2024-11-02 15:16:30 i actually maintain a distro that does build one architecture in qemu (riscv64) and it really sucks to deal with it and i'm looking forward to when I can put it on baremetal 2024-11-02 15:18:20 ikke: is there currently a way for people to volunteer to help maintain the various bits of infrastructure that Alpine uses? I assume that's probably something the TSC would promote someone for and then vote on, but I'm not aware of the process outside of what is done for promoting maintainers to developer access. Does something like this exist already? 2024-11-02 15:25:25 clandmeter is lead of the infra team] 2024-11-02 15:25:46 We don't have a pre-defined workflow for that 2024-11-02 15:26:27 Ah gotcha. So it's more of an as needed by appointment directly from clandmeter then. That makes sense. 2024-11-02 15:26:51 We could use help, but it also takes time 2024-11-02 15:31:33 q66: even if the performance is half, it would still be worth it to wait a few extra hours for a build, than to blindly trust a build has not been tampered with. 2024-11-02 15:32:39 I would be very interested in helping if I can, and if that offer is of interest/use to the team. Happy to discuss further! 2024-11-02 15:32:50 durrendal: feel free to discuss in #alpine-infra 2024-11-02 15:36:11 lrvick: so as i said, disconnected from reality 2024-11-02 15:36:35 not only it is far less than that while burning the full power of a beefy x86 box, it also has the other drawbacks 2024-11-02 15:37:10 sure love waiting 2 days for kernels to build when they update basically weekly 2024-11-02 15:39:59 not only is emulation not worth it and introduces random bugs into the result while preventing tests from being run as at least a basic correctness check, they are also environmentally irresponsible, on top of being annoying to wait for 2024-11-02 15:40:21 no amount of security clownery will outweigh that 2024-11-02 15:45:38 I updated this morning (latest-stable) and the `netmount` service now causes a kernel panic. Specifically it seems to be the CIFS module: https://tpaste.us/oxaR (see 13.232497 ). Changing to linux-virt or linux-lts in edge or v3.19 did not help, but linux-lts@v3.18 works for now, although I would prefer a more recent kernel. 2024-11-02 15:50:07 q66: Well, to be clear, I would only be suggesting doing what it takes for release builds, and only on architectures where it counts the most initially. 2024-11-02 15:50:30 but also, there are many different forms of hardware remote attestion, other than TPMs 2024-11-02 15:50:44 emulation would be a last resort 2024-11-02 15:51:16 I think focusing on reproducable builds would make individual servers less important 2024-11-02 15:51:16 I am just saying if I -must- choose abysmal build performance, and having to sale up to compensate, or having builds I can trust 2024-11-02 15:51:20 the latter is more important 2024-11-02 15:51:54 I am currently running full source bootstraps of rust on 2 systems to make sure it reproduces as 1.82. Yes, its hard 2024-11-02 15:52:03 but for high risk applications there is no alternative 2024-11-02 15:52:09 and it takes 2 days every time 2024-11-02 15:52:38 when you are doing reproducible builds, take anything you are doing and triple it. Security is expensive. 2024-11-02 15:52:47 I agree that is reality. 2024-11-02 15:53:35 well enjoy 2024-11-02 15:53:40 if alpine was reproducible, then you don't have to trust any one server. They could each have their own keys, and all is well. This is what we do on stagex 2024-11-02 15:53:53 however without reproducibility you don't have many options other than remote attestation 2024-11-02 15:53:59 both options are expensive, you have to pick a poison 2024-11-02 15:54:22 doing nothing is going to create more problems that slow builds though, I am sure of that. 2024-11-02 15:55:02 fwiw decoupling signing from the builder is useless from security perspective because regardless you gotta trust the output of the builder, if it's tampered with you won't be able to tell and you will just get tampered-with packages that were signed without leaking the private key 2024-11-02 15:55:13 which has no security benefit whatsoever, it's worse if anything 2024-11-02 15:55:29 We are musl based and 100% reproducible, so I don't imagine alpine is that far off if CI blocked all new updates that were not reproducible as a fourcing function 2024-11-02 15:55:43 because at least if you know your builder is compromised and therefore the key is too, you can revoke the key and invalidate everything 2024-11-02 15:56:18 q66: on this we totally agree. I think you might as well keep the key on the build node. 2024-11-02 15:56:32 whatever is trusted enough to compile might as well be trusted to sign 2024-11-02 15:56:49 yes i thought about whether I should do this in my case and came to the conclusion that there is no way to separate the key and gain anything from it 2024-11-02 15:56:57 though a non-extractable key and an immutible build system that can't be changed after deployment should be the first two steps imo 2024-11-02 15:57:08 those alone give you a massive reduction in attack surface 2024-11-02 15:57:31 q66: what you gain from it is that it's harder to compromise the key when you lack some sort of hardware enclave 2024-11-02 15:57:31 if you can't put a key in a TPM, put it on a nitrokey and plug it into a usb drive 2024-11-02 15:57:35 non extractable keys are cheap 2024-11-02 15:57:47 usb port* 2024-11-02 15:58:23 the goal should not be preventing key extraction though. That by itself is not that useful 2024-11-02 15:58:31 the goal should be preventing the key from signing something malicious 2024-11-02 15:59:06 If the key is extracted, nothing prevents actors from signing malicious things 2024-11-02 15:59:39 it is of non zero value, however if anyone can ask the key to sign anything blindly 2024-11-02 15:59:44 then you are not in that much different of a situation 2024-11-02 15:59:48 You are 2024-11-02 15:59:51 lot of effort for very very little reduction in attack surface 2024-11-02 16:00:18 You can ditch the server, remove the compromised packages, and continue 2024-11-02 16:00:30 If you need to revoke the key, everyone is impacted 2024-11-02 16:00:37 but the damage is already done. The world is already compromised. 2024-11-02 16:00:42 bigger problems thatn key revocation at that point 2024-11-02 16:02:29 let me put it in a concrete situation so we stay grounded. Companies like coinbase build everything with Alpine. Billions and billions of dollars are trusted to binaries built with alpine from just that one company. There are hundreds more examples. 2024-11-02 16:02:48 if a single malicious binary is singed by an alpine build server even once 2024-11-02 16:03:16 it could cause an exfiltration of insane amounts of value to some pretty bad actors to fund war machines. 2024-11-02 16:03:52 With key extraction, they could do it without us even having a clue 2024-11-02 16:04:08 without key extraction, they could still do it without you having a clue. 2024-11-02 16:04:12 Remote signing includes auditing 2024-11-02 16:04:40 let me be clear, I agree solving for non-extractable keys is then right first step 2024-11-02 16:04:48 I just think that is like a 5% solution 2024-11-02 16:04:52 i'll always approve of coinbase getting screwed over so you just gave me a good argument to keep things as they are :P 2024-11-02 16:06:07 q66: I hate most of these companies, and I don't care if they get ripped of. I do care that the people ripping them off are using them to fund dictators. 2024-11-02 16:06:30 lots of money being stolen by dangerous people is bad for everyone, even if we dont' like the people being stolen from 2024-11-02 16:09:58 I once audited a crypto firm that had a billion dollars in doge sitting on a server the whole team had access to. Honor system. Now we can say, doge is stupid, I agree. But you can trade it for real money, which means it is dangerous and worth protecting (or deleting). 2024-11-02 16:11:01 Anyway point is, IMO, maintaining software the world depends on is a big responsibility. You can't just think about your own use cases. 2024-11-02 16:12:28 Now if you want to say boldly "we are just a hobby distro, we don't have the funding to take security seriously" you should do that if it is true. But if it is not true, then there is some real responsibility to seek out funding if required, and do it right. 2024-11-02 16:13:51 idk about alpine but i literally don't care about the needs and wants of some stupid scam corporate 2024-11-02 16:14:02 i won't take their money, i want to have 0 to do with them 2024-11-02 16:14:36 all i care about is my community 2024-11-02 16:14:38 But you do realize public infrastructure, governments, hospitals... all anchor their security to alpine 2024-11-02 16:15:21 now again, I think that was irresponsible of all those decision makers to not verify a distro like alpine has no human or system single points of failure before electing it into those positions 2024-11-02 16:15:26 but they did, and here we are 2024-11-02 16:16:03 I think the choice is convince all those parties to stop using Alpine, loudly, or close the risks. 2024-11-02 16:16:11 I am very happy to help support either path. 2024-11-02 16:57:45 Irvick: I do agree that security should be taken seriously. Yet, if you know what happens within cloud providers infra... 2024-11-02 16:59:29 Alpine as it is right now is the last thing to worry about. 2024-11-02 17:05:47 Most of my client are running immutable appliance-like production infrastructure already. 2024-11-02 17:06:02 trusted and reproducible binaries are the next layer down 2024-11-02 17:09:19 That's great if you have your own infra. If you don't then it's like building a house from roof to bottom. 2024-11-02 17:13:38 Hello, are packages in repositories statically link to musl ? or dynamically ? I'm wondering in what condition can the LD_PRELOAD be used for switching allocator. Also if LD_PRELOAD would work with gcompat dependent software 2024-11-02 17:14:13 SyntheticBird[m]: In Alpine Linux, packages are built dynamically 2024-11-02 17:14:25 at least, c(++) based ones 2024-11-02 17:17:01 I see thanks. 2024-11-02 17:43:23 lrvick: "We are musl based and 100% reproducible", which distro is it ? 2024-11-02 17:56:57 https://codeberg.org/stagex/stagex 2024-11-02 17:58:03 Blog post written about us recently: https://quorum.tkhq.xyz/posts/reproducible-builds-made-easy-introducing-stagex/ 2024-11-02 17:58:19 Though per the discussion above I think the comments about alpine are probably not quite accurate and need adjustment 2024-11-02 18:00:44 SyntheticBird i think LD_PRELOAD will work anyways, no matter if it's dynamic or static 2024-11-02 18:02:45 comparsion could include void 2024-11-02 18:03:50 it could include 1000 other distros, but I think the goal was just to cover the ones typically on the short list for container/build/release use cases which is the topic at hand here. 2024-11-02 18:04:06 stagex in particular has no package manager, and no ambition of being a desktop linux distribution 2024-11-02 18:04:23 its goal is just to make reasonably secure reproducible builds easy. 2024-11-02 18:04:53 to not take us too far off topic though, probably best to direct most stagex questions to #stagex :) 2024-11-02 18:05:11 (sorry alpine devs, he asked!) 2024-11-02 18:05:41 no worry 2024-11-02 18:05:54 ok, nice to read 2024-11-02 18:11:00 btw our musl patch to mrustc covered in that post should cover alpine as well, if you want to fully build rust from source 2024-11-02 18:11:34 Though, I warn you, it takes about a day on 32 threadripper cores 2024-11-02 18:11:59 though mrustc 1.72 is very close which should cut this down to a few hours 2024-11-02 18:12:28 oh, not trying to discredit the/your work, just trying to get more info on reproducible builds 2024-11-02 18:13:09 Didn't think you were. Was just trying to avoid hijacking the channel to shill my own solution ^_^ 2024-11-02 18:16:20 its linux channel and "reproducible builds" is common to al too 2024-11-02 21:40:40 As there been any attempt or information about supporting enabling SELinux on Alpine ? I see their is a fairly updated version of libselinux and its utils in edge repository. I've also compiled my kernel with SELinux enabled. I know there is probably not a compatible policy for it but i'm wondering whats the state of things 2024-11-02 21:42:55 SyntheticBird[m]: afaik you need also to recompile userspace software to make it selinux-aware 2024-11-02 21:43:16 It takes a lot of work to get SELinux right 2024-11-02 21:46:36 seems like selinux is not something you can just enable or disable 2024-11-02 21:47:21 OOOOH right I forgot about userspace part 2024-11-02 21:47:34 I thought it was just a systemd thing 2024-11-02 21:47:46 selinux has nothing to do with selinux 2024-11-02 21:47:54 ? 2024-11-02 21:47:54 systemd has* 2024-11-02 21:47:58 ah 2024-11-02 21:48:21 I just remember that Arch linux required SELinux recompilation of base 2024-11-02 21:48:34 and it was all systemd packages recompiled with selinux flag 2024-11-02 22:08:37 I don't see what software would need selinux aware recompilation 2024-11-02 22:08:42 tbh 2024-11-02 22:08:50 ig that cost nothing to try 2024-11-02 22:10:45 selinux requires a lot of work 2024-11-02 22:11:04 it's not for nothing that the most common advise people give when running into selinux issues is to disable it 2024-11-02 22:11:40 Without proper care, applications stop working because they are denied access to things they need 2024-11-02 22:12:27 i worked on gentoo hardened back in the day, but i'm not sure what's changed since then. libselinux should be enough but gentoo afaik still asks people to use hardened. but yeah, the audience is limited. 2024-11-02 22:13:04 the main upside is limiting stuff that runs as root. 2024-11-02 22:14:18 even amongst sysadmins the # of people who really understand selinux well is, in my view, small 2024-11-02 22:53:16 ikke: yes I'm aware of the challenge and I really want to learn it. 2024-11-02 22:53:55 invoked: on some chat platform I meet a Fedora engineer and its bio was: *SELinux wiped my soul.* I think this is an accurate representation. 2024-11-02 22:55:37 it takes some work 2024-11-03 03:16:17 it really sucks that I had to register in order to access this channel. from my logs I can see it wasn't like this up to the 31st of the last month. what happened? spam? 2024-11-03 03:18:05 Alpine... "Enter ssh key or URL for foo changed by root" - does this want to populate authorized_keys for the user? 2024-11-03 03:20:44 So far the installer is pretty straightforward. Other than that one brief puzzlement it's pretty droolproof so far. 2024-11-03 03:21:49 Nice, that was amazingly quick, and it did indeed install my ssh public key from the URL I gave it. 2024-11-03 07:41:49 if i buy a 512G disk i cant fit 512G onto it, but if i created a +2G partition with fdisk, i can fit 2G onto it after formating it? 2024-11-03 08:58:51 Most likely not 2024-11-03 09:25:07 hmm there is some problem with st in repo, when pasting or navigating history, it seem to force longer than the screen lines to overlap upon itself so it stays on one like ... 2024-11-03 09:25:22 *line 2024-11-03 10:43:13 Hummm, there's no “history” in st 2024-11-03 12:39:47 quinq oh, its ash!? even just holding down a key till it it reaches the end of the screen, it starts overwriting the same line, instead of starting a new line... 2024-11-03 12:41:22 is a too large hd more durable since, iiuc, it can stop using bad sectors and still have plenty of space? 2024-11-03 12:41:44 I'm not sure what history you're talking about, if it's about command history, then yes that's $SHELL 2024-11-03 12:42:01 yeah same problem in xterm/ash 2024-11-03 12:42:14 hum 2024-11-03 12:42:49 damn, then i guess it will never be fixed ;/ 2024-11-03 12:43:28 if i open a termianl with ash and type untill i read EOL it starts overwriting the line instead of wrapping to a new line 2024-11-03 12:43:51 I think that things can be fixed most of the time :) 2024-11-03 12:44:04 busybox ash 2024-11-03 12:44:05 It just has to be annoying enough to motivate you ^^ 2024-11-03 12:44:16 Yeah, I can reproduce the issue 2024-11-03 12:44:38 i reported some bugs to busybox, and looked over the bugs there, lots of old old bugs 2024-11-03 12:45:06 its a new bug tho 2024-11-03 12:45:22 been using ash many years now with no/little problem 2024-11-03 12:47:05 Is that the first time in those many years you wrote a long command line? ^^ 2024-11-03 12:47:26 hehe, no, thats what im saying, its a new bug 2024-11-03 13:04:58 ohhh ok 2024-11-03 13:17:39 oksh/mksh seems nice, basic, mksh seem to have some more features, you just delete /bin/sh and make a new symlink? 2024-11-03 13:18:26 I'm using loksh 2024-11-03 13:18:31 But no, don't do that 2024-11-03 13:18:43 /bin/sh is the portable shell, called by scripts 2024-11-03 13:18:49 quinq whats loksh like? 2024-11-03 13:19:20 i also use /bin/sh as the default shell 2024-11-03 13:19:45 If you want to use an alternative shell, just set it in /etc/passwd 2024-11-03 13:20:24 (check its valid path in /etk/shells) 2024-11-03 13:20:29 s/etk/etc/ 2024-11-03 13:26:40 loksh seem very similar to oksh 2024-11-03 13:26:54 slightly smaller 2024-11-03 13:35:52 Sure, they're both ports of OpenBSD ksh, but Alpine provides loksh, worksforme 2024-11-03 14:07:28 alpine also has oksh 2024-11-03 14:12:19 theres also mrsh, which together with mrsh-libs is slightly smaller still.. 2024-11-03 14:40:24 mksh doesnt support 'sleep 1h', mrsh kills background processes when it itself is killed, i think i prefer oksh/loksh yeah 2024-11-03 14:51:14 sleep $((60*60)) 2024-11-03 14:51:36 hehe, yeah 2024-11-03 14:53:38 probably posix... i guess its not a big deal anyway.. 2024-11-03 14:54:48 oh mksh also kills background jobs when exiting.. 2024-11-03 15:54:02 frag: the busybox ash bug is not a bug in a alpine patch and not budybox itself. I have already created a MR to fix this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74526 2024-11-03 15:54:31 *is a bug in an alpine patch and not busybox itself 2024-11-03 15:55:48