<    April 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
00:03 <kaniini> TemptorSent: let me know if theres any more discrepancy
00:08 <kaniini> with that fixed, i think it is safe to dump linux-grsec transitional package and use provides again
00:11 saintdev joined
00:12 gromero joined
00:15 ephemer0l joined
00:15 ephemer0l joined
00:22 <TemptorSent> kaniini: Give it a shot -- what's the WORST that could happen? ;)
00:22 <Shiz> finally identified my Scaleway ARM CPU
00:24 <Shiz> ThunderX T88 dualcore
00:24 <Shiz> ARMv8.1-A
00:32 czart__ joined
00:53 <jirutka> Shiz: are you testing my attention? :) https://txt.shiz.me/MzljMDRjMz#l-152
00:54 <Shiz> ?
00:54 <Shiz> ah
00:54 <Shiz> no, i just thought it looked better the other way around
00:54 <Shiz> :P
00:54 <jirutka> why you’ve switched order in this conditon? o.O
00:54 <Shiz> as in (check_need || check_special_condition)
00:54 <Shiz> as opposed to the other way it was before
00:54 <jirutka> actually it was theoretically more performant before
00:54 arch3y_ joined
00:55 <jirutka> var check vs. func call
00:55 <Shiz> and i needed to redo that patch anyway
00:55 <Shiz> well, performant for something being called a single time in creating the final executable?
00:55 <jirutka> ?
00:55 <Shiz> :P
00:55 <Shiz> feel free to change it back though if you wanna
00:55 <Shiz> i mean, it'd be a function called a single time in the entire process
00:55 <jirutka> I know, it doesn’t make sense, just arguing that the previous variant was slightly better :P
00:56 <jirutka> this https://txt.shiz.me/MzljMDRjMz#l-117 used to be in a separate patch, didn’t it?
00:59 <Shiz> uhm, if it was, it was before the patch reorganisation
00:59 <Shiz> it makes more sense in the 'fix static linking patch' since it's needed for that
00:59 <Shiz> :P
00:59 <Shiz> this patch just addds those features for anewly added linker impl they added in 1.17.0
00:59 <Shiz> (EmLinker, can you guess what for?)
01:00 <jirutka> but then it have to be removed from the original patch, haven’t it?
01:00 <jirutka> Emscripten?
01:00 <Shiz> yeah
01:00 <Shiz> jirutka: no?
01:01 <Shiz> between 1.16.0 and 1.17.0 a new linker impl was added in Rust
01:01 <Shiz> this addition just implements these 3 functions for that new linker
01:01 <Shiz> as these 3 functions are added by our patches
01:01 <jirutka> eh, aha, i see now
01:02 arch3y_ joined
01:02 <jirutka> okay, merged, thanks a lot! :)
01:02 <jirutka> and i go sleep now
01:02 <Shiz> \o/
01:02 <algitbot> \o/
01:03 <Shiz> good night :)
01:04 <jirutka> hm, build-3-6-* builders are fucked up, they still have unpatched libressl
01:06 s33se joined
01:15 arch3y_ joined
01:47 arch3y_ joined
02:19 gromero joined
02:34 rdutra1 joined
02:44 blueness joined
02:49 arch3y_ joined
03:28 ifbizo joined
03:42 <kaniini> TemptorSent: do i go for it? do i kill the linux-grsec transitional package now that i fixed apk itself??
03:44 <TemptorSent> kaniini: Might as well... After all, it can't break any worse, right?
03:44 <kaniini> TemptorSent: it should be fine i think
03:46 <TemptorSent> 'should' and 'I think' in the same sentence... what could possibly go wrong? :P
03:47 <Shiz> at least apk always upgrades itself first :)
03:51 <kaniini> TemptorSent: https://git.alpinelinux.org/cgit/aports/commit/?id=1e735e4a
03:53 <TemptorSent> *LOL* Oh, that's an awesome commit message!
03:54 <awilfox> that's pretty impressive indeed lol
03:54 <Shiz> do all the previous -grsec modules also provide their -hardened variants now?
03:54 <Shiz> err, other way around but you get what i mean
03:55 <kaniini> Shiz: yes
03:55 <kaniini> Shiz: they always did
03:55 <Shiz> ocool
03:55 <kaniini> Shiz: i just put linux-grsec in as a temporary workaround while i debugged apk
03:55 <kaniini> because SAT solvers are not things meant to be debugged at 03:45am
03:56 <Shiz> :P
03:56 <TemptorSent> Damn good work nailing it down in the first place.
04:00 <TemptorSent> We really need to do somethign about the kernel building system -- it shouldn't take that many changes to bump a kernel version
04:03 <kaniini> :D
04:03 <kaniini> REMEMBER THAT TIME I BROKE THE ENTIRE DISTRO OH WAIT IT WAS LAST NIGHT
04:04 <TemptorSent> *lol*
04:06 <kaniini> hopefully renaming the package will have a positive impact such as
04:06 <kaniini> making the "grsec is 100% of alpine's security" crowd fuck off
04:06 <kaniini> that would be pretty cool
04:06 <TemptorSent> Agreed.
04:06 <TemptorSent> Maybe we can do some actual hardening.
04:06 <kaniini> because they are quite annoying
04:06 <kaniini> oh, grsec is great for what it is
04:06 <kaniini> it's just that
04:07 <kaniini> there's a lot more going on than just grsec re: security in alpine, and if you don't want to run grsec it doesn't really change your security exposure that much
04:07 <TemptorSent> But simple stuff like canary checks and syscall auditing have more day-to-day impact against the classes of exploits we're likely to see.
04:07 <kaniini> right, which is why we do all of that too
04:07 arch3y_ joined
04:08 <TemptorSent> Replace the missing roof before you worry about the open window.
04:09 <kaniini> right
04:09 <kaniini> way i put it is
04:10 <kaniini> grsecurity is like having a 12 gauge vs having a 20 gauge shotgun to protect your house
04:10 <kaniini> 12 gauge is a little better
04:10 <kaniini> but both are good
04:10 <kaniini> it's sometimes nice to have the additional kernel security hardening that grsecurity provides
04:10 <TemptorSent> And in in both cases, the ammo is more of a consideration than the bore.
04:11 <kaniini> exactly
04:11 <kaniini> point is
04:11 <kaniini> it's just one of many variables
04:11 <Shiz> fwiw
04:11 <Shiz> seems like the gentoo hardened folks are setting up a hardened kernel project
04:11 <TemptorSent> I found bits and pieces of grsec useful, but not so much overall.
04:11 <Shiz> https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project
04:11 <pickfire_> T_T
04:11 <TemptorSent> They've had a hardened kernel for ages.
04:12 <Shiz> (also im still not asleep)
04:12 <Shiz> TemptorSent: please read the actual page.
04:12 <pickfire_> Latest alpine update turn my laptop into a brick.
04:12 <Shiz> they had hardened-sources for years
04:12 <Shiz> not the same
04:12 pickfire joined
04:12 <pickfire> T_T
04:12 <pickfire> The change of `vmlinux-linux`
04:13 <pickfire> Into `vmlinuz-hardened` T_T
04:13 <pickfire> Need to flash coreboot again and fix that.
04:13 <Shiz> lol
04:13 <TemptorSent> Okay, looks like they're turning it into a larger community project, cool.
04:15 arch3y_ joined
04:16 <TemptorSent> BTW - are we tracking their hardened-musl project?
04:16 <Shiz> it's not very interesting to us
04:16 <Shiz> they do nothing we don't, afaik
04:16 <kaniini> Shiz: why do you think we moved to just -hardened? :)
04:16 <Shiz> kaniini: because i suggested the name to ncopa
04:16 <Shiz> i'm just saying a project actually exists now
04:16 <Shiz> :P
04:17 <kaniini> Shiz: anyway, we might collaborate with them, but we are watching first to see if they actually bring something to table
04:17 <Shiz> sounds fair
04:17 <Shiz> i talked to strcat in #pax today about such a project
04:17 <Shiz> and he seemed interested in it as well, as long as he didn't have to do x86_64 work
04:17 <kaniini> before or after he was banned
04:17 <Shiz> :P
04:17 <kaniini> ;)
04:17 <Shiz> that was #grsecurity
04:17 <Shiz> ;p
04:17 <Shiz> #pax has no ops
04:18 <Shiz> but it's nice since uhm
04:18 <Shiz> strcat is at least competent
04:20 <TemptorSent> The patchsets in gentools proj/musl.git look potentially useful for reference.
04:21 <TemptorSent> They may save some people time porting.
04:22 <Shiz> i ran gentoo musl befor
04:22 <Shiz> eit's not nearly as advanced as alpine
04:22 <Shiz> things would break every 3 packages
04:22 <TemptorSent> Yeah, just noticing some recent patches for things such as libvirt that may be of interest.
04:22 <awilfox> it's also run by two people
04:22 <Shiz> but yeah, they may have patches for packages we don't carry yet, same with void etc
04:22 <awilfox> and I'm one of the two
04:22 <awilfox> and I haven't written open source code in six months
04:22 <awilfox> so there's that too
04:23 <Shiz> :p
04:23 <awilfox> they have a patch to boehm-gc that fixes a correctness issue on musl/x86_64 that doesn't exist on any other arch but is bad enough to make w3m broken if you don't apply it; I don't think alpine packages either boehm-gc nor w3m (when I looked anyway) so it isn't relevant but
04:24 <awilfox> yes they do have patches for things alpine doesn't
04:24 <awilfox> alpine also has a much more comprehensive gcc patchset
04:24 <TemptorSent> And some interesting workarounds for nss...
04:24 <awilfox> void took the kde packages from ad�lie too
04:24 <Shiz> nss shouldn't be worked out
04:24 <Shiz> it should be excluded
04:24 <Shiz> :P
04:24 <Shiz> awilfox: your encoding's broken
04:24 <awilfox> nss is much better than openssl
04:24 <awilfox> it's a shame less things use it
04:24 <TemptorSent> no, other nss :)
04:25 <awilfox> oh
04:25 <awilfox> that
04:25 <TemptorSent> name service switch
04:25 <Shiz> the only thing i remember from NSS the security library is that it didn't support DH keys >1024 or so bits a couple of years back
04:25 <Shiz> because "DoS reasons" lol
04:25 <Shiz> both should be eradicated
04:25 <kaniini> anyway, i don't care about grsecurity itself
04:25 <kaniini> my problem is the grsec fanboys who show up
04:26 <kaniini> they are unpleasant
04:26 <Shiz> well, i'm a grsec fanboy
04:26 <kaniini> they make ircd fanboys look tolerable
04:26 <Shiz> am i that unpleasant
04:26 <kaniini> Shiz: i mean the "grsec is 100% of alpine's security story" crowd
04:26 <Shiz> :P
04:26 <Shiz> i'll admit it's a big reason why i picked alpine back when i did
04:26 <awilfox> bahamut master race
04:26 <kaniini> if you've sat on #alpine-linux you know exactly what i am talking about
04:26 <Shiz> and now i run my own kernels always anyway
04:27 <kaniini> there's nothing wrong with carrying grsecurity patch as an option
04:27 <kaniini> i do consider it a way that alpine does provide more choices than most distributions
04:27 <kaniini> but it doesn't mean grsec is the only aspect of our security plans either
04:28 <kaniini> that's the part i don't like about the grsec fanboy crowd that shows up on #alpine-linux
04:28 <TemptorSent> I'd be happy with a couple of PaX features and the gcc plugins out of it.
04:28 <kaniini> it's just so ignorant
04:28 <Shiz> anyway
04:28 <TemptorSent> The rest was take it or leave it IMHO, and not terribly portable.
04:28 <Shiz> low-level protections are inherently unportable
04:28 <kaniini> so i am happy that we call it -hardened now
04:28 <Shiz> that's how it works
04:29 <Shiz> imo it should've been -hardened in the first place
04:29 <Shiz> anyway
04:29 <TemptorSent> Yeah, unportable in ways they don't need to be.
04:29 lucybun joined
04:29 <Shiz> if a viable/competent hardening project shows up, i think it'd be nice if we could contribute to it
04:29 <Shiz> i'd be willing to invest work in it
04:29 <kaniini> Shiz: i just find it irritating that people show up and have that attitude re: grsec, given that we have done a lot of work outside of grsec to build a hardened distribution that people can actually use
04:30 <kaniini> and yes
04:30 <kaniini> i agree 100%
04:30 <kaniini> we should continue to innovate with the kernel instead of duplicate
04:30 <TemptorSent> Agreed.
04:31 <TemptorSent> so kaniini, now that you broke all of Alpine, any thoughts on manifesting?
04:31 <TemptorSent> ;)
04:32 <TemptorSent> Hmm, no kernel upgrade with apk upgrade...
04:32 <kaniini> TemptorSent: x86_64 hasn't landed yet
04:32 <kaniini> TemptorSent: presently building zfs-hardened: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/zfs-hardened/zfs-hardened-4.9.24-r3.log
04:32 <TemptorSent> Ahh, okay -- apk-tools has, which makes me smile.
04:33 <kaniini> TemptorSent: http://build.alpinelinux.org/
04:34 <TemptorSent> 57% on ZFS.
04:34 <Shiz> 3.6 builders are building again
04:34 <Shiz> yay
04:35 <TemptorSent> theoretically, spl is done then.
04:35 <Shiz> TemptorSent: that's 57% of the packages in queue
04:35 <Shiz> :P
04:35 <TemptorSent> Right,
04:35 <TemptorSent> Meaning as soon as zfs is done, everything I need should be built.
04:36 <TemptorSent> Packaging...
04:36 <Shiz> and it is done
04:36 <Shiz> but packages only get uploaded at the end of the run
04:36 <Shiz> afaik
04:37 <TemptorSent> Looks that way.
04:37 <TemptorSent> Almost ther.
04:37 <TemptorSent> Bing!
04:38 <TemptorSent> Should show up from -commits in a sec
04:38 <TemptorSent> Well shit, no kernel.
04:38 <kaniini> what mirror ?
04:38 <kaniini> rsync :P
04:39 <TemptorSent> yep, rsync
04:39 <TemptorSent> It installed spl and zfs, but I have a bricked system again :(
04:40 <TemptorSent> Something is still very wrong
04:40 <kaniini> with --available ?
04:40 <TemptorSent> Yes.
04:41 <TemptorSent> I can see it with policy, but it's not even trying.
04:41 <kaniini> let me test clean upgrade
04:42 <TemptorSent> So I now have spl and zfs at 4.9.24-r3, but my kernel is stuck at 4.9.24-r2
04:44 <kaniini> clean upgrade i get
04:44 <kaniini> (24/29) Installing linux-hardened (4.9.24-r3)
04:44 <kaniini> (25/29) Purging zfs-grsec (4.4.59-r0)
04:44 <kaniini> (26/29) Purging spl-grsec (4.4.59-r0)
04:44 <kaniini> (27/29) Installing spl-hardened (4.9.24-r3)
04:44 <kaniini> (28/29) Installing zfs-hardened (4.9.24-r3)
04:44 <TemptorSent> what happened to the kernel there?
04:44 <kaniini> linux-grsec was purged
04:44 <kaniini> sec, pastebinning entire install log
04:44 <TemptorSent> Right, I'm already on hardened.
04:45 <TemptorSent> It's failing to update from hardened to hardened.
04:45 <TemptorSent> I have hardened in my world.
04:45 <kaniini> http://sprunge.us/PVKE
04:45 <TemptorSent> Something is fubar somewhere.
04:46 <kaniini> /etc/apk/world ?
04:47 <TemptorSent> Oh, FFS -- something somehow pinned 'linux-grsec=4.9.20-r0' in my world file, and I didn't do it.
04:47 <kaniini> :D
04:47 <Shiz> :P
04:47 <Shiz> inb4 there was never a bug at all
04:47 <kaniini> Shiz: there was a bug in APK
04:47 <Shiz> i kid, i kid
04:48 <kaniini> but i'm pretty sure that is 100% fixed now :)
04:48 <TemptorSent> I think it was one of the updates that did that, as I didn't have it in there before this mess started, and that's my currently running kernel.
04:49 <kaniini> :D :D :D :D :D :D :D :D :D :D :D
04:49 <TemptorSent> Because I was getting the same behavior in a fresh apkroot as well
04:50 <kaniini> updates don't edit /etc/apk/world
04:50 <kaniini> lol
04:50 <TemptorSent> Then how exactly would that get there?
04:50 <kaniini> IDK
04:50 <kaniini> but /etc/apk/world is user selections only
04:51 <TemptorSent> That's nice, but I never tagged it.
04:51 <kaniini> apk itself will never write to it unless a mutation is requested
04:51 <kaniini> so, i dunno
04:51 <kaniini> well
04:51 <kaniini> wait
04:51 <kaniini> wait
04:51 <kaniini> wait
04:51 <kaniini> i know
04:51 <kaniini> it might be from messing with
04:51 <kaniini> apk add --virtual .mkinitfs-dep linux-grsec=4.9.20-r0
04:52 <kaniini> i told you about that
04:52 <kaniini> and then made it possible to fetch on a virtual
04:52 <kaniini> so it might be from that
04:52 <TemptorSent> Yeah, but I never executed that in my apkroot
04:52 <kaniini> dunno then
04:52 <kaniini> that's all i got
04:52 <TemptorSent> Unless it breaks with an alternate root in a weird way...
04:53 <TemptorSent> Wait, how about the virtual package for the transitional package? What was that dep?
04:53 <kaniini> linux-hardened>=4.9.21-r1
04:53 <kaniini> but
04:53 <kaniini> if you have linux-grsec=4.9.20-r0 pinned
04:53 <kaniini> you wouldnt have gotten it
04:53 <kaniini> :p
04:53 <TemptorSent> Because here's the weird thing -- the LAST time I did the upgrade it upgraded the kernel!
04:54 <TemptorSent> Yeah, so why was I getting modules every time and the kernel occasionally?
04:54 <TemptorSent> And I had explicitly removed linux-grsec from my world file to get it to fetch hardened in the first place!
04:54 <TemptorSent> Somethign is still fishy.
04:55 <TemptorSent> Modules shouldn't be upgrading to a different version than the kernel, no matter what.
04:55 <TemptorSent> That is broken resolving.
04:56 <TemptorSent> Yeah, if that was pinned, I also wouldn't have had the rest of the symptoms... somethign is very weird.
04:56 <kaniini> (1/4) Purging linux-grsec (4.9.24-r1)
04:56 <kaniini> (2/4) Upgrading linux-hardened (4.9.24-r2 -> 4.9.24-r3)
04:56 <kaniini> (3/4) Upgrading spl-hardened (4.9.24-r2 -> 4.9.24-r3)
04:56 <kaniini> (4/4) Upgrading zfs-hardened (4.9.24-r2 -> 4.9.24-r3)
04:57 <kaniini> humm, it upgraded all the modules for me just now outside the apkroot
04:57 <TemptorSent> Yeah, but why would it upgrade the modules but NOT the kernel in ANY case?
04:57 <kaniini> it shouldn't,
04:57 <TemptorSent> That shouldn't happen -- if it's pinned at an earlier version, it should either get those modules or fail.
04:58 <TemptorSent> Try pinning your kernel, then retrying that...
04:58 <kaniini> raccoon:~/aports$ sudo apk --root ~/apkupgrade/ info spl-hardened --depends
04:58 <kaniini> spl-hardened-4.9.24-r3 depends on:
04:58 <kaniini> hmmmm
04:59 <kaniini> looks like you may be onto something here, these kernel module packages are missing dependency on linux-hardened
04:59 <TemptorSent> Yeah, that's starting to make sense.
04:59 <kaniini> i wonder when /that/ broke
04:59 <TemptorSent> A long time ago, because it was broken on -grsec before any of this.
05:00 <kaniini> sigh, i don't want to do *another* rebuild
05:00 <Shiz> lol
05:00 <TemptorSent> I'm sorry -- I just seem to be good at turning up corner cases for some reason.
05:00 <kaniini> depends=""
05:00 <kaniini> indeed...
05:00 <kaniini> this is definitely wrong
05:01 <kaniini> should be depends=linux-hardened=${_kpkgver}
05:01 <TemptorSent> Agreed.
05:01 <kaniini> lets see if -vanilla modules are fucked too
05:01 <kaniini> i predict yes
05:01 <kaniini> depends=""
05:01 <kaniini> depends_dev="linux-vanilla-dev=$_kernelver"
05:01 <kaniini> and what do you know
05:02 <TemptorSent> Likely, yes -- this whole thing of having the flavor for the package name fubars it.
05:02 <kaniini> i was right
05:02 <kaniini> yes but it is too close to release to just completely overhaul the packaging imo
05:02 <TemptorSent> Fixing the package naming will largely eliminate that, since we can just dep on the proper package.
05:02 <kaniini> ON THE OTHER HAND
05:02 <kaniini> KIND OF GOOD WE FOUND THAT BUG LOL
05:03 <TemptorSent> Yeah, that might be a problem for a few people when upgrade time comes :)
05:03 <kaniini> okay
05:03 <kaniini> so basically
05:03 <kaniini> all the APKBUILDs need to be fixed
05:03 <kaniini> to reference linux-hardened=${_kpkgver} or similar
05:03 <TemptorSent> It looks that way.
05:04 <kaniini> who wants to take that one on
05:04 <TemptorSent> A single abuild for each that references linux-$_flavor=$_kpkgver would be ideal.
05:04 <kaniini> its simple work, just tedious and annoying
05:04 <TemptorSent> sed -i ?
05:04 <kaniini> TemptorSent: cant, not all the APKBUILDs use the same variable names ;/
05:04 <TemptorSent> Oh, FFS.
05:05 <kaniini> h/o
05:05 <kaniini> i am git blaming this
05:05 <Shiz> i'll do it
05:05 <Shiz> when i wake up again
05:05 <TemptorSent> Can we fix the variable names at least so they're consistent across all the kernel builds?
05:05 <kaniini> :D
05:05 <TemptorSent> So we can update such things in the future without so much pain.
05:07 <kaniini> well
05:07 <kaniini> git blame
05:07 <kaniini> was inconclusive
05:07 <kaniini> wait
05:07 <kaniini> 3.5 is probably fucked too
05:07 <kaniini> to 3.5!
05:07 <TemptorSent> In other words, it's been broken for ever?
05:07 <TemptorSent> Awesome!
05:08 <TemptorSent> And somehow I just now turned up with actual breakage? How the hell did people get that lucky, that long?
05:08 <kaniini> ohhhhh
05:08 <kaniini> clandmeter!!!!
05:08 <kaniini> TemptorSent: good news!
05:08 <kaniini> TemptorSent: seems it's just zfs
05:09 <awilfox> .oO{ is it bad I am kind of hoping `git blame` turns up like alpine 1.1 because that would just be the most hilarious kind of schrodinbug }
05:09 <TemptorSent> Oh!
05:09 <TemptorSent> Sounds like it might have been there as long as zfs anyway ;)
05:10 <kaniini> TemptorSent: working on it
05:10 <kaniini> TemptorSent: and yes!!!
05:10 <TemptorSent> Woohoo!
05:12 <TemptorSent> Wait, the APKBUILD looks more broken than that...
05:12 <TemptorSent> the kernel release string might be broken...
05:13 <TemptorSent> Yep, vanilla kernels don't always have the -0 for the release string, so the vanilla modules need a check I think.
05:14 <TemptorSent> That needs to be fixed, because having 4.9.24-0 in one place and 4.9.24 in another breaks things.
05:15 tmh1999 joined
05:16 <TemptorSent> kaniini: also, the install-if in zfs-hardened appears wrong.
05:17 <TemptorSent> it references -grsec still
05:17 <kaniini> it will work, but good catch
05:19 <TemptorSent> The vanilla abiversion mismatch won't work though I suspect.
05:19 <kaniini> TemptorSent: vanilla kernels need same
05:22 <TemptorSent> Hmm, I wonder if that will randomly fix the s390x build?
05:22 <kaniini> nope
05:22 <kaniini> s390x fucked
05:22 <TemptorSent> How do I tell algitbot to retry?
05:22 <kaniini> for other reasons
05:23 <TemptorSent> Looks like spl has version missmatch.
05:24 <kaniini> nope
05:24 <kaniini> s390x kernel config is missing stuff
05:24 <kaniini> needed by spl
05:24 <kaniini> is why its broken there
05:25 <TemptorSent> Ahh, lack of kmem accounting.
05:25 <TemptorSent> And possibly other issues...
05:26 <TemptorSent> Are detailed build results available anywhere?
05:26 <TemptorSent> (config.status, config.cache, etc?)
05:26 <kaniini> just deploy an IBM LinuxOne(R) instance and rebuild it
05:26 <kaniini> duhhhhh
05:27 <TemptorSent> Yeah - have one I haven't played with yet.
05:27 <TemptorSent> Expires soon :)
05:27 <kaniini> hop to it
05:28 <kaniini> well
05:28 <kaniini> that should solve that
05:28 <TemptorSent> Yeah, expires in two days, might be worht extending it first :)
05:31 <minimalism> I heard there was some word in here earlier about the grsec matter
05:32 <kaniini> minimalism: yes!!!
05:32 <kaniini> minimalism: we are going to send ISIL to spender's house!!!
05:32 <kaniini> minimalism: who will, *ahem* "convince" him to change his mind!!!
05:32 <minimalism> I'm mainly a gentoo user, but it seems everyone concerned about it is busy having internal strife over it
05:32 <kaniini> not us!
05:32 <minimalism> so it seems
05:32 <kaniini> we're pretty much chill about the whole thing
05:32 <kaniini> spender's gonna spend, etc
05:32 <minimalism> You said you were willing to collaborate with other distros, right?
05:33 <kaniini> sure if they actually bring something to the table
05:33 <kaniini> otherwise we'll just do our own thing, it's cool
05:33 <minimalism> well, this is what's generally being argued in other channels
05:33 <minimalism> a) we can't live without grsec, let's pay the piper
05:33 <minimalism> b) it will take too long to develop a community alternative
05:33 <kaniini> we can definitely live without grsec
05:33 <kaniini> it's all good
05:33 <minimalism> c) let's build our own
05:34 <kaniini> and i care why ?
05:34 <kaniini> i wasn't aware the woes of gentoo users were alpine's problem
05:34 <TemptorSent> c is probably the only way it's worth going, possibly in coordination with other groups.
05:34 <minimalism> Not saying they are
05:35 <kaniini> maybe you can solve it with USE flags and CFLAGS strings at least 1KB long
05:35 <minimalism> just saying everyone's being kind of difficult about it in favor of their own solution that might not be as good as a real community effort
05:35 <kaniini> minimalism: it doesn't really bug us either way
05:35 <kaniini> minimalism: we've basically been running a grsec *fork* for 2 years anyway
05:35 <TemptorSent> Long term, we want some kernel security improvements, but grsec isn't the end-all-be-all-at-all :)
05:36 <kaniini> we're just gonna keep doing what we do maaaaaaaan
05:36 <kaniini> if some peeps bring something concrete to the table we might come play
05:36 <kaniini> if they dont, we wont
05:36 <kaniini> it's all good either way
05:36 <minimalism> is this table a non-distro table?
05:36 <kaniini> could be
05:36 <kaniini> any table is good
05:37 <kaniini> distro/non-distro/whatever
05:38 fabled joined
05:38 <TemptorSent> It would generally be preferable to have it non-disto-centric for maintainability.
05:38 <kaniini> minimalism: basically end of the day we want to see commitment before we come play
05:38 <kaniini> is really it
05:39 <kaniini> because we know that doing security at distro scale is hard
05:39 <kaniini> and we know that doing kernel security at distro scale is even harder, because we already do it!
05:39 <kaniini> so, need to see proof that something is concrete before we commit to anything
05:39 <kaniini> is basically the bottom line
05:39 <kaniini> if nothing surfaces, no harm no foul, it's all gooooood
05:40 <Shiz> are you on those dank leaves again
05:40 <* awilfox> checks room name
05:40 <TemptorSent> In the mean time, cherry pick the good, maintainable code and keep it rebased, and find solutions for anything really critical.
05:40 <awilfox> Shiz: no, this is #alpine not #atheme, I doubt he is
05:40 <TemptorSent> This is Alpine, we're supposed to be high.
05:41 <Shiz> boo
05:41 <kaniini> what TemptorSent said obviously!
05:41 <kaniini> minimalism: but in all seriousness, like i said, we will come play if someone produces something that is interesting to us that we feel isn't a waste of our resources
05:42 <TemptorSent> The KSPP works looks interesting, but there's another set of politics and some technical problems there too.
05:42 <kaniini> minimalism: we generally think that having multiple stakeholders for a grsecurity replacement is a good thing, but again, if it doesn't happen we have other options
05:43 <kaniini> minimalism: we have been planning for this eventuality for the past 2 years
05:43 <Shiz> KSPP has a few issues, most of them being that upstreaming is hard and their work has lead ot incomplete/lacking replacements supposedly
05:43 <kaniini> Shiz: arguably any replacement that does not generate revenue for spender is lacking though!
05:43 <TemptorSent> Yeah, good, upstreamable solutions should be top priority.
05:43 <kaniini> gotta keep that one in mind :)
05:44 <TemptorSent> Meaning wherever possible, surgical and easily tested, or linus will send it to the bit bucket.
05:45 <kaniini> minimalism: in fact, it appears we have been planning for this eventuality for many orders of magnitude longer than these other distributions! quite funny, that!
05:46 <Shiz> keep it in your pants
05:46 <kaniini> minimalism: so basically, here's the talking points
05:46 <minimalism> kaniini: well yes.. some details like that were brought up in regards to spender's personality
05:46 <minimalism> I said 2015 should've been enough indication he was unstable
05:46 <TemptorSent> I don't know if ted ever drops in here, but I'm sure he can offer some very good advice on how to get something to actually land in the mainline in a reasonable time.
05:46 <minimalism> and may do this
05:46 <kaniini> minimalism: we have been planning for this outcome since 2011 actually
05:46 <minimalism> damn
05:47 <kaniini> minimalism: we kinda want to get in on this $ for patch game tho
05:47 <kaniini> minimalism: what do you think is good pricing
05:47 <TemptorSent> *LOL*
05:48 <minimalism> well, this is officially a sperg's nightmare.. Microsoft is winning in here
05:48 <minimalism> gonna wake up now
05:48 <kaniini> i am kidding about that
05:48 <minimalism> I know
05:49 <kaniini> there's a few aspects of our plan that have been in effect for many years
05:49 <kaniini> although we have been pushing much harder since 2015
05:49 <kaniini> securing userspace has been a high priority for us (which is largely why we switched to musl)
05:50 <kaniini> reverse engineering PaX has been an ongoing thing for some time, i have built prototype LSMs that emulate some PaX features in 2011 when spender first started threatening this
05:50 <TemptorSent> Whats the status on the gcc plugins?
05:51 <kaniini> letting the KSPP guys handle that one, they seem to have it on lock
05:51 <TemptorSent> Cool.
05:51 <TemptorSent> And the stack protection / NX perms?
05:51 blueness joined
05:52 <kaniini> stack protection is done for years on -vanilla ;)
05:52 t0mmy joined
05:52 <Shiz> the wiki page on the gentoo project seems to have an overview what is upstream and not
05:52 <Shiz> https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project#Progress_tracking
05:52 <kaniini> NX is in hardware honestly it's good enough for 99% of our installs
05:52 <TemptorSent> Right, but is the logic there?
05:52 <Shiz> it seems they managed to get kees onboard
05:52 <Shiz> that's nice
05:53 <kaniini> minimalism: so basically
05:53 <kaniini> minimalism: we're probably going to work with KSPP and get the parts we already came up with shot over there so they can do something useful with them
05:54 <kaniini> in the immediate term we are more worried about shipping 3.6
05:54 <kaniini> minimalism: one thing we want to do is switch system compiler to clang with CFI plugin and adapt the kernel to build under such a setup
05:55 <minimalism> There's a way to use clang without any dependency on gcc whatsoever?
05:55 <kaniini> which honestly between that and NX support is good enough
05:55 <kaniini> minimalism: yes, compiler-rt provides a libgcc replacement
05:55 <Shiz> UDEREF is pretty big
05:55 <minimalism> You may be able to completely de-GNU Alpine?
05:55 <Shiz> and well, MPROTECT
05:55 <kaniini> minimalism: yes
05:56 <minimalism> amazing
05:56 <kaniini> Shiz: MPROTECT can be done with LSM, i built a prototype 5 years ago
05:56 <TemptorSent> Yes, UDEREF/MPROTECT are the intersting parts of GRSEC IMHO.
05:56 <TemptorSent> And they're really not grsec dependent that I can see
05:56 <kaniini> they are pax features
05:56 <Shiz> nothing is "grsec dependent"
05:56 <Shiz> :P
05:57 <kaniini> UDEREF is a lot trickier
05:57 <TemptorSent> Well, it's not tied to much of the rest of their infrastructure.
05:57 <TemptorSent> UDEREF has a lot of possible problems to address.
05:58 <TemptorSent> Various semantic changes could break things in subtle ways.
05:58 <kaniini> UDEREF honestly
05:58 <kaniini> does not matter that much
05:59 <Shiz> imo uderef is pretty big
05:59 <kaniini> it's really not
05:59 <TemptorSent> Well, proper segmentation anyway.
05:59 <kaniini> if you're running on x86_64 it is a complete waste of time
05:59 <TemptorSent> There's a reason it's called a 'segmentation fault'.
05:59 <TemptorSent> Enforcing that is a good thing.
05:59 <kaniini> and code instrumentation does a reasonably good job at emulating the effects of UDEREF anyway
06:00 <kaniini> that's why GCC plugins is where all the hotness is these days
06:00 <Shiz> dont see at all how it's a waste of time
06:00 <kaniini> because x86_64 is not segmented
06:01 <TemptorSent> IIRC UDEREF essentially segments it with a layer of indirection tables.
06:02 <kaniini> right
06:02 <kaniini> like i said
06:02 <kaniini> waste of time verses what can be done with instrumentation
06:03 <TemptorSent> Yes, most of the time, but it does catch some very nasty classes of bugs and exploits I believe.
06:03 <kaniini> yes, but those bugs/exploits can be caught using instrumentation (which is how modern UDEREF works anyway)
06:04 <Shiz> modern UDEREF works through SMEP/SMAP
06:04 <Shiz> lol
06:04 <kaniini> that too
06:04 <kaniini> which is available in vanilla
06:04 <TemptorSent> Right, it abuses the extended page tables in creative ways.
06:04 <kaniini> sorry, i was thinking about KERNEXEC
06:05 <Shiz> i was wondering where this was going
06:05 <Shiz> lol
06:05 <TemptorSent> Ahh, yeah - kernexec makes sense.
06:06 <TemptorSent> The problem with UDEREF is mostly copy semantics.
06:06 <kaniini> copy_[to|from]_user() has been considerably hardened in recent years
06:06 <kaniini> so i still question the value of UDEREF ;)
06:06 <kaniini> anyway :)
06:06 <TemptorSent> That's not the problem it solves, its the problem it creates.
06:07 <TemptorSent> the problem it solves is bogus pointers suddenly wormholing to userspace
06:07 <Shiz> yeah, the problem is the *lack* of usage of copy_*_user()
06:07 <Shiz> through incompetence or pointer manip or otherwise
06:08 <TemptorSent> Pretty much, or sometimes through rather intentional tricks, which need to be worked around if UDEREF is implemented with special cases.
06:08 <Shiz> that's what pax_open_kernel/pax_close_kernel does
06:08 <Shiz> :P
06:09 <TemptorSent> Zero-copy semantics are the hardest to handle, since you really can't know which are valid pointers or not in many cases.
06:10 <TemptorSent> So fast network handling, encryption, and a few other things may end up breaking, possibly in insecure ways if care isn't used.
06:10 <TemptorSent> (such as leaking encryption keys)
06:11 <kaniini> sure
06:11 <kaniini> and if somebody wants to split that out
06:11 <kaniini> obviously we will carry it :P
06:11 <TemptorSent> I'd say any of the encryption/packet acceleration hardare driver/userland interfaces would require extensive auditing before using with something like UDEREF.
06:12 <kaniini> yes
06:13 <TemptorSent> So UDEREF isn't what I'd call low-hanging fruit, and it's value is somewhat tempered on many platforms without some serious effort.
06:13 <Shiz> hard but needed work :P
06:14 <TemptorSent> I'd go after finer-grained page permissions first, and possibly look at the copy semantics themselves.
06:17 <TemptorSent> I've got to call it an early night tonight, have a meeting to crash in the morning.
06:20 <kaniini> TemptorSent: i already have LSM that implements MPROTECT W^X and similar around here somewhere, NX-emulation is likely possible through playing with segments or PTEs on x86 (but honestly not sure if it is worth it)
06:20 <TemptorSent> Anway, if you get some spare time kaniini, would you please look into getting apk to spit out the checksums and file listing for an apk on demand?
06:21 <TemptorSent> Cool. I'll take a look at that this weekend.
06:22 vakartel joined
06:24 <TemptorSent> kaniini Perhaps an option to 'apk verify'?
06:26 <TemptorSent> kaniini: 'apk verify -v --<sumf>sums'
06:26 <TemptorSent> verify the file, and compute the requested sums.
06:27 <TemptorSent> kaniini: output as '<sumf>:<sum>' ie 'sha1sum:...
06:27 <TemptorSent> kaniini: Feasible?
06:29 <TemptorSent> So the listing would look essentially the same as a sha1sums run against the extracted file, with "sha1:" (oops, not sha1sum) prepended to each sum.
06:30 <TemptorSent> Ideally, it would also compute any requested sum after verifying the stored sum against the file contents.
06:32 <TemptorSent> So 'apk verify -v --sha512sums linux-hardened-4.9.24-r3.apk' would verify the contents using the sha1 sums in the PAX headers, then calculate the sha512 sums for the files, and print entries for each.
06:34 <TemptorSent> Anyway, g'night.
06:56 <clandmeter> morning climbers
06:56 <clandmeter> almost weekend!
06:59 <scadu> \o/
06:59 <algitbot> \o/
07:28 t0mmy joined
07:31 arch3y_ joined
07:40 <clandmeter> jirutka, can you look at openjdk on arm?
08:25 Ayyad joined
08:27 arch3y_ joined
08:33 arch3y_ joined
08:46 Shiz joined
08:48 arch3y_ joined
08:49 Shiz joined
09:04 fekepp joined
09:36 blueness joined
09:57 arch3y_ joined
10:17 irclogger_com joined
10:17 Topic for
10:42 stateless joined
10:42 rk324 joined
10:49 tg joined
10:55 cyteen joined
10:55 consus joined
10:57 blueness joined
11:00 LouisA joined
11:17 blueness joined
11:21 <jirutka> clandmeter: sorry, not now, no time
11:34 blueness joined
12:03 rdutra joined
12:04 czart joined
12:05 gromero joined
12:08 leitao joined
12:29 tmh1999 joined
12:42 arch3y_ joined
12:44 <ncopa> hi
12:47 gromero joined
12:52 <jirutka> hi
13:10 <jirutka> clandmeter: oh crap, gcj started segfaulting on armhf? that’s not good
13:22 cyteen joined
13:39 <Shiz> yello
13:43 <leitao> jirutka, hi there. regarding https://github.com/alpinelinux/aports/pull/1318, should I disable the broken test on all platform?
13:44 <Shiz> yell/w 74
13:44 <Shiz> whoops.
13:44 <jirutka> leitao: what’s wrong with that test?
13:51 <leitao> jirutka, I am not smart enough to understand.
13:51 <leitao> http://build.alpinelinux.org/buildlogs/build-3-6-ppc64le/main/mosh/mosh-1.3.0-r3.log
13:51 <leitao> fcolista might know better
13:52 <jirutka> hm, me neither
13:52 <jirutka> well, let’s disable it for all arches, until someone figure out what’s wrong
13:54 lucybun joined
13:55 t0mmy joined
13:59 arch3y_ joined
14:02 <kaniini> good morning
14:02 <kaniini> TemptorSent: i was thinking something like sha1sum output yes
14:03 gromero_ joined
14:04 <Shiz> sha1 :(
14:05 <Shiz> https://github.com/mobile-shell/mosh/blob/master/src/tests/unicode-later-combining.test
14:05 <Shiz> # XXX This test is fragile because it depends on tmux's unicode rendering.
14:05 <Shiz> # The baseline and variant tests produce different (but valid) outputs
14:05 <Shiz> # that are visually identical. The variant test is not run or validated.
14:06 <leitao> jirutka, updated the PR? Do you mind merging it?
14:06 <kaniini> Shiz: sha1 is what the embedded file hashes in apks are
14:06 <jirutka> leitao: please update the PR with details provided by Shiz
14:06 <jirutka> afk
14:07 <kaniini> leitao: done
14:08 <kaniini> ncopa, fabled: i think we need to cut apk-tools-2.7.1 release because of the solver bug
14:08 <fabled> kaniini, you foudn a fix?
14:08 <kaniini> yes
14:08 <kaniini> 2.7.0-r5 has the fix
14:08 <fabled> git log
14:09 <fabled> checking
14:10 <kaniini> problem was we would result in states like {old: nameA, new: nameB} and only a remove would be synthesized
14:11 <kaniini> wehn we needed a remove and an add
14:12 <fabled> ah, ok
14:12 <fabled> good
14:12 <fabled> would be good to get test case for that too
14:13 <fabled> i guess i could just tag a new version now
14:13 <fabled> there's one more commit coming up though
14:13 <kaniini> not sure
14:14 <kaniini> how to work it into testsuite
14:14 <kaniini> but i can give you the files i used to generate a reproducer
14:14 <kaniini> :)
14:14 <fabled> if you can, i can do the test suite update
14:14 <fabled> please email them
14:14 arch3y_ joined
14:15 <kaniini> fabled: http://turtle.dereferenced.org/~kaniini/reproducer.tgz
14:15 <ncopa> good job kaniini <3
14:16 <kaniini> i'm glad we tracked it down before 3.6 release
14:16 <fabled> yeah
14:16 <fabled> good work
14:16 <kaniini> we can thank spender for killing grsec off at this time which exposed the bug :P
14:16 <fabled> ok, the other patch was pushed to apk-tools.git too
14:17 <* kaniini> wonders what the GCC compiler plugins business is like
14:17 <TemptorSent> xentec: I'm not sure what that was in reference to?
14:17 <xentec> CTARGET <-> CTARGET_ARCH
14:18 <xentec> e.g. armhf is armv6
14:19 <fabled> kaniini, so.. the trigger is to have state with 'a' installed, and then swap repository to provide only b and do upgrade?
14:19 <kaniini> fabled: yes
14:20 <kaniini> fabled: b provides a
14:20 <fabled> ok, i'll do test case it for it, thx
14:20 <kaniini> fabled: literally same as what happened when i did the -grsec rename to -hardened
14:20 <fabled> i'll tag a release after that
14:25 <kaniini> great
14:29 <TemptorSent> kaniini: Actually having modules with deps helps too :)
14:30 arch3y_ joined
14:32 <TemptorSent> xentec: Ahh, thank you. Any idea where the original definition is? gcc spec file?
14:33 <xentec> afaik this pretty much is the original definition
14:34 <fcolista> how can I pass flags to gcc via APKBUILD? e.g. if I want to compile a binary with "-pg" flags
14:34 <fcolista> is CFLAGS ?
14:34 <TemptorSent> I mean the triples... arm*-*-*-*eabi and armv6*-*-*-*eabihf ...etc
14:35 <xentec> yeah, they're part of gcc spec
14:36 <TemptorSent> Okay, that's what I figured. At some point, extracting the machine defs would be useful.
14:36 <xentec> 'gcc -dumpmachine' ?
14:37 <TemptorSent> Yeah, but arm is tricky IIRC, because it supports multiple instruction sets.
14:37 <TemptorSent> I'm going even going to get into THUMB mode :P
14:38 <TemptorSent> Looking at feasiblity of supporting smaller arm chips.
14:40 <TemptorSent> kaniini: FWIW, we should consider compressing the kernel modules on installation (or packaging time) -- They go from ~279MB to 74MB in installed size.
14:46 <fabled> kaniini, test cased pushed
14:50 tkharju joined
14:59 fabled joined
15:09 <xentec> TemptorSent, then you might want to decompress them before building modloop
15:10 <TemptorSent> xentec: Yes, exactly -- I had a debat with Z
15:10 <TemptorSent> Shiz about the need for that.
15:12 <TemptorSent> The only problem is it takes quite a while to do on the host machine, but we could probably spawn that off and complete in the background.
15:13 <TemptorSent> When we build the dep tree, we want to use the checksums of the uncompressed modules, but if we're installing them on the host, we want to install them compressed to save significant storage. Even the initramfs modules should probably be compressed inside the cpio archive, as that saves ram for a little time.
15:31 t0mmy joined
15:40 LouisA joined
15:53 andypost joined
15:54 arch3y_ joined
15:58 BitL0G1c joined
16:00 bfritz joined
16:25 arch3y_ joined
16:39 arch3y_ joined
16:47 cyteen joined
17:13 <kaniini> TemptorSent: i'm not sure busybox module tools support compressed modules
17:19 arch3y_ joined
17:22 cyteen joined
17:43 t0mmy joined
17:59 cyteen_ joined
18:16 blueness joined
19:00 fekepp joined
19:07 Ayyad joined
19:23 LouisA joined
19:25 Ayyad joined
19:43 fabled joined
20:42 Ayyad joined
20:43 minimalism joined
21:01 Ayyad joined
21:05 fekepp joined
21:23 blueness joined
21:32 letoram joined
22:16 adsfasd joined
22:17 Ayyad joined
22:25 cyteen joined
22:41 cyteen joined
23:18 <jirutka> andypost: are you here?
23:23 <jirutka> omfg! of course I was right when I didn’t want to introduce two php7 pkgs, one in testing and the other one in community! tracked dependencies are totally messed
23:24 blueness joined
23:43 <duncaen> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c
23:43 <duncaen> they reverted it now
23:45 <jirutka> duncaen: why i don’t see it in GH mirror?
23:46 <duncaen> no idea how long it takes to sync
23:46 <jirutka> kk
23:46 <duncaen> but there are 4 cvs revs for this fix, something went wrong
23:46 <jirutka> ?
23:47 <duncaen> ah
23:47 <jirutka> actually, naming the other php7 differently would not help at all, just cause less confusion, b/c tracked deps does not implicitly contain pkgname
23:47 <duncaen> just one accidential without a commit message
23:48 <duncaen> the other ones are for the 6.1 branch and one for -current