<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28 29 30 31
00:04 <kaniini> yes, it is nuts
00:21 <TemptorSent> kaniini: Okay any suggestion on how to get a user-verifiable disposable key?
00:24 <jirutka> "emrun: Implements machinery that allows running a .html page as if it was a standard executable file." … what the hell did I just read?!
00:25 <TemptorSent> Say WHAT?
00:25 <TemptorSent> It's not April 1st, is it?
00:25 <TemptorSent> No, no... that's SATURDAY.
00:26 <jirutka> I’m not sure if I should continue with this…
00:28 <TemptorSent> *hysterical laughter* Why, what could *POSSIBLY* go wrong?
00:28 blueness joined
00:35 <kaniini> ppc64le builder is going to be busy for a while
00:35 <TemptorSent> :)
00:35 tmh1999 joined
00:35 <kaniini> it just started building firefox
00:36 <TemptorSent> Come back tomorrow and check progress :)
00:37 <TemptorSent> kaniini: So, do you have any thoughts on how to handle the nonce key?
00:37 <kaniini> not really
00:38 <kaniini> wow
00:38 <kaniini> firefox built
00:38 <TemptorSent> WTF??
00:38 <TemptorSent> No way!
00:38 <kaniini> yes it is pending installation in the archive
00:38 <TemptorSent> Wow, that's insanely fast!
00:38 <TemptorSent> 3 minutes flat?
00:38 <kaniini> some minecraft clone failed to build, however
00:38 <kaniini> no
00:39 <kaniini> it had been running for about 20 minutes
00:39 <TemptorSent> Oh, okay!
00:39 <TemptorSent> You had me going for a sec there.
00:39 <kaniini> build/build-edge-ppc64le 12/233 656/885 community/php5 5.6.30-r0
00:40 <kaniini> now up to that
00:40 <TemptorSent> kaniini: Wow, that things cookin' along. Not shabby.
00:41 <kaniini> 12/233 for this run, 656/885 total packages built or already installed
00:41 <TemptorSent> kaniini: I'll be interested to play with a vm on that!
00:44 <TemptorSent> kaniini: I suppose the more accurate question is: Is it nuts to require a user to sign with their own key if they're using anything other than the stock packages?
00:44 <TemptorSent> kaniini: Since the stock nonce could be signed with the alpine keys.
00:46 <Shiz> what's 12/233 indicate?
00:47 <TemptorSent> Package 12 of 233 in queue
00:47 <Shiz> http://build.alpinelinux.org/
00:48 <Shiz> slightly confused what built vs total here means
00:48 <TemptorSent> Shiz: Total is total in repository IIRC
00:48 <kaniini> total is number of packages already installed in the archive plus number of successfully built packages for this run
00:48 <kaniini> build is the progress of this buildrun
00:49 <Shiz> right
00:49 <TemptorSent> Okay, total is in repo+built and pending then?
00:49 <Shiz> where did we get the ppc64le builder from? :)
00:49 <kaniini> IBM
00:50 <kaniini> i think it is in the same rack as the debian one
00:50 <TemptorSent> Nice.
00:52 <TemptorSent> kaniini: For now, I'll just use the host keys only and we'll implement the nonce once we can get agreement on how to make it verifiable.
00:54 <kaniini> host what
01:03 gromero joined
01:08 <TemptorSent> kaniini: /etc/apk/keys
01:08 tmh1999 joined
01:21 Emperor_Earth joined
01:33 rdutra joined
01:42 minimalism joined
01:51 TemptorSent joined
01:53 s33se_ joined
01:53 <TemptorSent> ncopa: Are you around by chance?
03:38 Emperor_Earth_ joined
04:51 blueness joined
05:08 fabled joined
05:08 <TemptorSent> Hello fabled.
05:09 <kaniini> clandmeter: libgd does not pass tests, i disabled it for now
05:39 <TemptorSent> Did I miss a memo? It's been dead here all day...
05:40 <kaniini> ZOMG FEATURE REQUEST: BUILD LOG OUTPUT OVER MQTT
05:40 <kaniini> KTHX
05:43 <TemptorSent> ?
05:48 <kaniini> nothing
05:48 <kaniini> don't worry about it
05:56 trfl joined
06:09 minimalism joined
06:24 <ncopa> morning
06:24 <ncopa> just reminder that git.alpinelinux.org and build.alpinelinux.org and distfiles.alpinelinux.org ill go dark in 5 mins
06:25 <ncopa> will be down for 2 hours or less
06:25 <fcolista> ncopa, should we announce it to twitter account?
06:27 <skarnet> darknesssss
06:28 <ncopa> dont think its needed
06:29 <ncopa> people will still be able to clone from github
06:30 <skarnet> the horrors you're putting them through
06:32 <kaniini> ncopa: there is something funky with ppc64le, like some of the packages are not seen by the builder yet theya re in the archive
06:45 t0mmy joined
06:50 vakartel joined
07:00 algitbot joined
07:04 <ncopa> build.alpinelinux.org, git.alpinelinux.org and distfiles.alpinelinux.org should all be back again
07:04 <ncopa> kaniini: might be the ppc64le builder didnt finish the current build-run
07:05 <ncopa> it will not git pull until its done with current run
07:14 elroncio joined
07:32 royger joined
07:47 tty` joined
07:48 TemptorSent joined
07:49 <ncopa> kaniini: yeah some thing is funky with ppc64le builder
07:49 <TemptorSent> Let's try this once more...
07:49 t0mmy joined
07:49 <TemptorSent> Good evening all.
07:49 <ncopa> hi TemptorSent
07:50 <TemptorSent> It appears my network is on the fritz upstream, so I'm sorry if I keep popping in and out -- I'll check the logs to see what I missed.
07:51 <TemptorSent> Hi ncopa, how are you doing?
07:51 <ncopa> TemptorSent: how can I help you? was a bit busy with the reconfiguration of build servers
07:51 <ncopa> im good thanks
07:51 <TemptorSent> No problem :) Anyway, I'm working on fixing our init trust model.
07:52 <ncopa> ok?
07:52 <TemptorSent> ncopa: Not sure if you read the logs on that, but the short of it is that we need a way of signing everything that gets installed into the initramfs so it can be verified later.
07:53 <TemptorSent> ncopa: Otherwise some almost-trivial attacks can succeed.
07:53 <ncopa> i didnt read the logs
07:54 <TemptorSent> ncopa: In the mkimage/initfs/init directory of my branch are init.stub and init-bake.sh
07:55 <TemptorSent> ncopa: Okay, in short, the problem we currently have is that none of the artifacts installed by update-kernel are currently verifyable after the fact, nor really at install time under the current model.
07:57 <TemptorSent> ncopa: Once files get copied to the initramfs, any verification our authentication ability we gained from the signed apk packaging was lost.
07:57 <yGweSm1OzVHe> but why not go all the way with secureboot then?
07:58 <TemptorSent> ncopa: So arbitrary code could be placed in the boot process without any way of checking.
07:58 <ncopa> TemptorSent: so the problem is that update-kernel doesnt really check the signature of the downloaded apk?
07:59 <TemptorSent> yGweSm1OzVHe: Secureboot is several steps further and requires additional hardware, bios, and bootloader support.
07:59 <yGweSm1OzVHe> yeah. it's turtles all the way down.
07:59 <yGweSm1OzVHe> but a simple boot sector backdoor is all i need to twart all your verbose work
08:00 <TemptorSent> ncopa: No, the problem is that update-kernel downloads several packages, extracts them, copies some of the files from each to the initrd, generates a few more files, an installs it all in /boot with no way of checking the integrety.
08:01 <yGweSm1OzVHe> you put a lot of effort into this, but is it worth it?
08:01 <yGweSm1OzVHe> bootsector malware exists since the 90ies
08:01 <ncopa> TemptorSent: and the /boot/vmlinuz?
08:02 <TemptorSent> yGweSm1OzVHe: Okay, answer me this, Why the hell verify every single package on the system and NOT verify init?
08:02 <TemptorSent> ncopa: Also not signed by us that I'm aware of.
08:02 <TemptorSent> ncopa: The kernel package contains the kernel, all the modules, and a few random bits and pieces.
08:03 <TemptorSent> ncopa: Which we proceed to install in 4 different places.
08:03 <TemptorSent> ncopa: We have the kernel, system map, etc that go in /boot, modules in /lib/modules, modules in .modloop, and modules in the initfs.
08:03 <yGweSm1OzVHe> maybe it's easier to put init on a bootstick? and protect it physically?
08:04 <TemptorSent> yGweSm1OzVHe: That's great, now how do you make sure someone didn't just randomly append a bit more to your kernel command line and load another initrd to snarf your encryption keys?
08:04 <yGweSm1OzVHe> that's about the same threatmodell you have
08:05 <yGweSm1OzVHe> how does this someone append something to my kernel command line exactly?
08:05 <TemptorSent> yGweSm1OzVHe: I'm talking about VERIFICATION
08:05 <yGweSm1OzVHe> don't shout man
08:05 <TemptorSent> yGweSm1OzVHe: Dunno, what kind of system? The easiest way is to have physical access.
08:05 <ncopa> right, verify that the usb stick with your kernel and initramfs didnt have corrupt sectors
08:05 <yGweSm1OzVHe> ok, corrupt sectors is a different thing
08:06 <yGweSm1OzVHe> one threadtmodel is nature, the other is human nature
08:06 <TemptorSent> ncopa: The idea is that we can sign what we install, then we can see if we're running what we installed.
08:06 <yGweSm1OzVHe> that is not true
08:06 <yGweSm1OzVHe> i can easily fool you into verifying correctly with my malwarehypervisor
08:06 <TemptorSent> yGweSm1OzVHe: The idea is to make it so you actually have to work at it to bypass verification.
08:06 <yGweSm1OzVHe> not much work actually
08:07 <TemptorSent> yGweSm1OzVHe: Really? so you can spoof the sha512 sums?
08:07 <yGweSm1OzVHe> less work than what you put effort into this i believe
08:07 <yGweSm1OzVHe> no i don' thave to
08:07 <yGweSm1OzVHe> i can just say that your memcmp is returning 0
08:07 <TemptorSent> yGweSm1OzVHe: To break verification, you do.
08:07 <yGweSm1OzVHe> i have to break your memcmp not sha
08:08 <yGweSm1OzVHe> super easy
08:08 <TemptorSent> yGweSm1OzVHe: Unless you break sha512, when I run sha512 sums and compare it to an external copy, you can't tell me I'm running the same thing.
08:08 <yGweSm1OzVHe> i only have to break your comparison
08:08 <yGweSm1OzVHe> not sha
08:09 <TemptorSent> yGweSm1OzVHe: My eyeballs will tell me if a sha512 sum doesn't match!
08:10 <yGweSm1OzVHe> i achieve your protections with much less effort or complexity by maintaining physical contact with my bootpartition.
08:10 <yGweSm1OzVHe> we are both fucked by a malicious hypervisor
08:10 <TemptorSent> yGweSm1OzVHe: I can't make it impossible for a malicious user to break their own sytem, but I can make it damn hard to spoof.
08:10 <yGweSm1OzVHe> no, you make it more complex
08:11 <yGweSm1OzVHe> but not necessarily fo rthe attacker
08:11 <TemptorSent> yGweSm1OzVHe: Which eliminates broad attacks and requires individualized effort.
08:11 <yGweSm1OzVHe> not sure a bout that
08:12 <TemptorSent> Okay, fine - I give up. I have no reason to trust an OS that doesn't allow me to verify that what I installed hasn't been changed since I installed it.,
08:12 <yGweSm1OzVHe> as you wrote: "Dunno, what kind of system? The easiest way is to have physical access." i deny physical access by putting the boot sector on a compartment.
08:12 <yGweSm1OzVHe> i can if i want check my pgp sig on that compartment whenever i want.
08:13 <yGweSm1OzVHe> much less complexity
08:13 <TemptorSent> yGweSm1OzVHe: *facepalm*
08:13 <yGweSm1OzVHe> you have compelling arguments sir
08:14 <TemptorSent> Okay. Seriously, I give up. Alpine is not my distribution and if the decision to explicitly ignore even basic verification is made, I'm not going to use it.
08:14 <yGweSm1OzVHe> you misunderstand
08:14 <yGweSm1OzVHe> i'm all for good verification, thats why i asked about secureboot
08:15 <ncopa> TemptorSent: i understand that you are not trying to protect against malware hypervisor with this
08:15 <TemptorSent> yGweSm1OzVHe: That would be great, but we don't have it on most systems.
08:15 <ncopa> im still not sure exactly what you are trying to solve
08:15 <ncopa> with verifictaion you want veriy that the files in initramfs has not been modified
08:15 <TemptorSent> yGweSm1OzVHe: What we CAN have is a boot-time means of checking that at least what we're currently running matches what we installed and verifying signatures on the content of the initramfs.cpio
08:16 <ncopa> modified in between what?
08:16 <ncopa> buildtime and runtime?
08:16 <ncopa> eg if there are bad sectors on boot media
08:16 <TemptorSent> ncopa: The same as any package audit -- that the files haven't been tampered with by checking their sums and checking sigs against that.
08:17 <ncopa> right, audit was actually a bi-effect of other problem we needed to solve
08:17 <TemptorSent> ncopa: Bad boot media, some common attacks (anything that can append to a cpio file)
08:17 <yGweSm1OzVHe> readonly boot media solves your problem also with much less complexity
08:17 <ncopa> we wanted to know which files had been modified by system administrator
08:18 <ncopa> so we knew which files in /etc to make backup of
08:18 <TemptorSent> But the one that really got me was the ability for an attack aginst the install itself.
08:18 <ncopa> no point in backing up unmodified files
08:18 <ncopa> how would such attack take place?
08:19 <TemptorSent> ncopa: Right, but it's a critical part of both forensics and general auditing.
08:19 <ncopa> im listening
08:19 <TemptorSent> ncopa: Memory collision attacks vms is an easy one, as is preloading a payload and appending it with the kernel command line.
08:20 <ncopa> how would you do that?
08:20 <TemptorSent> ncopa: race condition during writing files, all sorts of entertaining vecotrs.
08:20 <ncopa> "writing files"
08:20 <yGweSm1OzVHe> you are already running in a vm so you have to trust the layers above you, how do you verify those?
08:20 <ncopa> how, when, where?
08:21 <TemptorSent> For the memory collision, a broken ballon implementation can allow you to leave artifacts in ram at known locations
08:21 <ncopa> so this is in typical vm setups?
08:21 <ncopa> not physical boot media (eg boot usb)
08:21 <TemptorSent> It's a bigger issue with physical boot.
08:21 <TemptorSent> VMs are just easy to break from remote.
08:22 <_ikke_> How can you defend yourself against an evil maiden?
08:22 <yGweSm1OzVHe> doesn't have to be an evil maiden even
08:22 <ncopa> im just trying to understand what threat we are trying to solve with this
08:22 <TemptorSent> But the issue of someone swapping the initfs on your bootloader with their own could even be mostly mitigated
08:23 <ncopa> TemptorSent: if someone can swap the initfs
08:23 <ncopa> i mean
08:23 <ncopa> if i were an attacker
08:23 <ncopa> and had the possibility to swap the initfs
08:23 <TemptorSent> A copy of an install that can be subtly altered and not verified after the fact.
08:23 <TemptorSent> ncopa: If we bake the stub into the kernel, it makes it damn hard.
08:23 <ncopa> why would i swap the initfs when i could swap the vmlinuz?
08:23 <_ikke_> TemptorSent: How can you verify it it is altered (and so the verification can be corrupted)
08:23 <TemptorSent> _ikke_: By checking against the known-good sig.
08:23 <ncopa> if i can swap the initfs, then i can very likely swap the kernel itself
08:24 <_ikke_> TemptorSent: From where?
08:24 <TemptorSent> Just like we know apks are good.
08:24 <ncopa> since they are both stored same location
08:24 vakartel joined
08:24 <TemptorSent> ncopa: The kernel itself should be signed, as should the modules.
08:24 <ncopa> but it isnt
08:24 <_ikke_> TemptorSent: In order to trust the APKs are good, we trust /etc/apk/keys is not compromised
08:24 <yGweSm1OzVHe> and the verification function that verifies the sig, who verifies that?
08:25 <_ikke_> TemptorSent: How can you trust the signature? Against what, and how do you prevent that signature to be altered
08:25 <TemptorSent> _ikke_: right, but we can also go look at the keys stored on another system and make sure they have the same key!
08:25 <_ikke_> TemptorSent: But the attacker can just disable that check
08:25 <TemptorSent> _ikke_: I can't keep them from attacking it, but I can find out that they've changed something!
08:25 <_ikke_> or compromise it in such a way that it looks like it succeeded
08:25 <TemptorSent> Forensics.
08:26 <ncopa> TemptorSent: how would you like to verify the initfs?
08:26 <TemptorSent> Currently, how do you know if your initfs has been altered or not.
08:26 <yGweSm1OzVHe> i know
08:26 <yGweSm1OzVHe> it's in my pocket on a readonly stick
08:26 <ncopa> TemptorSent: we can also not verify that the vmlinuz is modified
08:27 <ncopa> whwich is bigger problem imho
08:27 <yGweSm1OzVHe> thus secureboot
08:27 <ncopa> but anyway
08:27 <ncopa> TemptorSent: im am open to suggestion to do initramfs verification
08:27 <TemptorSent> ncopa - I wrote a stub that handles the early init, checks the checksums of apk.static and busybox.static, sets up proc and a work fs, and then uses apk verify to check against baked-in keys
08:28 <ncopa> the apk-tools-static package should have a pubkey that you can verify against
08:28 <TemptorSent> Securing vmlinuz should be easy -- we can enable module signing at the very least, and the kernel sigs can be checked.
08:28 <ncopa> so you could verify the apk.static using the /etc/apk/keys
08:29 <TemptorSent> ncopa: Right, but I have to have it IN the initfs cpio to be able to run it.
08:30 <TemptorSent> ncopa: So I take the hashes of the file AND the init stub, put that file in a signed tarball, and verify THAT with apk, then check the enclosed hashes against the running tools.
08:31 <TemptorSent> So to break it, you'd need to rebuild several files, hash them, sign them, and insert them into the initfs, not just append a file to it.
08:31 <yGweSm1OzVHe> you have a documented threatmodel somewhere i'd like to understand what your adversary is capable of.
08:32 <TemptorSent> Ideally, we'd use a nonce key that is used only for one run of update-kernel, then destroyed.
08:32 <yGweSm1OzVHe> if he can append to your boot cpio i think he's quite a strong attacker already
08:32 <TemptorSent> The problem is verifying that key -- ideally, the user would counter-sign it.
08:32 <yGweSm1OzVHe> and i'm not sure he would attack your init
08:32 <TemptorSent> yGweSm1OzVHe Not really, the kernel will just keep reading until it runs out of io stream
08:32 <yGweSm1OzVHe> there's juicier targets than that
08:33 <TemptorSent> It's a very fragile part of the boot process.
08:33 <yGweSm1OzVHe> i can install my malicious hypervisor instead of messing with your init
08:33 <yGweSm1OzVHe> much easier
08:34 <TemptorSent> yGweSm1OzVHe: even that would be detectable, as the canary wouldn't sing.
08:34 <yGweSm1OzVHe> why?
08:34 <TemptorSent> I might not STOP you from doing it, but you couldn't trick me into thinking my init ran properly without a lot of effort.
08:34 <yGweSm1OzVHe> your init is untouched. all your sigs verify correctly
08:34 <yGweSm1OzVHe> i give a damn about your init
08:35 <TemptorSent> Yes, but I also have a canary value that passes through and is altered along the way that can be verified in userspace
08:35 <yGweSm1OzVHe> i have control over the ring that your kernel cannot touch
08:35 <yGweSm1OzVHe> so it's a somekind of secureboot without tpm?
08:36 <TemptorSent> yGweSm1OzVHe: Again, it's not going to work against a sophisticated, determined blackhat, but it should keep most easy attacks out or at least flag them.
08:36 <yGweSm1OzVHe> you overestimate the difficulty of malwaring your your bootprocess
08:36 <TemptorSent> yGweSm1OzVHe: No, it's not secure boot, I don't have anythign enforcing the harware to boot anything in particular or not,
08:37 elroncio joined
08:37 <TemptorSent> yGweSm1OzVHe: No, I estimate that the difficulty of attacking my boot process undetected is much harder if it contains unique, verifyable data.
08:38 <ncopa> i kind of like the idea of verifying the initfs
08:39 <ncopa> you can verify that boot media was not modified over the wire
08:39 <TemptorSent> yGweSm1OzVHe: But again, the point isn't to necessarily stop an attack, it's to let you look at two side by side FS images and tell if one has been altered from the original
08:39 <ncopa> normally you would verify the checksum of the tarball or iso image
08:40 elroncio joined
08:40 <ncopa> but it may be useful to verify that bootmedia does not have corrupt sectors
08:40 <ncopa> etc
08:40 <TemptorSent> ncopa: Exactly, it won't stop someone from going to great lengths, but a simple, inconspicuous addition of a malicious file to your initramfs when your tftp boot or whatever is going to be a lot harder to pull off.
08:40 <ncopa> right
08:40 <ncopa> initramfs from tftp
08:41 <ncopa> might also be a usecase
08:41 <TemptorSent> ncopa: Think a laptop you loan out to a not-so-trusted client and want to make sure you got it back without someone adding anythign malicious.
08:41 <ncopa> oh that i think is harder
08:42 <ncopa> if attacker has physical access then the game is more or less over
08:42 <TemptorSent> ncopa: You can still verify all signatures match from an external machine.
08:42 <ncopa> i mean, how do i know he/she didnt open the laptop and replaced the bios
08:42 <TemptorSent> ncopa: Or booting from iso
08:43 <ncopa> in which case you'd have a pre-bootloader rootkit
08:43 <_ikke_> TemptorSent: How do you know if things do not get compromised on the fly somehow?
08:43 <ncopa> if attacker has physical access, the game is over
08:43 <TemptorSent> ncopa: Right, against a highly motivated, higly skilled attacker, you'd be screwed.
08:44 <TemptorSent> _ikke_: Becaue to do so would require comprimising the private keys the files are signed with.
08:44 <ncopa> the attacker could make an identical build of alpine, but with his/her private keys installed
08:45 <TemptorSent> Sure, but then it wouldn't verify on anyone elses.
08:45 <ncopa> so if untrusted part had physical access the only sane thing to do is reinstall from scratch
08:45 <TemptorSent> ncopa: Right, agreed - but you'd like to KNOW whether they did something malicious.
08:46 <TemptorSent> ncopa: Thats the verification and forensics part.
08:46 <ncopa> you raise the bar to pull off that kind of thing
08:46 <ncopa> which is good
08:47 <TemptorSent> It makes it require a targeted attack rather than a one-size-fits-all exploit.
08:47 <ncopa> TemptorSent: what i am trying to do is calculate cost/benefit
08:47 <ncopa> thats why you get al the "critical" questions
08:47 <ncopa> figure the benefit
08:48 <TemptorSent> It's like locking the door on your car -- it won't keep a determined agent from smashing your windows to steal your evidence against them, but it will usually stop the casual crooks.
08:48 <ncopa> i would kind of expect casual crooks not have access to the boot media in the first place
08:48 <TemptorSent> Costs are pretty minimal, a few extra calls to sha512 sum against a handful of files and a couple calls to apk verify
08:49 <ncopa> but i think it is useful to verify that we dont read from media with bad sectors
08:49 <_ikke_> TemptorSent: Until they have a bump-key, which leaves no physical evidence :P
08:49 <TemptorSent> ncopa: Yeah, sadly with things like labs, libraries, etc...
08:49 <TemptorSent> _ikke_: Yeah, been there and done that, but not instant.
08:49 <ncopa> so, this is a new feature
08:49 <ncopa> we currently dont verify this, right?
08:50 <TemptorSent> ncopa: To an extent, it's fixing a gaping hole in existing security.
08:50 <_ikke_> but if the hardware is compromised, then even a reinstallation cannot be trusted
08:50 <ncopa> im not conviced it is a gaping hole, but sure
08:51 <TemptorSent> _ikke_: True, again, casual case is the script kiddie going to the kiosk at the library/hackerspace/whatever
08:51 <TemptorSent> ncopa: Gaping in terms of knowing what your running on your system.
08:52 <TemptorSent> ncopa: Everything else gets verified except the things we REALLY need to be able to check -- the kernel, the initfs, and the modules.
08:52 <ncopa> because we assume that we trust the boot media
08:52 <TemptorSent> The kernel and modules can be signed.
08:53 <ncopa> since we dont sign kernel and modules, we dont bother verify the initramfs
08:53 <TemptorSent> ncopa: Because we can look at the keys contained in the media and see that they match what we have on our servers
08:54 <TemptorSent> The question is WHY don't we currently sign the kernel and modules?
08:54 <yGweSm1OzVHe> regarding lending a laptop, you can still defend against your threat by simply giving out a 2nd boot media and keeping the original with you.
08:54 <TemptorSent> What we should be able to do is stick our boot media in another system run sha512 sums against the files, and verify the sigs with apk against keys external to the media.
08:54 <TemptorSent> Then, we can trust it.,
08:55 <TemptorSent> But stick a usb stick in an untrusted computer and who knows what it might try to do?
08:55 <ncopa> i havent looked into how to sign the kernel
08:55 <yGweSm1OzVHe> i have readonly sticks ;)
08:55 <yGweSm1OzVHe> you can have them too
08:55 <ncopa> i think that would be a bigger "gaping hole" than not verify the initramfs
08:55 <TemptorSent> So it would be REALLY nice to be able to check that said untrusted computer didn't tamper my stick
08:56 <ncopa> and yes, we used read-only media early days
08:56 <ncopa> you could run from cdrom
08:56 <ncopa> which is physically read-only
08:56 <ncopa> we used usb sticks which you could physically make read-only
08:56 <ncopa> floppies too
08:56 <TemptorSent> ncopa: Yes and no, the kernel is a single file, which is easy enough to verify against the one in the kernel package (if it still exists)
08:57 <TemptorSent> Yeah - I don't trust supposedly RO flash much... I've seen some interesting abuses of the spi bus.
08:57 <yGweSm1OzVHe> the booting over tftp is also flawed, as you need to verify the tftpd image before running it
08:58 <ncopa> yeah
08:58 <TemptorSent> yGweSm1OzVHe: And the stub would at least mostly do that.
08:58 blueness joined
08:58 <TemptorSent> If you want to enable secure boot where we have it, that would be great
08:58 <yGweSm1OzVHe> the stub is in the tftp image no?
08:59 <yGweSm1OzVHe> so i can alter your stub while downloading it
08:59 <TemptorSent> yGweSm1OzVHe: Yes, but you can use unique machine info to generate the key.
08:59 <ncopa> i am not against verfying files in initramfs, but i dont think i would like to promote it as a security feature
08:59 <yGweSm1OzVHe> me neither
08:59 <TemptorSent> yGweSm1OzVHe: So your altered stub doesn't actually run becasue it doesn't hit a magic.
09:00 <ncopa> it would be useful to catch packets lost for tftp
09:00 <ncopa> or bad blocks on boot media
09:00 <yGweSm1OzVHe> i'm totally for it, i'm not questioning TemptorSents problem he tries to solve, i'm questioning his solution.
09:00 <TemptorSent> *facepalm* If being able to verify integrity of your files isn't a security improvement, I don't know what is.
09:00 <yGweSm1OzVHe> your arguments are very convincing with your facepalms
09:01 <ncopa> my point is that verifying integrity properly is kind of hard
09:01 <TemptorSent> It doesn't save you from all attackers, but it certainly will make it known when you go to check after the fact if you have differnt hashes in the stub than in the original packages!
09:01 <ncopa> it will raise the bar
09:01 <ncopa> but not solve the problem
09:01 <TemptorSent> The point is right now, we can't referr back a file to it's original source in any whay.
09:02 <yGweSm1OzVHe> let me repeat i would love to see a solution to the problem your fighting, i just don't see how your solution actually is doing that without increasing other attack surface or leaving other gaping holes open making your solution easily circumvented and useles
09:02 <ncopa> the current way to veriy initramfs
09:02 <ncopa> currently, you can download an iso
09:02 <TemptorSent> so /usr/sbin/zfs in the initramfs could have been replaced, and you'd never know it!
09:02 <ncopa> veriy ghte gpg signature
09:02 <ncopa> verify the gpg signature
09:03 <ncopa> now you have a trusted iso
09:03 <TemptorSent> The question is what happens the first time you try to UPGRADE the kernel?
09:03 <ncopa> that is unmodified
09:03 <ncopa> run a checksum on initramfs
09:03 <ncopa> compare with the one on your boot media
09:03 <ncopa> oh
09:03 <TemptorSent> Yeah.
09:03 <ncopa> right
09:04 <TemptorSent> THAT'S the problem.
09:04 <ncopa> we generate the initramfs
09:04 <TemptorSent> Nothing to compare against.
09:04 <ncopa> on a running system
09:04 <TemptorSent> Exactly.
09:05 <ncopa> how about we as a part of mkinitfs create a checksum of it?
09:05 <TemptorSent> So a race condition writing ANY of those files means that someone can slip something in.
09:05 <ncopa> and store that somewhere else?
09:05 <TemptorSent> That's the idea, but rather than just a checksum, a one-off signature.
09:05 <TemptorSent> So we can actually verify the signature on the checksums like we do in APK
09:06 <ncopa> so you would need to have a public key on the running system?
09:06 <TemptorSent> Yes.
09:06 <ncopa> i mean priv/public key
09:06 <yGweSm1OzVHe> and a secret key also for signing?
09:06 <TemptorSent> Nope, the private gets nuked
09:06 <yGweSm1OzVHe> how do you sign without a secret key?
09:06 <TemptorSent> ideally, we'd use a countersigned nonce.
09:07 <yGweSm1OzVHe> on a system where you expect someone slipping in something in your init?
09:07 <yGweSm1OzVHe> but not subverting your secret key?
09:07 <TemptorSent> yGweSm1OzVHe: You generate a temporary key and don't write it anywhere.
09:07 <yGweSm1OzVHe> but on the same system where you suspect someone slipping somethingmalicious in your image?
09:07 <TemptorSent> yGweSm1OzVHe: Avoid the FS and you avoid most of the easy exploits.
09:08 <TemptorSent> yGweSm1OzVHe: It's a lot easier to slip something into /tmp while mktmp is running than it is to get to memory and find the needle youre looking for.
09:08 <yGweSm1OzVHe> how do you know then that the key that was used for signing is the one you and your signer deployed instead of the attacker provided his own sig when slipping in his appending to the cpio?
09:09 <yGweSm1OzVHe> when you later destroy the key? and have no means knowing if it is your key or the attackers?
09:09 <TemptorSent> yGweSm1OzVHe: That's why we would like to countersign it with a user key if possible.
09:09 <TemptorSent> But the nice thing is you don't need a private key to verify a signature, just a well known public and the sig
09:10 <yGweSm1OzVHe> do you have somewhere a document about your threat model? like what attack surface you reduce, what you increase, what are the capabilities of the attacker?
09:10 <TemptorSent> So the nonce becomes a consistencey check and helps protect against downgrade attacks if you keep counter-signing against the previous kernel
09:10 <yGweSm1OzVHe> it seems you are shifting the goal posts
09:11 <yGweSm1OzVHe> a specification would be nice before implementing this
09:11 <TemptorSent> yGweSm1OzVHe: FFS! Look at the bloody stub.
09:11 <yGweSm1OzVHe> calm down mate
09:12 <TemptorSent> https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage/initfs/init
09:13 <TemptorSent> I'm not trying to solve the problems of the world here, I'm just trying to make it harder for someone who isn't actually trying to fool init into snarfing keys or the like.
09:13 <TemptorSent> And let us know when something broke.
09:14 <TemptorSent> So if we trust our host keys, we can read the stub, make sure it's using the same host keys, an we at least know we're running the same init we expect.
09:15 <TemptorSent> And if not, userspace can bitch, moan, and complain.
09:15 <yGweSm1OzVHe> it seems to me it will be easy to try to exploit this as i can easily test my PoCs in qemu against your stub
09:15 <yGweSm1OzVHe> i wish i'd had time for that
09:15 <yGweSm1OzVHe> will you call me then a "sophisticated, determined blackhat"?
09:16 <TemptorSent> If I wanted to exploit it, I'm sure I could too, but I'd have to actually work to do so in a way that wouldn't be easily detected!
09:16 <yGweSm1OzVHe> i'd like to be a cyber APT instead ;)
09:18 <TemptorSent> This will complain or just delete most simple append attacks, make it difficult to replace apk or busybox with something else, and make memory attacks have to alter crypto, not just a few bytes.
09:18 <TemptorSent> If it makes you take 20 minutes rather than 2, it's a win!
09:18 <ncopa> as i said, it raises the bar
09:19 <TemptorSent> And since it can be baked into the kernel, it makes it pretty damn hard to spoof if you can verify the checksum on the kernel or the sigs.
09:20 <TemptorSent> So no, it's NOT secure boot, but it gets you at least some trust that your booting what you meant to boot.
09:20 <TemptorSent> Especially in terms of modules.
09:20 <yGweSm1OzVHe> i have this trust already with much less effort
09:21 <TemptorSent> Even if the modules aren't signed, they're stored in signed tarballs, so if the tarballs don't verify, they don't get extracted.
09:22 <TemptorSent> yGweSm1OzVHe: Then perhaps you can write an update-kernel/mkinitfs that we can trust and I can get ready for mining season rather than sitting behind a monitor.
09:22 <ncopa> TemptorSent: i wonder when i can pull your mkimg
09:22 <ncopa> if you want do the signing of initramfs
09:22 <ncopa> how long time til its ready for productin?
09:22 <TemptorSent> ncopa: TBH, without fixing the trust issue, I'm leary of mkinitfs
09:22 <ncopa> we need plan for the 3.6 release
09:23 <ncopa> other question
09:23 <TemptorSent> ncopa: The stub and baker should be pretty damn close.
09:23 <TemptorSent> The rest of the system is working.
09:23 <ncopa> if you in initramfs detect that something was modified
09:23 <ncopa> what is the action?
09:23 <TemptorSent> I've done a fair bit of documentation cleanup
09:24 <TemptorSent> In the stub, it pukes an reboots currently.
09:24 <ncopa> so if you have a bad blocks of your boot media
09:24 <TemptorSent> It will complain, wait 5 seconds, then reboot.
09:24 <ncopa> or you lose packets on tftp
09:24 <ncopa> it will reboot
09:25 <ncopa> hm
09:25 <ncopa> i think that need to be configurable
09:25 <TemptorSent> Which is the desirable action in most cases I can think of where a transient error may cause failure.
09:25 <ncopa> yup, in most cases
09:25 <TemptorSent> ncopa: No problem, it's a matter of changing a few lines.
09:26 <ncopa> we ned be able to override it
09:27 <ncopa> fixing the issue (corrupt FAT filesysem for example) may need to be done remotely
09:27 <ncopa> so it might be needed to try boot up so at least sshd works
09:27 <TemptorSent> Okay, but do we need that in the stub, or can that live in base?
09:28 <ncopa> i dont know
09:28 <ncopa> i havent looked at your work yet
09:28 <TemptorSent> Basically, the stub just gets the devices setup and is only reading from the initfs, nothing from any hardware.
09:28 <ncopa> did you refactor mkinitfs too?
09:28 <TemptorSent> It is entirely concerned with verifying the contents of the initfs.
09:29 <TemptorSent> Yes, that's done and working :)
09:29 <ncopa> can we push that now?
09:29 <ncopa> and you are confident that it does not break any current running systems?
09:29 <TemptorSent> At this point, no, as I don't have the cross-section of systems to test on.
09:30 <TemptorSent> It needs to be tested and we need to decide what to do about config files.
09:30 <ncopa> wherea re the mkinitfs changes?
09:30 <TemptorSent> I also didn't implement the list features, so if anythign needs those, it won't work now.
09:31 <TemptorSent> plugin-mkinitfs.sh
09:31 <ncopa> full url?
09:31 <TemptorSent> It's building running images for me.
09:32 <TemptorSent> https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage/initfs
09:33 <TemptorSent> For the mkimage wrapper to be used as a standin for the old mkimage, it needs a few minor changes at worst.
09:34 <ncopa> ok
09:34 <ncopa> i am a bit confused now
09:34 <ncopa> so if apk upgrade and get new kernel
09:34 <ncopa> i need to have aport git repo checked out?
09:34 ostera joined
09:35 <ncopa> so plugin-mkinitfs.sh makes sure the generated initramfs gets verified?
09:36 <ncopa> http://git.alpineliwhy dont we fix: nux.org/cgit/mkinitfs/
09:36 <TemptorSent> ncopa: No, not yet -- that's why I'm trying to fix the init issue so I can have it make verifyable tarballs rather than just appending everything to the cpio
09:36 <ncopa> why dont we fix http://git.alpinelinux.org/cgit/mkinitfs/
09:37 <TemptorSent> ncopa: That's what I'm using, essentially, but with support for modular features.
09:37 <ncopa> its a copy of http://git.alpinelinux.org/cgit/mkinitfs/ right?
09:38 <ncopa> why dont we fix and use the upstram mkinitfs?
09:38 <TemptorSent> Much of it, yes, but modified.
09:38 <ncopa> im not happy about having two different versions of mkinitfs used for different situations
09:38 <ncopa> double maintenance
09:38 <TemptorSent> ncopa: Once stabilized, we don't need the other tree.
09:39 <ncopa> "the other tree" is which?
09:39 <ncopa> the plan is to remove the http://git.alpinelinux.org/cgit/mkinitfs/?
09:39 <TemptorSent> ncopa: update-kernel, mkinitfs, mkimage, and overlays all work together basically
09:39 <TemptorSent> Or merge it.
09:40 <ncopa> but update-kernel and mkinifs needs to work without mkimage too
09:40 <ncopa> mkimage is not the only user of those tools
09:40 <TemptorSent> ncopa: I could finish the wrapper and just push that back to mkinitfs.
09:41 <ncopa> that is a prerequisite yes
09:41 <TemptorSent> Right, mkimage is probably a bad name at this point.
09:41 <TemptorSent> it's more like mkalpine :)
09:41 <TemptorSent> It knows how to make an image, or any part of one.
09:42 <TemptorSent> So we don't necessarily need to duplicate functionality for each utility, just call the function we need.
09:42 <ncopa> This branch is 112 commits ahead,
09:43 <TemptorSent> update kernel has a few bits that need to be done seperate from the process of extracting the kernel, modules, firmware, apks, etc, .
09:43 <ncopa> you know that this will be diffcult to merge
09:43 <TemptorSent> ncopa: Yes. The branch really should become a top level repo
09:44 <TemptorSent> There shouldn't be anything touched outside the mkimage directory
09:44 <ncopa> that probably a good idea
09:44 <ncopa> im still scared
09:45 <ncopa> this touches mkinitfs, update-kernel and mkimg
09:45 <ncopa> is more or less a full rewrite o mkimg
09:45 <TemptorSent> Yes.
09:45 <ncopa> its not clear how much is modified from mkinitfs or update-kernel
09:46 <TemptorSent> update-kernel no longer resembles the original and has not been made to attempt to emulate it yet.
09:46 <ncopa> so a complete rewrite there too?
09:46 <TemptorSent> the old update-kernel should be able to work with my mkinitfs code
09:46 <ncopa> that does something different?
09:47 <ncopa> the update-kernel was used to update the kernel on tmpfs installs
09:47 <ncopa> if i have a "live" usb
09:47 <ncopa> that i run for production
09:47 <TemptorSent> And all of the existing mkinitfs should work with output so long as we spit out files/modules to include in its format.
09:48 <TemptorSent> I incorporated the build logic, creation of modloop, etc, but not the mounting/unmounting/remounting as of yet.
09:49 <TemptorSent> It's in kernels/plugin-update-kernel.sh
09:49 <ncopa> can we merge this in smaller chunks?
09:49 <ncopa> so we dont break everything at same time
09:49 <ncopa> eg
09:49 <ncopa> can we replae current update-kernel first for example
09:49 <ncopa> test it
09:49 <ncopa> make sure it does nto break existing usecases
09:50 <ncopa> once its stabelized we take mkinitfs
09:50 <TemptorSent> We can merge all of mkimage, including mkinitfs and update-kernel built into it, but only use mkimage until we've tested the rest.
09:50 <ncopa> make sure that it does not break things for people who upgrade
09:50 <ncopa> then we will have to maintain both in parallel?
09:51 <TemptorSent> mkimage is probably to the point of being ready for actual use.
09:51 <clandmeter> omg.. can you guys please stop typing, im trying to read my backlog but it never finishes.
09:51 <clandmeter> :)
09:51 <TemptorSent> mkinitfs works for mkimage, and should work for the existing update-kernel with minor fixes
09:51 <ncopa> i would prefer fix the dependences (mkinitfs and update-kernel) first
09:52 <ncopa> so they work indepndet of mkimage
09:52 <TemptorSent> so mkinitfs is probably the closest to testing
09:52 <ncopa> in their respective repositories
09:52 <ncopa> ok
09:52 <ncopa> lets start with that
09:52 <ncopa> update-kernel uses mkinintfs too, right
09:53 <TemptorSent> update-kernel in mkimage is currently just doing the extraction and modloop logic then handing of to mkintfs.
09:53 <ncopa> current update-kernel seems to use mkinitfs
09:54 <TemptorSent> Right.
09:55 royger_ joined
09:56 <ncopa> im a bit sceptic to be honest
09:56 <TemptorSent> What we'll want to do is probably make a 'mkalpine' repo, then dump the whole branch in there, then make all three utilities as wrappers.
09:57 <ncopa> as i understand, the origian problem you wanted to solve was fix so you could boot with configs on zfs
09:57 <TemptorSent> We can fix init later if we must...
09:57 <ncopa> you needed zfs userpace tool in initramfs
09:57 <ncopa> and you neded up reimplementing mkimage, mkinits and update-kernel
09:57 <TemptorSent> ncopa: A bit more than just that, I need to be able to make preconfigured, ready-to-run images.
09:58 <TemptorSent> ncopa: Including formatting and partitioning the data disks, having pre-generated ssh keys, etc.
09:59 <ncopa> something like unattended installs
09:59 <TemptorSent> ncopa: The init issue came up when trying to run install on first boot.
09:59 <TemptorSent> ncopa: Yes, lights-out once the disk is dropped in except maybe to confirm that they REALLY want to wipe the systemn,
10:00 <ncopa> so then rewriting the setup-alpine script will be next natural step
10:00 <TemptorSent> Now, I have it doing everything I need except the install-before-first-boot.
10:01 <ncopa> i just wonder where it stops so we can start merging things
10:01 <TemptorSent> Yeah, I was half way there before I even started.
10:01 <ncopa> in my experience big revolutions never work
10:01 <ncopa> incremental changes does
10:01 <TemptorSent> ncopa: Yeah, that's what it's been for me :)
10:02 <ncopa> what i am trying to say
10:02 <ncopa> the more we push things ahead the bigger is the chance that it never will be merged
10:02 <ncopa> we need to start merge pieces
10:02 <TemptorSent> Right now, it's primarly an image builder with shades of mkinitfs and update-kernel
10:03 <TemptorSent> For the purposes of building images, it works for the cases I've tried.
10:03 <ncopa> ok
10:03 <ncopa> lets try mrege in the fixes for mkinitfs first then
10:03 <ncopa> lets do that in mkinitfs repo
10:03 <TemptorSent> For the purpose of being mkinitfs, it works in the cases I have tested, but have not tested on a live system in places of the default
10:04 <TemptorSent> The reason I needed to incorporeate mkinitfs was to get features to have control over their modules and files in the initfs
10:05 <TemptorSent> So the entire features system has been gutted and replaced,.
10:06 <ncopa> and is not backwards complatible?
10:06 <TemptorSent> How exactly we translate the features is likely a bit messy.
10:06 <TemptorSent> Sorta...
10:06 <ncopa> ok
10:07 <TemptorSent> But there was no way to make it backwards compatible and actually modular.
10:07 <ncopa> ok
10:07 <ncopa> so there is no upgrade path for this?
10:07 <ncopa> that needs to be solved first
10:08 <ncopa> we need a plan for this
10:08 <TemptorSent> We can upgrade pretty easily actually...
10:08 <ncopa> i will not merge in mkimage with a clone of mkinitfs that we end up maintain in double for ever
10:08 <TemptorSent> It's how we want to keep track of the various feature files installed.
10:08 <TemptorSent> Currently we don't actually know what's installed, we just have globs.
10:09 <TemptorSent> As an upgrade path, we can just make some features that match the old names and call the new ones.
10:10 <TemptorSent> For instance, ata -> ata_all
10:10 <ncopa> i wonder if we will be able to merge all this for 3.6 release :-/
10:11 <TemptorSent> Given some testing, it shouldn't be too much more to finish up.
10:11 <ncopa> ok
10:12 <ncopa> but if it is a rewrite of basically every tool we have then we do have a problem
10:12 <TemptorSent> mkinitfs features need to be looked at and compatability setup where needed.
10:13 <TemptorSent> ncopa: I'm afraid it pretty much is as far as mkimage/mkinitfs/update-kernel.
10:13 <TemptorSent> The functions of the three are rather tightly knit.
10:14 <ncopa> i understand that
10:14 <ncopa> can we get all the mkinitfs changes in here: https://github.com/alpinelinux/mkinitfs
10:14 <TemptorSent> Maybe...
10:15 <ncopa> if we cannot, then it will never fly
10:15 <TemptorSent> Although it would mean undoing a lot of code.
10:15 <ncopa> we cannot maintain 2 different tools in parallel
10:16 <TemptorSent> I'm not sure how we integrate the features defined in the mkimage tree with mkinitfs if it's broken out.
10:17 <ncopa> then we have a problem
10:17 <TemptorSent> That means maintaining two separate sets of modules, files, and apks.
10:19 <ncopa> we need be able to use mkinitfs withtout mkimage
10:19 <ncopa> mkinitfs is used whenever kernel i upgraded from apk hook
10:19 <TemptorSent> And somehow integrating the kernel building with the old mkimage in the middle
10:19 <ncopa> mkinitfs needs to be an independent tool
10:20 <TemptorSent> Where does it get it's list of what to put in the initfs?
10:20 <TemptorSent> That's the problem
10:21 <TemptorSent> The current system has absolutely no way of pulling the packages it needs, and relies on update-kernel to do that.
10:21 <TemptorSent> So we have deps between packages already that we can't seem to fix.
10:22 <TemptorSent> Why does mkimage need to run every kernel update BTW? Just the modules?
10:22 <ncopa> mkimage is not needed
10:22 <ncopa> mkinitfs
10:22 <TemptorSent> er, sorry mkinitfs
10:22 <ncopa> when we do apk upgrade
10:23 <ncopa> and get new kernel
10:23 <ncopa> then the initramfs needs to be regenerated
10:23 <TemptorSent> Right, why do we actually need to rebuild it?
10:23 <ncopa> so kernel modules in there matches the kernel
10:23 <ncopa> otherwise will we have old kernel modules with new kernel
10:24 <TemptorSent> Why don't we just append those to a stock initramfs?
10:24 <ncopa> how would we do that?
10:24 <TemptorSent> cat modules.cpio.gz >> initramfs
10:25 <TemptorSent> You can append more than one initramfs, which is actually probably the best bet.
10:25 <ncopa> i suppose that would work
10:25 <TemptorSent> So you just use your initramfs and append initramfs-modules-4.x.x
10:26 <ncopa> well
10:26 <TemptorSent> ...which is where I was headed with init... the feature sets become nothing more than tarballs of modules and userspace files.
10:26 <ncopa> right
10:27 <TemptorSent> Then we could actually distribute init features as apk packages and just install them.
10:27 <ncopa> we also need userpsace tools
10:27 <skarnet> TemptorSent: I think you should write a design document and publish the URL here instead of alternatively kidnapping me, ncopa and kaniini
10:27 <skarnet> (and making everyone else run away screaming)
10:27 <ncopa> thats probably a good idea
10:28 <ncopa> write a design document of how you think it shoudl work
10:28 <TemptorSent> initfs-zfs for instance would contain both the modules AND the userspace.
10:28 <ncopa> oh
10:28 <ncopa> one thing
10:28 <ncopa> that will not work
10:28 <ncopa> unless we run depmod from nitramfs
10:29 <TemptorSent> At this point, I'm thinking maybe I should just develop on my branch and you can pull what you like.
10:29 <ncopa> the reason why we regenerate the initramfs is that depmod needs to run
10:29 <TemptorSent> ncopa: Why? We'll have all modules and their depmods.
10:30 <TemptorSent> At worst, we cat them all together.
10:30 <ncopa> the /lib/modules/4.9.17-0-grsec/modules.dep
10:31 <ncopa> and modules.dep.bin
10:31 <TemptorSent> Right, we just run depmod against each tree when we build or run in initramfs before loading modules
10:32 <TemptorSent> We're already calculating the deptree when we build the features.
10:35 <ncopa> you are aware that this is a major re-design of things that we have used for a decade
10:35 <ncopa> and that has matured over a decade
10:36 <TemptorSent> ncopa: Actually, no -- I don't have a lot of history on Alpine, which is why I'm asking what may seem like stupid questions.
10:37 <ncopa> its not stupid questions
10:37 <ncopa> im just thinking how we merge this thing
10:37 <TemptorSent> I'm not pushing for any of this to be mainlined, I thought it was something that filled a need.
10:37 <ncopa> for v3.6
10:37 <ncopa> yes, i understand
10:37 <ncopa> the thing is
10:38 <ncopa> i dont want have 2 different mkinitfs
10:38 <TemptorSent> I was trying to make a good image building tool.
10:38 <skarnet> ncopa: if you're in the finish line for 3.6, it can wait until 3.7
10:38 <ncopa> one that is used for generating the image
10:38 <skarnet> I mean, a freeze is exactly the moment when you don't want to pull major changes, even if those changes are good :P
10:38 <ncopa> and one that is used for apk upgrade of kernel
10:38 <ncopa> yes
10:39 <ncopa> but then will the changes be even bigger
10:39 <ncopa> for the next cycle
10:39 <TemptorSent> ncopa: mkinitfs from mkimage will work for building the system, but it needs to know what to build in.
10:39 <skarnet> they may be a little bigger but we will have *much* more time to integrate them
10:40 <ncopa> it would be nice if we could integrate some of the things in mkinitfs
10:40 <TemptorSent> The existing mkimage just globs everything in the path and has no way of knowing which packages it needs.
10:40 <skarnet> you're the boss - the only thing I don't like is spending nights here trying to understand how it works and feeling pressured for time
10:40 <ncopa> that we might need fix
10:40 <skarnet> happened too many nights already
10:41 <ncopa> hm
10:41 <ncopa> yeah
10:41 <skarnet> I like the idea of the change, I like some of the implementation too
10:41 <ncopa> yes same
10:41 <skarnet> but I wish I could process it at my own pace
10:41 <TemptorSent> So for it to know what is needed for a given feature to work, it needs the features files.
10:41 <ncopa> i am afraid that if we dont merge this in chunks, it will never be merged
10:41 <TemptorSent> I'd be more than happy to table this for a couple months.
10:42 <skarnet> chunks sounds good, but I'd advise focusing on getting 3.6 out first unless you can find a chunk that can be integrated right now
10:42 <ncopa> yes
10:42 <TemptorSent> I'm going to finish up what I need for system I need to support, but beyond that, it can sit and wait.
10:43 <ncopa> i was looking for a chunk thatcan be mreged for v3.6
10:43 <ncopa> as i understand the config fiels for mkinitfs changes dramatically
10:43 <ncopa> which might be a good thing
10:43 <ncopa> mkinitfs becomes more modular
10:43 <ncopa> which is something i have wanted a long time
10:44 <skarnet> yes
10:44 <TemptorSent> Yes, but it also integrates with features in general...
10:44 <ncopa> so what i am thinking
10:44 <TemptorSent> So including the zfs feature in an image pulls in the zfs initfs features.
10:44 <skarnet> again, the change is good, but I don't want to be rushed reviewing it
10:44 <skarnet> or analyzing it to find something you could integrate in 3.6 :)
10:45 <ncopa> skarnet: the problem is that is solves a current issue with the release images
10:45 <TemptorSent> Take a look at the files, they are pretty damn close to what was there before, except encapsulated in functions so they can be manipualted.
10:45 <skarnet> what's the current issue?
10:45 <ncopa> it is not possible to build a release image, which will find the apkovl on zfs
10:45 <skarnet> and you want zfs support for 3.6 ?
10:46 <ncopa> because the generated initramfs will not include the needed userpace tools
10:46 <ncopa> same goes for lvm or mdadm
10:46 <TemptorSent> right :)
10:47 <skarnet> is that a regression or not?
10:47 <ncopa> sort of
10:47 <ncopa> we had alpine-iso earlier
10:47 <skarnet> is it something you promised would be fixed in 3.6?
10:47 <TemptorSent> Currently the way I'm using mkinitfs is just setting up a profile and building.
10:48 <ncopa> not promised, but it would be really good to have it fixed
10:49 <TemptorSent> To fix mkinitfs properly, we need to figure out exactly which packages we need for each of the various features still and tag them.
10:49 <skarnet> get 3.6 out and let's work on that immediately after the release. It will take the time it takes. It will be done for 3.7. If it's ready earlier, nothing prevents you from cutting out a 3.6.1 with the change.
10:49 <TemptorSent> From there, we could just copy all init- files out of mkimage to generate the feature database.
10:49 <ncopa> skarnet: unless it is a major redesign
10:49 <TemptorSent> And teach mkinitfs to handle the apks on its own.
10:50 <TemptorSent> That still leaves us with update-kernel to fix properly later, but should make it mergable.
10:50 <skarnet> ncopa: what's the issue, you can't change designs between two minor releases?
10:50 <ncopa> not if it requires users to change their config files
10:51 <skarnet> then make it an early 3.7
10:51 <skarnet> I mean, it's just naming
10:51 <TemptorSent> ncopa: I *think* we can get away without config file change, but it won't fix anything for those who really need it.
10:52 <skarnet> or do you have corporate pressure to follow a regular release schedule that's fixed in time?
10:52 <ncopa> TemptorSent: the way mkinitfs works now, it know nothing about apk at all
10:52 <TemptorSent> ncopa: Exactly the problem -- it doesn't have any way of knowing if the files it needs even exist!
10:53 <ncopa> but i suppose update-kernel may need the file -> apk mapping
10:53 <ncopa> feature -> apk mapping
10:53 <TemptorSent> ncopa: And that's where things break currently.
10:53 <ncopa> yup
10:53 <ncopa> i understand
10:53 <TemptorSent> That's why both got dragged into mkimage.
10:54 <TemptorSent> The image generating is almost a byproduct at that point :)
10:54 <ncopa> and ended redesigning the entire world :)
10:54 <TemptorSent> I coudn't make images the way I needed to without doing it.
10:55 <ncopa> i understand
10:55 <ncopa> and i am not against it
10:55 <ncopa> what i want, is to start in the right end
10:55 <TemptorSent> There was no sane way of altering configurations.
10:55 <ncopa> so we need to redesign the configurations
10:55 <ncopa> right?
10:56 <TemptorSent> Okay, I guess the question is what exactly in mkinitfs has to work as it did to be usably compatible?
10:56 <TemptorSent> Yes, at least the feature files/modules.
10:57 <TemptorSent> And the naming mostly has to change for sanity sake, but we can grandfather the old feature names.
10:59 <ncopa> this is from apk trigger:
10:59 <ncopa> abi_release=$(cat "$i"/kernel.release)
10:59 <ncopa> initfs=initramfs-$flavor
10:59 <ncopa> mkinitfs -o /boot/$initfs $abi_release
11:00 <ncopa> that needs to work
11:00 <TemptorSent> The biggest change, aside from scrapping a whole lot of logic and replacing it with a short wrapper, is fixing the craziness of config files.
11:00 <ncopa> lets thart with the config files
11:00 <TemptorSent> Hmm, with features, it should work.
11:00 <ncopa> how do we want them
11:01 <ncopa> also users may have their config in /etc/mkinitmfs/mkinitfs.conf
11:01 <TemptorSent> Take a look at what I have in mkimage/initfs/initfs-features
11:01 <TemptorSent> That's fine, and supported as-is with the names added.
11:02 <TemptorSent> In fact, looking at it, as long as we source the feature files first, it might work as is.
11:02 vakartel joined
11:03 <TemptorSent> I'd have to cut out my utility functions or put those where they could be sourced...
11:03 <TemptorSent> 'warning
11:03 <TemptorSent> 'file_is_writable' and 'mkdir_is_writable' come to mind
11:04 <TemptorSent> ...and I'd have to stick the apk code there...
11:05 <TemptorSent> But that's easy enough, and we can include the apk list directly in each feature.
11:08 <TemptorSent> It looks like Id have to add back the default check for /etc/mkinitfs/mkinitfs.conf in an if statement to use the standard one again.
11:10 blueness joined
11:12 <TemptorSent> As far as the wrapper goes, the only things not implemented are -K (defaults on), -P (wasn't used by mkimage), -l/-L (not implemented, shouldn't be hard if needed), and -q (I'm debugging, who wants quiet?)
11:13 <skarnet> quiet is sounding pretty good right now :P
11:14 <TemptorSent> And I really need to get to sleep soon.
11:14 <TemptorSent> I've been up about 23 hours at this point.
11:15 <TemptorSent> ...and need to be up in another 4
11:18 elroncio joined
11:40 <ncopa> get some sleep
11:41 <TemptorSent> Yeah, very soon, else it will start getting light and I'll end up not sleeping another full day
11:42 <TemptorSent> I've got a totally screwed internal clock.
11:49 gromero joined
11:50 rdutra joined
12:04 leitao joined
12:16 ferseiti joined
12:18 farosas joined
12:36 elroncio joined
12:39 czart_ joined
12:54 blueness joined
13:06 blueness joined
13:08 t0mmy joined
13:16 tty` joined
13:52 farosas joined
14:10 elroncio joined
14:29 fabled joined
14:36 <leitao> jirutka, another upstream package hacked. ncftp-3.2.6-src.tar.xz has a different checksum. Do you manage to have the old one?
14:36 <jirutka> leitao: I don’t have, but we already know about this one
14:37 <jirutka> leitao: https://github.com/alpinelinux/aports/pull/1111
14:49 vakartel joined
14:52 <^7heo> I'm trying to create an openssl serial, and I get '119534120156044:error:0D066096:asn1 encoding routines:a2i_ASN1_INTEGER:short line:asn1/f_int.c:200:'
14:52 <^7heo> Did anyone ever stumble over that?
14:53 algitbot joined
14:57 <^7heo> ncopa: ^ any clue?
14:57 <^7heo> ncopa: I'm not sure anyone ever tried to generate a serial with libressl openssl.
14:57 <^7heo> on alpine.
14:57 <^7heo> maybe we're missing something in the APKBUILD.
14:58 <ncopa> we should contact ncftp devs and ask whats going on
14:58 <^7heo> I'm gonna toy a little with the APKBUILD first.
14:58 <ncopa> ^7heo: no idea
14:59 <ncopa> maybe ask in #libressl
14:59 <^7heo> maybe there's a missing ./configure flag
14:59 <^7heo> yeah
14:59 <^7heo> if my attempt fails, I'll do just that.
15:00 farosas joined
15:03 leo-unglaub joined
15:05 <kaniini> ncopa: http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/py-gnuplot/py-gnuplot-1.8-r0.log but these packages are already built
15:05 <kaniini> ncopa: i think there is something broken with ppc64le builder :/
15:09 <^7heo> ncopa, kaniini: do you know what a "short line" means?
15:10 <^7heo> I mean, aside from "expected to read more bytes before \n"
15:29 loopz_ joined
15:31 <ncopa> kaniini: testing/py-gnuplot does not seem to be built? http://rsync.alpinelinux.org/alpine/edge/testing/ppc64le/
15:32 <kaniini> ncopa: i mean the dependencies
15:32 <kaniini> ncopa: gnuplot has been built for some time
15:32 <ncopa> ok
15:33 <ncopa> but its in community
15:33 <ncopa> it doesnt find it in community then
15:33 <kaniini> right, i think there's a configuration problem
15:33 <ncopa> i think you are right
15:34 <ncopa> and i think i have just worked around it on x86_64 builder
15:35 <ncopa> ok i added same workaround to ppc64le builder
15:52 <kaniini> ncopa: main/freeradius also has not been built yet, despite all dependencies satisfied :/
15:58 <kaniini> looks like that did clear most of testing though
16:10 atmoz joined
16:26 <^7heo> ncopa: problem solved, that was a pebcak
16:57 <xentec> ncopa, kaniini: could you please backport the following abuild typo fix to 3.5? http://git.alpinelinux.org/cgit/abuild/commit/?id=a7f9bff0f73dba6a82af6ccc60fdd2fab73a6566 I have to setup cross compilers for armhf a lot and this typo bugs me really often.
17:18 blueness joined
17:56 Emperor_Earth joined
18:01 blueness joined
18:24 <^7heo> xentec: on the other hand, we're on the starting blocks for 3.6
18:26 <xentec> ^7heo: yeah, I keep track of your work, but there are still ~3 months (?) until release and that's some time
18:27 <^7heo> possibly indeed
18:27 <^7heo> say
18:27 <^7heo> isn't armhf supposed to be v7?
18:28 <xentec> since everything made with armhf is armv6. I guess not
18:29 <xentec> s/armhf/gcc-armhf/
18:31 <^7heo> I'm asking that because: "In Debian Linux, and derivatives such as Ubuntu, armhf (ARM hard float) refers to the ARMv7 architecture"
18:31 <^7heo> https://en.wikipedia.org/wiki/ARMhf#Floating-point_.28VFP.29
18:32 <^7heo> even https://en.wikipedia.org/wiki/ARM_architecture#Floating-point_.28VFP.29
18:32 <^7heo> actually.
18:34 <kaniini> xentec: 3.6 will be released on time
18:34 <kaniini> we are not going to have delays like 3.5
18:34 <kaniini> if something puts the release date at too much risk, we will back it out
18:36 <xentec> I didn't even know about that :). I was just not sure about the release cycle.
18:37 <kaniini> we are already increasingly conservative in what is allowed to land in edge as a first step in preparing for the 3.6 freeze
18:40 <xentec> so, for which date is the 3.6 release planed?
18:41 <kaniini> early may
19:05 Emperor_Earth joined
19:27 <kaniini> leitao: i updated https://wiki.alpinelinux.org/wiki/Ppc64le and started stubbing out some documentation for the port itself
19:28 <kaniini> clandmeter: why the hell can i not add links to the wiki
19:28 <leitao> kaniini, cool!
19:28 <leitao> kaniini, I will improve it with some details
19:29 <kaniini> a hardware list would be nice
19:29 <kaniini> there's other openpower servers out there
19:30 <kaniini> but nobody knows how to buy them
19:30 <kaniini> so if you happen to know, expanding that list would be nice
19:34 <kaniini> this is different than the /other/ ibm port, s390x where, well, the answer is pretty obvious
19:43 <leitao> kaniini, I have the machine list, but I am not able to post there
19:44 <kaniini> thats unfortunate
19:44 <leitao> https://pastebin.com/DjM1M2Mw
19:44 <leitao> unless I don't point to the machine spec site.
19:44 <leitao> but this will not be helpful, since IBM machine names are a bit confusing
19:45 <leitao> kaniini, as you can see in the pastbin
19:45 <kaniini> yeah
19:45 <kaniini> i'll try to figure out where you can get the ones from tyan/gigabyte
19:45 <kaniini> or perhaps clandmeter can help with the gigabyte side
19:45 <kaniini> i think ppc64le alpine port is good because power is fully open boot
19:45 <leitao> kaniini, there are other vendors also, winstron, supermicro
19:46 <kaniini> supermicro??? really?!
19:46 <leitao> yup
19:46 <kaniini> that one might actually be buyable
19:46 <leitao> kaniini, yup
19:46 <leitao> kaniini, have you ever heard about this project? https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation
19:46 <kaniini> yes
19:47 <kaniini> alpine would be a much better target OS for that than ubuntu
19:47 <kaniini> :)
19:53 <kaniini> damn, i cannot find SKUs for supermicro power8 stuff
19:53 <kaniini> maybe its not out yet
19:57 <leitao> kaniini, yea, I am not aware of the machines schedule.
20:01 farosas joined
20:04 ostera joined
20:09 <gromero> jirutka: https://github.com/alpinelinux/aports/pull/785 I guess it's fine now on ARM
20:11 <gromero> jirutka: also discussing the issue on #musl if dalias, really no better approach at the time
20:11 <gromero> *with dalias
20:15 <jirutka> gromero: please discuss this with fabled, this stuff is too low level for me :)
20:15 <kaniini> it is fine
20:15 <kaniini> i reviewed it
20:15 <kaniini> it wont break arm
20:15 <gromero> kaniini: thanks
20:16 <kaniini> and off it goes
20:23 <jirutka> okay, so I’m gonna merge it
20:23 <jirutka> ah, I’m late to the party XD
20:47 <gromero> jirutka: thanks anyway ;-)
21:25 Long_yanG joined
22:25 farosas joined
22:31 laj joined
22:33 rdutra joined
22:43 LouisA joined
23:32 blueness joined