<    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:16 kazblox joined
01:27 dirac1 joined
01:29 <pickfire> kahiru: Not sure about that but probably it works with the aarch64 image.
01:49 kazblox2 joined
01:55 s33se joined
02:29 Emperor_Earth joined
02:52 ahrs joined
03:04 mguentner joined
03:23 white_knight joined
03:24 kazblox joined
03:45 mguentner2 joined
05:12 p3rmagriN joined
05:25 grayhemp joined
05:48 grayhemp joined
05:57 rsal joined
06:20 alacerda_ joined
06:23 grayhemp joined
06:26 terra joined
06:35 <kahiru> pickfire: I'd be quite surprised if the aarch64 image worked as-is
06:36 <pickfire> kahiru: Not sure, haven't tried alpine on c2, just tried alarm.
06:37 <TemptorSent> 'evening pickfire.
06:37 <pickfire> Tried alpine on rpi 3 as well.
06:37 <pickfire> TemptorSent: Hi
06:37 <kahiru> pickfire: I'm running alarm there atm. but meh
06:37 <kahiru> it just isn't alpine
06:37 <TemptorSent> How'd the rpi3 go?
06:37 <pickfire> TemptorSent: Evening.
06:37 <pickfire> TemptorSent: Nice and easy.
06:37 <pickfire> kahiru: Alarm is nice for arm devices, they provides optimized builds.
06:38 <pickfire> TemptorSent: Just the part for setting up is a bit complicated.
06:38 <TemptorSent> pickfire: It'd be nice if we could use it in aarch64 mode, but I guess we still don't have 64bit support from the upstream for the blobs/drivers aside from bootloading.
06:38 <TemptorSent> pickfire: What'd you have to do?
06:39 <pickfire> I mean need to do some reading to setup the sys mode.
06:39 <pickfire> Because it can't be setuped just like that.
06:40 <pickfire> TemptorSent: Sorry that I haven't been sending much patches to alpine dev since I was a bit busy.
06:40 <TemptorSent> pickfire: Hmm, ideally we could just drop it in and it boot.
06:40 <pickfire> Yeah, it boots.
06:40 <TemptorSent> pickfire: No problem, I got sidetracked somewhat analyzing the boot process while trying to clean up init.
06:40 <pickfire> In data mode IICC or something similar.
06:41 <pickfire> IIRC*
06:41 <TemptorSent> We have no way of verifying our boot artifacts (kernel, initramfs, modules) once they're made currently.
06:41 <TemptorSent> pickfire: Hmm, so the bootloader isn't picking up the options properly?
06:41 <pickfire> TemptorSent: No
06:42 <TemptorSent> pickfire: I know it's funky, but I didn't look at the details.
06:42 <pickfire> setup-disk can't switch to sys mode for rpi
06:42 <TemptorSent> Oh, yeah -- setup-disk is a 3 trick pony :)
06:42 <pickfire> TemptorSent: I haven't tested your iso generator in arm devices.
06:43 <TemptorSent> It builds tarballs with boot configs in theory for uboot, and rpi configs for pis
06:44 grayhemp joined
06:44 <TemptorSent> pickfire: And part of where I got tangled in the init mess is trying to find a clean way of hooking in a first-boot installer so we can net-boot a stub and install from that.
06:45 <pickfire> Ah
06:45 <pickfire> TemptorSent: So you aim to make it flexible such as getting netboot on the first boot.
06:45 <TemptorSent> pickfire: Currently, we end up having a lot of useless modules and such to deal with, and no way of knowing that we have the right versions or that they're intact.
06:46 <pickfire> Maybe don't put the useless modules into the iso or let the user configure which modules they want (I think you already do that).
06:47 <TemptorSent> pickfire: Yeah, see what I'm working on to fix the trust issue at http://termbin.com/eq512
06:48 <TemptorSent> pickfire: The problem at present is modloop, and the bigger problem it brings up is WTF do we know about the contents of modloop and how do we verify it?
06:48 tmh1999 joined
06:48 <TemptorSent> pickfire: And this is painfully apparant, as I'm on a system that somehow did a kernel upgrade which gave me the kernel from one revision and the modules from the next!
06:49 <TemptorSent> pickfire: So my initfs modules were good, but my modloop are not.
06:49 <TemptorSent> pickfire: This shouldn't happen, either during install or boot without at the very least some nasty warnings.
06:50 <TemptorSent> The kernel knows how to handle signed modules and reject those with bad sigs, but can allow unsigned.
06:52 <TemptorSent> pickfire: Between that, and baking in the stub loader with a verified stub loader and keys, I think we can at least be sure we're running what we installed and it hasn't the files altered.
06:52 <TemptorSent> pickfire: Hopefully the logic there makes sense.
06:54 <TemptorSent> pickfire: Once we've loaded the stub, verified ourselves vs. our internal sums, we extract our base payload from a apk-signed tarball, double check our sums against those (which were signed with the same key as the kernel presumably).
06:55 <TemptorSent> From there, we can include whateve payload we need to boot our particular environment as a signed tarball, and init-base (which has an empty environment except BB, APK, and DIRTY) take over, reading options previously written out to files in /.init.d/env
06:56 <TemptorSent> This should let us ensure crypto keys are not thrown around decrypted and that we don't have unsecured payloads loading before our intended boot using and append.
06:58 <TemptorSent> It also provides us with some at least reasonably authenticated (or at least out of band and verifyiable) keys to verify the integrity of any net-boot payload.
06:59 <TemptorSent> ...all from a chicken and egg problem with the host keys in the image.
06:59 <TemptorSent> So, do you trust the keys in the initram fs or on the filesystem?
07:00 <TemptorSent> We're not there yet, but presumably we could utilize secureboot/tpm if we can maintain the chain of trust.
07:00 gogoprog joined
07:03 rollniak joined
07:05 <clandmeter> pickfire, i installed alpine 3.5 yesterday on alpine in semi sysmode.
07:05 <clandmeter> err on rpi3
07:05 <clandmeter> need more coffee
07:10 <ekarlso> what's the benefit of alpine on a rpi clandmeter vs raspian ?
07:10 <TemptorSent> ekarlso: raspian is rather heavy for embedded applications and not something I'd care to try to secure.
07:11 <clandmeter> ekarlso, not sure the platform matters, alpine is just different then debian.
07:13 <TemptorSent> ekarlso: raspian-light would be better comparison, but I suspect your looking at approaching an order of magnituded difference in installed size (excluding kernel, since it 's the same)
07:14 <TemptorSent> ekarlso: rasbian is an educational tool with all sorts of cool (and proprietary) software.
07:14 <clandmeter> and i dont know enough about raspbian to do a full comparison.
07:14 <TemptorSent> Wolfram Research :)
07:14 <ekarlso> :o
07:15 <pickfire> I think I have found some errors for sway crushing suid stuff. http://ix.io/piH
07:15 <* pickfire> reads
07:16 <TemptorSent> ekarlso: Which is great for using it as something to hack around with or use in a class or whatnot, but not so great when you're trying to use a rpi for a specific purpose, especially on the modules.
07:16 <clandmeter> and alpine runs from ram by default on rpi, which makes it much faster at cost of memory usage.
07:17 <TemptorSent> ekarlso: Basically it boils down to use the right tool for the job.
07:17 <pickfire> TemptorSent: I will probably trust the key on the filesystem.
07:17 <TemptorSent> pickfire: But how did that filesystem get mounted?
07:17 <pickfire> ekarlso: Alpine is probably faster since it uses musl.
07:17 <clandmeter> thats not always true
07:18 <clandmeter> so yes, probably possible :)
07:18 <pickfire> But IIRC alpine doesn't provides optimized compiled packages for arm.
07:18 <TemptorSent> pickfire: It comes down to we can verify pretty much everything on the system EXCEPT the kernel/modules/initramfs.
07:18 <pickfire> ekarlso: If you want, go alarm.
07:19 <pickfire> clandmeter: And probably smaller binary as well.
07:19 <TemptorSent> pickfire: In fact, if we use signed apkovls, it is the only missing link in being able to run a static analysis of an image and verify it.
07:19 <clandmeter> alarm?
07:19 <pickfire> TemptorSent: But if someone tampered with the signature as well?
07:20 <pickfire> clandmeter: arch linux arm
07:20 <pickfire> Arch Linux ARM -> ALARM
07:20 <Xe> http://seclists.org/fulldisclosure/2017/Mar/63
07:20 <clandmeter> lol
07:21 <TemptorSent> pickfire: Right, you have to trust some signature, sometime - the point is that can you tell if the kernel/initramfs/modules you're running are actuall the ones that came in your signed packages?
07:21 <pickfire> I wonder why sway without x11 doesn't get any input ]
07:21 <IcePic> for 64bit, ALAARM 8-/
07:21 <pickfire> http://ix.io/piJ
07:21 <scv> why the heck does a washer have a shadow file
07:21 <* scv> beats head into desk
07:22 <pickfire> TemptorSent: Initramfs and kernel probably yes but I don't think modules can.
07:22 <TemptorSent> pickfire: It wouldn't prevent a malicious user, it would prevent undetected tampering.
07:22 <Xe> scv: internet of things IFTTT integration?
07:22 <TemptorSent> pickfire: Actually, the kernel itself supports the verification of signed modules.
07:22 <clandmeter> well atleast a Miele lasts forever they say.
07:22 <scv> Xe: internet of shit -_-
07:23 <clandmeter> hope they provide sw updates that long...
07:23 <Xe> scv: the "s" in IoT stands for "security"
07:23 <scv> ha
07:23 <scv> thats a good one
07:23 <clandmeter> :)
07:23 <TemptorSent> pickfire: The idea being that you install a kernel package which has a baked-in stubloader, which contains the keys used to build it and checksums for each.
07:24 <Xe> though, threats of lawsuits might finally get IoT to be secured better
07:24 <pickfire> Ah, haven't heard of that.
07:24 <TemptorSent> pickfire: So you have the signature on the kernel package to verify, and you verify the signature of each and every file involved in boot.
07:24 <Xe> as in that might be the impetus they need to actually care about security
07:25 <pickfire> I heard they say IoT are botnets but I wonder why.
07:26 <Xe> because the "s" in IoT stands for "security"
07:26 <TemptorSent> pickfire - because nobody building those thigns gives a shit about anything other than 'coool featurez' or 'easy remote diagnositcs', neither of which are particularly compatible with 'well secured'
07:26 <TemptorSent> Xe :)
07:26 <Xe> unsecured IoT devices that have public facing ports are basically hacked instantly
07:26 <pickfire> How?
07:26 <Xe> by botnets that target them
07:27 <pickfire> Can a public facing ports be hacked instantly?
07:27 <Xe> it's within a few hours, but in the grand scheme of things instant
07:27 <TemptorSent> Is it really hacking when you do ssh 'root@' and get '# ' without so much as a request for a password?
07:28 <pickfire> What?
07:28 <pickfire> ???
07:28 <TemptorSent> Considering the number of buggy routers out there, it's almost trivial to get them to bounce-open ports.
07:28 <pickfire> > get '# ' without so much as a request for a password?
07:28 <TemptorSent> pickfire: Yes, it's that bad in places.
07:28 <pickfire> That's insane
07:29 <Xe> TemptorSent: if it's not hacking, then we need a term for it because it's everywhere
07:29 <TemptorSent> pickfire: And that's an improvement, it used to be just telnet and you're into the router :)
07:29 <TemptorSent> from ANYWHERE.
07:29 <pickfire> Xe: I didn't even knew that.
07:29 <pickfire> Oh, that's not even hacking.
07:29 <pickfire> That's public access
07:29 <Xe> most of the time they download a botnet binary to the device
07:30 <pickfire> That's the best security that I have ever heard of
07:30 <Xe> i kinda consider that the "hacking" part
07:30 <TemptorSent> pickfire: ANYBODY can log in, you might have to guess a few letters to get adminstrative access.. then again, try 'SECRET' or 'ENABLE'
07:30 <pickfire> Haha, ssh for root
07:30 <pickfire> Wow
07:30 <pickfire> I have never even enable ssh for root.
07:30 <TemptorSent> Xe: Yeah downloading a file is hacking these days... *shakes head*
07:31 <Xe> TemptorSent: it probably stays alive thanks to the wrath of cron
07:31 <TemptorSent> pickfire: ssh is the only root access I allow, and that's restricted to local net.
07:31 <TemptorSent> Xe: *LOL* Oh, if the old RADIUSd servers could talk..
07:32 <pickfire> TemptorSent: I will never allow that.
07:32 <TemptorSent> Xe: People treat running PPP over some random protocol as a wrapper is a hack these days :)
07:33 <pickfire> Not even to local server, need to pass normal user ssh (pub key with pass) then only can sudo -i with pass as well.
07:33 <TemptorSent> pickfire: How do you allow root access? Do you trust your local users?
07:33 <pickfire> TemptorSent: I only allow root access to myself only.
07:33 <pickfire> No others are allowed.
07:34 <pickfire> I mean with the help of group wheel.
07:34 <TemptorSent> pickfire: Right, but how do you gain secure remote access?
07:34 <pickfire> ssh? locally
07:35 <pickfire> Of course ssh locally first to add the key then only remove password authentication.
07:35 <TemptorSent> pickfire: Yeah, more for things like system backups (zfs send) and the like.
07:35 <pickfire> Oh, I rarely do backups since I don't have storage here.
07:35 <pickfire> I do backup from laptop to pi though with rsync.
07:35 <TemptorSent> pickfire: I don't allow root logins except from terminal at home or ssh from internal network using trusted key
07:35 <pickfire> rsync protocol or ssh
07:36 <pickfire> Ah
07:36 <pickfire> Well, the only way for root logins is to ssh to my onw user first.
07:36 <TemptorSent> pickfire: Essentially I use a DMZ so I can tunnel secure root connections over my already authenticated user connections.
07:37 <TemptorSent> pickfire: Sounds like we're doing essentially the same thing, just with opposite wrapping directions.
07:38 <pickfire> TemptorSent: What is DMZ actually? I have heard of it.
07:38 <pickfire> Ah
07:38 <TemptorSent> De-Milterized Zone
07:38 fekepp joined
07:38 <pickfire> Something like a honeypot.
07:38 <IcePic> middle zone between full protection and the outside
07:39 <pickfire> TemptorSent: I don't use that since I have no other devices at home.
07:39 <TemptorSent> Nothing more than an environment with minimal privs and strong authentication you must connect to before you can establish a connection through it to the internal netowrk.
07:39 <pickfire> But probably can do a firejail for that and break the jail with password again.
07:40 <TemptorSent> pickfire: I run it even on a single host as needed.
07:40 <pickfire> ?
07:40 <TemptorSent> Basically, yes, that's the same idea
07:40 <pickfire> Single host?
07:40 <TemptorSent> pickfire: Yes, running a chroot jail, tap, bridge, and back-to-back firewall rules.
07:41 <pickfire> Oh, sounds complicated.
07:41 <TemptorSent> pickfire: basically an internal VPN that only allows connections from untrusted zones by first connecting to the DMZ and authenticating, then you tunnel through.
07:41 <pickfire> I just setup sshguard for security.
07:42 <pickfire> Yeah, basically using DMZ as a tunnel.
07:42 <TemptorSent> pickfire: Not really complicated, but a VM works better.
07:42 <* pickfire> had never successfully used tap or bridge
07:42 <TemptorSent> You run things in reverse, with the VM getting the actual network hardware via pci-pass and it running your firewalling.
07:44 <TemptorSent> That eliminates two major vectors for breach, in that the host OS can't accidentally leak what it's not actually touching, and that you can depriv the VM such that any breach there can't write anything.
07:46 <TemptorSent> So your security system is essentially running in immutable mode, with the only means of touching it being to rewrite it from INSIDE the host and update it, probably with some manual intervention to make it really secure.
07:46 <TemptorSent> (Yes, that's one of the images I intend to setup for mkimage -- a nested system with kvm outer and firewall / storage inner.
07:47 <TemptorSent> Hmm, I've usually had pretty good luck with both taps and bridges (and tun too at one point)
07:49 <TemptorSent> Hmm, I guess getting configs like this out there might open a few eyes as to real, vs. perceived layered security.
07:50 <kahiru> TemptorSent: could you ping me if/when you do?
07:51 <TemptorSent> kahiru: Working on it now, have part of it working enough to start messing with, but haven't done anything on the FW part yet.
07:52 <TemptorSent> kahiru: I can currently build vm images with baked in services quite easily, including one-off ssh key-pairs for root login, root user, and host.
07:53 <TemptorSent> kahiru: I haven't started messing with the FW portion yet, mostly because that appears to be a largely solved problem.
07:54 <TemptorSent> kahiru: The only tricky part is shaving the VM images to just what's needed, nothing that's not, and making them run cleanly in a RO environment.
07:55 <TemptorSent> kahiru: The work I'm doing on init now will facilitate that, so it will be a run-from-ram VM image with no access to write anything attached to a file system, and all logging etc done over the network.
07:59 <TemptorSent> kahiru: Even for minimal configs without VMs, we can do things much cleaner by isolating internal and external network traffic from within the same host and only allowing outgoing external traffic on the specified interface and to the specified gateway.
08:01 sparklyballs joined
08:17 subscope joined
08:19 rrx joined
08:20 grayhemp joined
08:34 <kahiru> TemptorSent: sounds interesting
08:57 gogoprog joined
08:59 lesion joined
09:00 royger joined
09:02 gogoprog1 joined
09:02 t0mmy joined
09:02 ncopa joined
09:02 fekepp joined
09:41 uma joined
09:43 <uma> hi everyone. since php7.1 and php7.0 now share the same package names, I'm struggling to select which one I want to install
09:43 <uma> http://pkgs.alpinelinux.org/packages?page=6&name=php7%2A
09:44 <uma> what is the correct syntax for the --repository option? I want community (7.0) but I keep getting 7.1
09:44 <uma> (^ in apk add, sorry)
09:48 stwa joined
09:51 grayhemp joined
09:54 <TBB> you should basically decide whether you want to stay in stable or go edge
09:55 <TBB> a sane approach is to stay in stable, tag the edge repos and only install what you need from edge using apk add package@edge
09:56 <^7heo> moin alle
09:56 <TBB> sup ^7heo
09:56 <^7heo> CEST happened.
09:57 <^7heo> Everyone feels like a zombie.
09:57 stwa joined
09:57 <TBB> me included, although a couple other factors might have had a part in that :)
09:58 <uma> how can I install edge/testing packages in v3.5? apk add php7@edge doesn't seem to work
09:59 <^7heo> In Germany it was even "worse" (all things relative)
09:59 <uma> either with or without 'http://dl-cdn.alpinelinux.org/alpine/edge/testing' in the /etc/apk/repositories file
09:59 <^7heo> TBB: The DST change happened EXACTLY the same day as a 15C temperature bump... =/
09:59 <uma> (I gather v3.5/testing does not exist)
09:59 <^7heo> uma: AFAIK testing is only a branch on edge.
10:00 <uma> problem is, I need packages php7* packages from edge/testing
10:00 <TBB> fortunately we're slowly starting to get to a point where countries seriously consider forgetting about the whole daylight saving concept
10:00 <^7heo> uma: how is that a problem?
10:00 <^7heo> TBB: yeah, I just hope they get sane
10:01 <TBB> fix your repo config, keep stable unpinned, pin the edge ones with @edge-main, @edge-community and @edge-testing or something along those lines
10:01 <^7heo> and don't chose the CET as a standard for the eastern countries.
10:01 <^7heo> TBB: I just pin @community and @testing myself
10:01 <uma> because most php7.0 packages are not in community repo
10:01 <^7heo> uma: no they are not. It's intended.
10:01 <uma> I need a way to select which packages I want from each repo
10:01 <^7heo> yes you will need to.
10:02 <^7heo> hence TBB's recommendation.
10:02 <TBB> uma: and that's when you use package@tag
10:02 <^7heo> seems like we need better docs
10:04 <uma> ^7heo no, I need to learn how to search
10:05 <uma> I was using apk's --help, now I found https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Repository_pinning
10:05 <uma> will try that
10:05 <^7heo> uma: that is the way to go yes.
10:05 <TBB> that's just the kind of thing I read of last weekend
10:05 <^7heo> uma: but I really believe we need better docs ;)
10:05 <TBB> it was called "extreme ownership", fascinating stuff
10:06 <^7heo> what is called "extreme ownership"?
10:06 Skele joined
10:07 <TBB> what uma just did there is that stuff, taking responsibility, he acknowledged he could improve his searches, did it and found a doc explaining how to solve his problem
10:07 <TBB> it's basically a term invented by this ex Navy Seal who now teaches corporate decision makers to *gulp* take responsibility
10:13 <uma> aaand it works
10:13 <uma> thanks for your help guys :)
10:14 <uma> on top of that from now I'll be able to stay on stable releases instead of edge. big win
10:16 <^7heo> well, that's the whole point of having the pinning system
10:16 <^7heo> otherwise you would add both repos unpinned
10:16 <^7heo> and that would also work...
10:16 <darkfader> uma: one thing to watch out for: if an package from edge you pinned is deleted you get confusing messages on the upgrade
10:16 <^7heo> ...but you would get the most recent packages of any
10:17 <^7heo> so mostly all the stuff from edge.
10:17 <darkfader> apk keeps you safe but last time it took me a bit to figure what's going on
10:17 <^7heo> (given that you have edge main and stable main)
10:17 <^7heo> darkfader: what do you mean exactly?
10:18 <uma> darkfader ty for the tip
10:21 <darkfader> ^7heo: i had pinned enhanceio from edge
10:21 <darkfader> and then the package was deleted
10:21 <darkfader> on the next apk upgrade apk said no (i dont remember the wording unfortunately)
10:24 <pickfire> kahiru: Void have C2
10:24 <pickfire> https://repo.voidlinux.eu/live/current/void-odroid-c2-musl-20170220.img.xz
10:24 <^7heo> darkfader: aaah I got it, when it is deleted on the repo, not on your host...
10:24 <^7heo> moin pickfire
10:27 cyborg-one joined
10:28 <pickfire> TemptorSent: Are you Chris?
10:28 <pickfire> ^7heo: moin
10:37 fekepp joined
10:49 <dunx> s/chris/christ
11:13 <kahiru> pickfire: yeah, I know...
11:16 urzds joined
11:16 <pickfire> kahiru: Tried it?
11:18 <kahiru> pickfire: I tried it on my laptop some time ago. It was all fine until I talked with the devs. since that I don't use it anymore
11:19 <pickfire> kahiru: Huh? The dev humialiated you?
11:21 <kahiru> I asked a dumb question and they were way too hostile to my liking
11:21 grayhemp joined
11:22 <pickfire> Oh
11:22 <pickfire> kahiru: Sorry to hear that. I didn't know they are hostile. You should try #suckless
11:23 <pickfire> One you see how they talk, you won't considered others hostile.
11:23 <pickfire> OFTC* - #suckless
11:23 <kahiru> dunno, maybe I was just having a bad day. And they as well. Who knows
11:24 <kahiru> heh, guess I'll give it a try sometime
11:25 <pickfire> kahiru: :D
11:27 <kahiru> always wanted to give sinit a try
11:28 urzds joined
11:30 <pickfire> kahiru: Nice, I wanted to do that as well, and runit on alpine.
11:30 <kahiru> and all that s6 stuff as well
11:30 <untoreh> I am trying to change file descripors limit but it does not get applied, any guide on how to configure pam on alpine?
11:30 <pickfire> s6?
11:31 <kahiru> the skarnet supervision suite
11:31 <kahiru> http://www.skarnet.org/software/s6/
11:31 <pickfire> untoreh: Not sure about that. /etc/security/limits.conf?
11:32 <untoreh> yes those do not get applied
11:34 <pickfire> suckless init is considered by many as the smallest possible init. I disagree: suckless init is incorrect, because it has no supervision capabilities, and thus, killing all processes but init can brick the machine. Nevertheless, suckless init, like many other suckless projects, is a neat exercise in minimalism.
11:34 <pickfire> untoreh: Then probably I have no idea, I hope others can help.
11:35 <pickfire> kahiru: ^
11:36 <pickfire> kahiru: Thanks a lot for quoting skarnet
11:41 terra joined
11:52 gho joined
11:53 <gho> hi, I'm trying to boot alpine on libvirtd but it just get stuck after starting busybox crond
11:55 <kahiru> gho: I recall hitting that some time ago
11:55 <kahiru> but I have no idea how I worked around it...
11:55 <gho> doh :)
11:58 <gho> also I noticed on setup-alpine, that if you choose dhcp then the same time udhcp starts is the password prompt, and it dhcp goes second it isnt obvious there's been a pw prompt and so you're left waiting
12:01 <kahiru> does it get unstuck after a while?
12:03 <gho> it seems to on the standard image but not on the virt image
12:03 <kahiru> maybe that was the workaround I used
12:04 <gho> still takes 3-4mins tho
12:04 <gho> tried removing quiet from cmdline but still non the wiser
12:04 <gho> dont know how to debug openrc
12:15 xs[m] joined
12:20 farosas joined
12:20 <kazblox> ncopa: you're here! :)
12:22 ahrs joined
12:23 <gho> kahiru, just got openrc logging going, appears to be ssh, does that jog your memory?
12:23 <kahiru> gho: could it be that the system has low entropy?
12:23 <kahiru> and maybe making something like haveged start before ssh could help
12:24 <gho> yeah I'm starting to think that but random starts before it stalls
12:25 blueness joined
12:26 <kahiru> dunno, maybe the virtualized hw doesn't provide enough randomness
12:26 <kahiru> does it even make sense?
12:27 <gho> yeah I agree with what youre saying I'm just trying to reconcile it with what I'm seeing
12:28 <gho> added haveged but it still stalls on ssh
12:28 <gho> cant understand why ssh would need randomness except on initial keygen
12:36 dminca joined
12:36 <dminca> hi guys
12:37 <gho> hi
12:39 <dminca> what's up?
12:40 StarWarsFan|afk joined
12:41 <gho> kahiru, it is ssh, disabling it fixes it and starting it on the console stalls
12:48 <gho> adding RNG in the config for the VM fixes it!
12:49 <kahiru> so the virt edition has to have some other means of getting the stuff it needs
12:50 <gho> yeah
12:50 <jomatv6> Same problem here, also on real hardware like the apu board... my solution is to start haveged before sshd is started
12:50 <gho> haveged didn't make any difference sadly
12:50 <gho> adding RNG device to libvirt config did
12:51 grayhemp joined
12:51 <gho> noticed in log that as soon as random pool initialised, ssh completed
12:52 <jomatv6> unfortunately haveged is started after sshd per default on alpine :-/
12:55 <ncopa> kazblox: no im not :)
12:57 <dminca> is there a "scala" package in alpine? I've looked through the packages but couldn't find any
13:03 <kazblox> lol
13:04 <asie> probably not
13:04 <kazblox> anyways
13:05 <kazblox> ncopa: about one of the packages you maintained... is xf86-video-mach64 and mesa-dri-mach64 still broken? They've both been left out of packaging since 2011 because building xf86-video-mach64 "broke"
13:06 gromero joined
13:08 <kazblox> I'm not sure if the situation applies now
13:20 rollniak_ joined
13:24 atmoz joined
13:43 white_knight joined
14:07 <untoreh> oh nothing is built with pam support in alpine that's why pam doesn't work :p
14:13 <kahiru> is there a reason for excluding pam?
14:14 <hiro> kahiru: pam is a complex piece of shit
14:14 <TBB> lightness would be a good reason
14:14 <kahiru> sadly can't argue with that
14:15 <TBB> and yeah, pam is complex, but it also enables lots and lots of nifty things
14:16 <hiro> i wouldn't want security-related software to do nifty things, i want it to be as light as possible.
14:17 <hiro> it's more common to have a software developer misunderstand one of the hundred usable APIs for checking a password or login permission than it is that anybody uses some advanced shit like two-factor trusted-computing-device login.
14:17 <TBB> good point, but on the other hand, you'll end up coding a lot of security features yourself by ignoring something like pam, which usually isn't a very good idea either
14:18 <TBB> damned if you do, damned if you don't kind of thing
14:18 <hiro> i don't feel damned at all :)
14:18 <hiro> you know how i unlock my computer at work?
14:18 <hiro> i don't input a password.
14:19 <TBB> yeh, but as the saying goes, those who don't understand security are doomed to reimplement it poorly
14:19 <hiro> one less ways for people to see me type my password
14:19 <hiro> the way i unlock my screen is `ssh work-computer killall slock`, which gets triggered when i plug in my laptop into my docking station :)
14:20 <hiro> i completely reimplemented all this shit manually
14:20 <hiro> and still my coworker's mechanism is poorer.
14:21 grayhemp joined
14:21 <hiro> because i can just snoop their password while they unlock their screen.
14:22 <^7heo> hiro: or you work in your own office
14:22 <^7heo> hiro: and nobody can see you type.
14:22 <hiro> ^7heo: you always close your window blinds? :)
14:22 <^7heo> if anyone can see my typing from THAT distance
14:22 <^7heo> they really deserve access.
14:23 <dminca> hiro: kahiru: pam is a complex piece of shit < lol good one
14:23 <hiro> secure systems have to be based on complex (elliptic key maths, private/public key distribution), but well abstracted universal interfaces.
14:23 <hiro> PAM is not universal
14:24 <hiro> elliptic keys are based on some simple verifiable mathematical properties
14:24 <hiro> this can simply be implemented wherever it needs to be used
14:24 <hiro> PAM is some linux shit, windows doesn't even care about it.
14:24 <hiro> but elliptic keys work just fine on windows.
14:25 <hiro> this is about being universal
14:25 <hiro> if something is not universal, you have to think if the complexity of it is worth it.
14:26 <hiro> in the case of PAM it clearly isn't, because practice shows more bugs are introduced for the common user than it can ever elevate the single user's security.
14:27 avih joined
14:27 <dminca> and PRNG's
14:27 <hiro> ^7heo: counterexample: let's say you use PAM, with password login and a cordless keyboard :)
14:27 <hiro> dminca: hmm?
14:28 <TBB> PAM is not just Linux tho. Not Windows, but definitely not just Linux.
14:29 <hiro> TBB: well, just look at stuff that is supposed to run on both linux and bsd
14:29 <hiro> TBB: it's all non-trivial
14:29 <dminca> randomness generated from a library programatically is not random at all, as it's generated from a seed
14:29 <^7heo> hiro: I dunno, some stuff is.
14:29 <^7heo> hiro: you can make some portable simple code that runs on POSIX.
14:29 <hiro> dminca: sure, that's basic knowledge related to crypto.
14:30 <hiro> dminca: but there's interfaces on most systems (sadly they differ quite often) that will get you comparable quality of randomness for crypto purposes.
14:32 stwa joined
14:32 <hiro> of course /dev/urandom for example should block if the seed comes from flash on an embedded device and there's no other entropy available yet (obviously manufacturers get this wrong sometimes)
14:32 <hiro> but this is all possible to provide comfortably.
14:33 <hiro> ^7heo: well, something simple like slock has non-linux specific code ini it.
14:33 <^7heo> hiro: I didn't check the slock code.
14:33 <^7heo> hiro: I should have.
14:33 <hiro> i keep on complaining on suckless about this shit
14:34 <hiro> obviously slock should have X11 dependencies
14:34 <hiro> restricting it to run only on systems with X11
14:34 <hiro> but then...
14:34 <hiro> #ifdef __linux__
14:34 <hiro> #include <fcntl.h>
14:34 <hiro> #include <linux/oom.h>
14:34 <hiro> you have to prevent getting killed...
14:35 <^7heo> ah
14:35 <hiro> then
14:35 <hiro> #if HAVE_SHADOW_H
14:35 <hiro> #else
14:35 <hiro> #ifdef __OpenBSD__
14:35 Metacity joined
14:35 <hiro> #endif /* __OpenBSD__ */
14:35 <hiro> #endif /* HAVE_SHADOW_H */
14:36 orbiter joined
14:36 <hiro> getspnam(pw->pw_name) vs. getpwuid_shadow(getuid())
14:36 <hiro> already this is too much for me
14:37 cyborg-one joined
14:37 <hiro> now with PAM this will just go to infinitely more retarded extend
14:40 <hiro> ah shit, above i didn't put the first version: getpwuid(getuid())
14:40 eripa joined
14:41 <hiro> see i got confused immediately when i saw those 3 functions needed by slock
14:41 <^7heo> hiro: basically, if you make the mouse disappear, it kills it
14:41 <^7heo> I think I submitted a patch for that a while ago
14:41 <hiro> ^7heo: that also?
14:41 <^7heo> yeah
14:41 <hiro> ^7heo: hmm, i complained about what happens when network disappears
14:41 <^7heo> I didn't try that yet
14:42 <hiro> ^7heo: then when you press enter and it tries to do some weird request via nscd it segfaults iirc
14:42 <hiro> but perhaps they changed this in the current code after some tard made a CVE about it
14:42 <pickfire> hiro: Hi
14:42 <hiro> pickfire: hey :)
14:42 <pickfire> hiro: Haven't seen you for quite some tim.
14:43 <hiro> pickfire: i keep on spamming the suckless mailing list :)
14:43 <pickfire> Ah
14:43 <pickfire> :D
14:43 <hiro> and sometimes i say something here or in musl or so, just for fun
14:43 <pickfire> oh
14:43 <hiro> today i drank too much cafe so i have to annoy *ALL CHANNELS*
14:43 <pickfire> Haha
14:44 <pickfire> hiro: How many channels do you have there?
14:44 <Chlorophytus> hi hiro
14:44 <hiro> pickfire: no idea, didn't automate it yet.
14:44 <pickfire> Haha, annoy all channels
14:44 <Chlorophytus> eheh
14:44 <hiro> Chlorophytus: guten.
14:45 <Chlorophytus> uuuhhhhh
14:45 <Chlorophytus> buenos dias :)
14:45 <hiro> hahaha http://git.suckless.org/slock/commit/?id=597469541c10fdb8920ed190b72763b0719e5cb5
14:45 <hiro> i didn't even GET to complain about this kind of stuff
14:46 <Chlorophytus> i feel like the only one on here using a single board x86 computer :d
14:46 <kahiru> heh
14:47 <pickfire> hiro: I wonder why suckless unboolify all the stuff.
14:47 <pickfire> Doesn't that reduce efficiency?
14:48 elkw joined
14:49 <hiro> i wonder why they ever put a bool in there in the first place
14:49 <hiro> this is not java goddamnit, lol.
14:50 <pickfire> Lol
14:50 <hiro> this is very lightweight problems still: http://git.suckless.org/slock/commit/?id=04143fd68dbc656905714eff5c208fadb3464e25
14:50 <^7heo> because every C teacher I've seen in the university goes like "It's easy to define a bool type in C, just: #define bool char"
14:50 <hiro> but then there's http://git.suckless.org/slock/commit/?id=d8bec0f6fdc8a246d78cb488a0068954b46fcb29
14:50 <^7heo> "and then you can #define false 0"
14:50 <^7heo> "and then you can #define true !false"
14:51 <pickfire> ^7heo: That's true
14:51 <hiro> :D
14:51 <^7heo> "and then you can just use bools!"
14:51 <^7heo> I mean...
14:51 <^7heo> yes it's true, you can do that.
14:51 <pickfire> 1 and 0 is way easier to type
14:51 <^7heo> but, it doesn't really help anything.
14:51 <^7heo> exactly.
14:51 <hiro> this line here was crazy:
14:51 <hiro> running = !!strcmp(crypt(passwd, pws), pws);
14:52 <pickfire> But sometimes I get blurred.
14:52 <hiro> the reason i use 0 and 1 is bec. that's how it works in C.
14:52 <pickfire> Between whether 1 or 0 is true.
14:52 <hiro> you have to know *anyway* in C.
14:52 <^7heo> hiro: that's to "cast" the return of strcmp
14:52 <hiro> like there can't be a programmer that doesn't know.
14:52 <pickfire> hiro: What about short?
14:53 <^7heo> hiro: actually it's not 0 and 1.
14:53 <^7heo> hiro: it's 0 and non-0
14:53 <hiro> ^7heo: exactly.
14:53 <^7heo> hiro: so yeah the !! is just wasted CPU time.
14:53 <^7heo> hiro: on the compilation step, hopefully.
14:53 <jvoisin> it's not
14:53 <^7heo> jvoisin: how?
14:54 <jvoisin> strcmp returns an int
14:54 <^7heo> jvoisin: and?
14:54 <jvoisin> it can be different from zdro or one
14:54 <^7heo> yes, and?
14:54 <jvoisin> inverting it twice will make sure that it's either zero or one
14:54 <^7heo> and?
14:54 <^7heo> actually, false
14:54 <^7heo> but and?
14:54 <* jvoisin> checks
14:54 <^7heo> (it's gonna be zero or non-zero)
14:54 <^7heo> check first, next time ;]
14:54 <pickfire> Haha, wasted
14:55 <hiro> ^7heo: i'm not talking about the !!
14:55 <hiro> ^7heo: the problem is that they didn't check for crypt error
14:55 <^7heo> hiro: /exec !!
14:55 <* ^7heo> hides
14:55 <^7heo> yeah true.
14:55 <hiro> ^7heo: the idea of running a function that's the main core of all your security setup, then not bothering to check the man page whether it can error...
14:55 <pickfire> hiro: They assumes there is no error.
14:56 <hiro> ^7heo: and after failing to check anything important, putting the strncmp in the same line
14:56 <^7heo> hiro: yeah, suckless.
14:56 <^7heo> hiro: less is more.
14:56 <* ^7heo> hides
14:56 <jvoisin> ^7heo: https://paste.debian.net/924605/
14:56 <hiro> now ADD NETOWRK PROTOCOLS to your password scheme
14:56 <^7heo> jvoisin: yeah, read the spec.
14:56 <hiro> and everything will go just perfectly, right?
14:56 <^7heo> jvoisin: anything !0 is valid as in an `if`
14:57 <^7heo> jvoisin: aside from that, the behavior of !! is unspecified AFAIK.
14:57 <jvoisin> so what?
14:57 <^7heo> so first, it's WASTE as I said.
14:57 <jvoisin> I don't think it's unspecified
14:57 <^7heo> it is.
14:57 <jvoisin> then we misunderstood each other
14:57 <^7heo> !0 can be anything.
14:57 <^7heo> not 1.
14:57 <jvoisin> I thought that you said that `!!` was useless in _any_ situation
14:57 <^7heo> if can be 0xFFFFFFFF on 32 bits for exmaple.
14:57 <^7heo> no I didn't.
14:58 <^7heo> but also, now, I will say that YES IT IS.
14:58 <jvoisin> hence why I said "I thought"
14:58 <hiro> the sucklesss people were incapable of making slock works in any secure way -> then you want to propose anybody will be able to know how to use PAM safely?
14:58 <^7heo> (in C, not in javascript)
14:58 <jvoisin> haha
14:58 <^7heo> because you can't assume that !0 will be 1.
14:58 <^7heo> not everybody uses THAT version of THAT compiler.
14:58 <jvoisin> https://kernelnewbies.org/FAQ/LikelyUnlikely
14:58 <hiro> ^7heo: what does gcc do?
14:59 <jvoisin> apparently, it's used by the kernel
14:59 <^7heo> hiro: it sets !0 to 1.
14:59 tg joined
14:59 <^7heo> hiro: which is a purely arbitrary implementation detail.
14:59 <hiro> this should be the main argument then :)
15:00 <^7heo> v_v
15:01 <jvoisin> ^7heo: The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0==E).
15:01 <jvoisin> § C99
15:01 <jvoisin> so, yeah, 0 or 1.
15:01 <pickfire> jvoisin: I mean if you want to print 1 or 0 then fine but if you do it on a if then WASTED
15:02 <jvoisin> I know
15:02 <^7heo> jvoisin: C99
15:02 <^7heo> again.
15:02 <^7heo> same problem.
15:02 <^7heo> version-specific detail.
15:02 <jvoisin> "^7heo > jvoisin: yeah, read the spec." ← then what spec shall I read?
15:02 <^7heo> ansi C
15:03 <pickfire> C11 haha
15:03 <pickfire> of course most read the ancient c89
15:04 <^7heo> yeah
15:06 <jvoisin> I fail to see why this couldn't be true for C89
15:07 <^7heo> because it's NOT specifide.
15:07 <^7heo> s/de/ed/
15:07 <^7heo> gosh you're thick.
15:09 <jvoisin> K&R, §A.7.2, The result of the logical negation operator ! is 1 if the value of its operand is 0, 0 if the value of its operand is non-zero.
15:10 <^7heo> Where?
15:10 <^7heo> (also K&R != ansi C)
15:11 <jvoisin> §A.7.2
15:11 <^7heo> The version of C described in this book is sometimes referred to as K&R C (after the book's authors), often to distinguish this early version from the later version of C standardized as ANSI C.
15:11 <^7heo> https://en.wikipedia.org/wiki/The_C_Programming_Language#History
15:11 <^7heo> I mean, yes, it's OFTEN 1.
15:11 <^7heo> but you can find compilers which return 0xFFFFFFFF. I've seen that.
15:12 <* ^7heo> looks in the direction of microchip
15:12 <^7heo> but that starts to be highly offtopic anyway
15:12 <jvoisin> yup, sorry for the noise
15:13 <^7heo> And long story short, you can just do an if
15:13 <^7heo> or a macro
15:13 <^7heo> instead of !!
15:13 <^7heo> and that'll ALWAYS be correct
15:13 <^7heo> like, a ternary operator... Done.
15:14 <^7heo> #define CAST_BOOL(x) (x)?1:0;
15:14 <^7heo> can't be more correc than that.
15:14 <^7heo> s/ec/&t/
15:15 <^7heo> also, the kernel has many more, and more problematic gcc dependencies, afaik.
15:16 <jvoisin> indeed
15:17 <jvoisin> pipacs managed to compile it with clang
15:20 <hiro> ^7heo: oh, you were mentioning exec
15:21 <hiro> ^7heo: that's another thing: why can't slock output a line of text to stdout when it has successfully locked the screen, so that a script running outside of slock might start whatever stupid programs it wants...
15:22 <hiro> but nope, they have to add stupid unneeded logic to parse the arguments :)
15:22 <hiro> which is completely unneededf
15:22 <hiro> the "post-lock" command
15:24 <hiro> ^7heo: XNextEvent will return 0?
15:25 <hiro> ^7heo: seems like they assume sometimes it doesn't return 0, but where is this even documented?
15:26 <^7heo> hiro: also it should monitor the attemps
15:26 <^7heo> hiro: instead of stupidly coloring the screen
15:26 <hiro> ^7heo: yeah, possibly.
15:27 <hiro> ^7heo: i actually have the colors completely removed
15:27 <hiro> my screen is simply black
15:27 <hiro> always.
15:27 <hiro> so nobody will even know wtf is up :D
15:28 <^7heo> yeah
15:51 volleyper joined
15:51 grayhemp joined
15:58 fekepp joined
15:59 dlaube joined
16:06 kazblox2 joined
16:22 grayhemp joined
16:22 <TemptorSent> skarnet: A couple questions on your comments. What happens if the set -e shell has an error during init, do we get a hung machine or a reboot?
16:24 <TemptorSent> skarnet: Can we be certain that the kernel hasn't mounted anything at the users request before we got to init? Being wrong could be disasterous if thee is a live FS mounted that we wipe.
16:26 <TemptorSent> skarnet: /dev/console is actually populated by a cpio archive embedded in the kernel. The devices in /dev could be bogus in the case of a bad append, and if malicious, could be used to breach crypto keys.
16:28 <TemptorSent> skarnet: Also, with the tmpfs mount, we have control over the mount-opts independently, which may be important for securing against undesired program execution from untrusted locations.
16:29 <TemptorSent> skarnet: devtmpfs has far more in it than we want or need early in the boot process, and again could represent a means of leaking in the right (wrong) hands.
16:30 <TemptorSent> skarnet: I'm looking at it from a paranoid POV and not taking anything for granted.
16:31 <TemptorSent> (simple example, /dev/null created with the dev numbers for the serial port -- I saw this done years ago!)
16:32 <TBB> I might be missing something here, but... who are you talking to?
16:36 t0mmy joined
16:37 atomi joined
16:45 grayhemp joined
16:55 atomi joined
17:00 atomi joined
17:17 czart_ joined
17:17 gopar joined
17:29 grayhemp_ joined
17:30 Shiz joined
17:31 grayhemp_ joined
17:34 atomi joined
17:36 sergey_ joined
17:46 atomi joined
17:48 fekepp joined
17:48 grayhemp joined
17:50 grayhemp joined
17:51 atomi joined
17:56 atomi joined
18:06 ahrs joined
18:07 terra joined
18:23 Guest51853 joined
18:23 <Guest51853> how do I install who and w ?
18:23 atomi joined
18:29 <_ikke_> Guest51853: I believe they won't work with musl (lacking wtmp et al)
18:29 TomJepp joined
18:29 <Guest51853> ta
18:32 gopar joined
18:44 gho_ joined
18:44 <gho_> when Ilook at the load average it says it is 1 but I'm hardly running anything, top doesnt say anything useful except the the cpu is 99% idle
18:45 Berra joined
19:00 gopar joined
19:41 Nobabs27 joined
19:43 blueness joined
19:49 mdillon joined
20:02 gopar joined
20:21 rrx joined
20:24 BitL0G1c joined
20:35 skee joined
20:35 skee joined
20:38 <ekarlso> is there no wiringpi.h in archlinux?
20:44 blueness joined
20:57 blueness joined
21:07 stwa joined
21:23 atomi joined
21:25 atomi joined
21:30 grayhemp joined
21:42 lesion joined
21:57 alskdfjalskdfj joined
21:57 <alskdfjalskdfj> I am having weird issues with Alpine
21:57 <alskdfjalskdfj> at first, while trying newer version, it was possible to start X, but the classic linux console or anything framebuffer based was invisible (possible to type there but nothing seen at all)
21:58 alacerda joined
21:59 <alskdfjalskdfj> now it's the opposite (with older kernel/init/mods), the console is visible, and even X was working, but out of nowhere startx shows the cursor, but after a second it blacks out and freezes (unable to do anything)
21:59 <kaniini> what version
22:00 <alskdfjalskdfj> not sure now
22:00 <kaniini> :/
22:00 <alskdfjalskdfj> but what it could be
22:00 <nsz> i had the first issue, it was simply a change of deps in the modules that are loaded in the initramfs
22:00 <alskdfjalskdfj> nsz: what deps
22:00 <nsz> so if you customized the init stript and then updated the kernel then you did not get the fb set up right
22:00 <alskdfjalskdfj> nsz: .. were missing so the framebuffer wasn't visible really
22:01 <alskdfjalskdfj> nsz: that could be it
22:01 <alskdfjalskdfj> nsz: customized init scripts
22:01 <alskdfjalskdfj> nsz: wouldn't think the fbdev would be anyhow handled there
22:02 <nsz> ah it was kms
22:02 <nsz> the kernel mode switch module
22:02 <nsz> /etc/mkinitfs/mkinitfs.conf
22:02 <nsz> see if you have an *.apk-new of that file
22:02 <alskdfjalskdfj> nothing with /etc/init.d folder?
22:03 grayhemp_ joined
22:05 <alskdfjalskdfj> nsz: quite not understanding it. If it is something with the deps in the modules in initramfs, and I have changed only the init.d scripts, then it must be someting with that (if the console should be visible on boot, as I assume it should). So the kms in /etc/mkinitfs/.. is called from init.d folder?
22:05 <kaniini> if you do not have kms enabled in initramfs, enabling it might help
22:05 <alskdfjalskdfj> nsz: thanks for pointing on it and reacting
22:07 <nsz> mkinitfs builds the initramfs that executes before init.d stuff
22:08 <alskdfjalskdfj> thought it's already build by default in the release, not being built on the fly anytime
22:08 <alskdfjalskdfj> so I should enable kms, isn't it possible even via boot arguments?
22:09 <nsz> it is in /boot
22:09 <nsz> and you can rebuild it
22:09 <alskdfjalskdfj> that's great
22:10 <alskdfjalskdfj> I wonder why the console works in older version of Alpine, yet doesn't now. Is it now mandatory to enable kms or is it device-based issue? (gpu)
22:10 <nsz> i think /usr/share/mkinitfs/initramfs-init is the script that runs by default
22:11 <nsz> and you can parametrize it by the conf file
22:11 <nsz> you might get similar effect by passing some boot params to the kernel
22:11 <nsz> but i dont know the details
22:12 <nsz> for me updating mkinitfs and reruning mkinitfs solved the problem
22:12 <nsz> you might have a different issue though
22:13 <alskdfjalskdfj> maybe. as I am using the initramfs from the new version as well (new version: kernel, modloop, initramfs ..). But it could be a lot of things. Thanks for all the input.
22:15 grayhemp joined
22:19 ammunta joined
22:20 blueness joined
22:21 ammunta joined
22:25 ammunta joined
22:27 grayhemp joined
22:28 mdillon joined
22:33 terra joined
22:34 dirac1 joined
22:43 cyborg-one joined
22:43 grayhemp joined
22:46 grayhemp joined
23:14 cyborg-one joined
23:32 cyborg-one joined
23:34 gopar joined
23:52 blueness joined