Meeting 2014-08-28 20:00UTC and logs from last one

[22:23:45] <Zorry> 1.0 Toolchain
[22:24:49] <Zorry> gcc 4.9 have some nasty bugs (kernel) so would wait to use it 
[22:25:05] <prometheanfire> thought they were fixed
[22:25:05] <perfinion> isnt that fixed in 4.9.1?
[22:25:44] <Zorry> haven't look that close
[22:25:53] <Zorry> but could be fixed
[22:26:12] <Zero_Chaos> there is another one in 4.9.1 that people are talking about now
[22:26:24] <Zero_Chaos> something with mysql and -g and epic failure.
[22:26:40] <Zorry> did see that on -dev
[22:27:32] <prometheanfire> ya, think I've heard of that one as well
[22:27:54] <Zorry> have posted the gcc 4.10 default pie patch upstrem
[22:27:59] <Zorry> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02231.html
[22:28:22] <Zorry> so time to wait and see if it get applay or not
[22:28:59] <Zorry> affter that is time to upstrem ssp default upstream
[22:29:52] <perfinion> what is the diff between that ssp patch and the stack protector strong stuff that is already there?
[22:30:46] <Zorry> perfinion: it will make the compile defult to us ssp as default
[22:31:05] <Zorry> not what type
[22:31:35] <Zorry> so we don't to have all the patches in gentoo
[22:31:46] <perfinion> ah ok currently you have to use it manually everywhere without the patch?
[22:32:03] <Zorry> no we patch gcc
[22:32:32] <Zorry> but with a large patchset
[22:33:03] <perfinion> ah ok so upstreaming bit by bit
[22:33:09] <Zorry> yes
[22:33:29] <Zorry> did try all patches one time but no luck
[22:33:50] <Zorry> any thing else?
[22:34:14] <Zorry> next?
[22:34:26] <perfinion> sure
[22:34:51] <Zorry> 3.0 Selinux
[22:35:23] <Zorry> perfinion: ^^
[22:35:54] <perfinion> there was a pretty big problem with the libpcre upgrade that changed the compiled formats
[22:36:15] <perfinion> that is patched upstream and cherry picked into gentoo's libselinux and stablized now
[22:36:35] <perfinion> let me get the bug number
[22:37:45] <perfinion> bug 516608
[22:37:47] <willikins> perfinion: https://bugs.gentoo.org/516608 "sys-apps/policycoreutils with dev-libs/libpcre-8.35 - segmentation fault in /usr/sbin/setfiles"; Gentoo Linux, SELinux; RESO, FIXE; lari.korpi:swift
[22:38:10] <perfinion> also 2.3 userland was stabilized yesterday for selinux
[22:38:58] <perfinion> and i sent stuff in to openRC to fix up support for selinux during boot and some labelling issues
[22:39:16] <perfinion> they will be in openrc 0.13 when it gets released
[22:40:01] <perfinion> also noone except me replied to swift's mail to the list: http://article.gmane.org/gmane.linux.gentoo.hardened/6266
[22:40:13] <perfinion> did anyone else have thoughts about it?
[22:40:50] <perfinion> i think thats all i have for selinux
[22:41:31] <Zorry> anyone else?
[22:41:44] <blueness> Zorry, my parents just showed up!
[22:41:51] <blueness> crazy
[22:42:22] <Zorry> blueness: can you have the kernel stuff?
[22:42:34] <blueness> yes, let me update everyone
[22:42:51] <Zorry> 2.0 Kernel Grsec/PaX
[22:43:09] <blueness> there were two CVE's that meant rapid stabilizing 3.2.61-r2, 3.14.12-r2, 3.15.5-r2
[22:43:31] <blueness> but then the next day there was a nice fix to some dma stuff for usb dvd drives, and i didn't want ot leave it out
[22:43:43] <blueness> so i stabilized 3.2.61-r3, 3.14.12-r3, 3.15.5-r3
[22:43:55] <blueness> the sets are identical except for a few lines of code
[22:44:06] <blueness> so i'll remove the -r2's in a week
[22:44:17] <blueness> but both sets are very well tested, i did lots of extra tests
[22:44:25] <blueness> so we should be good for now
[22:44:29] <blueness> about PaX
[22:44:46] <blueness> we now have install-xattr-0.3 is working very well, Zero_Chaos is using it exclusively
[22:45:11] <blueness> i got a patch into portage which uses install-xattr if USE=xattr, and failing that will use install.py
[22:45:20] <perfinion> blueness: /topic says -r2, do you mean -r1/2 instead of -r2/3?
[22:45:24] <blueness> but biggest problem i had was understanding portage
[22:45:44] <blueness> perfinion, it should be -r3 but let me look at the stabilizations later
[22:46:03] <blueness> so here's what the problem was with portage+install-xattr
[22:46:30] <blueness> portage does a chdir() into /usr/lib/portage/pym from $S
[22:46:50] <blueness> so when install-xattr installed into $PWD it was installing into  /usr/lib/portage/pym !!!
[22:47:04] <Zero_Chaos> the xattr stuff is amazing, we need that stabilized asap but I think that we will have to wait since the portage team is having man-power issues.
[22:47:06] <blueness> zmedico understood this and fixed it for install.py
[22:47:31] <blueness> but i didn't so i had to trace the C code to figure out what was going on
[22:47:39] <blueness> it was subtle and tricky but i got it
[22:47:45] <blueness> next ...
[22:47:58] <blueness> there was a bug against elfix because liberte linux uses it
[22:48:15] <blueness> the problem there was they use USE=-ptpax which means building paxctl-ng without libelf
[22:48:16] <blueness> but
[22:48:49] <blueness> i bundled in fix-gnustack which necessarily needs libelf, so dropping in a stage3 from USE=ptpax to -ptpax caused an needless rebuild :(
[22:49:07] <blueness> i've now refactored that tree, and will push out fix-gnustack seperately
[22:49:33] <blueness> we needed fix-gnustack because we weren't using the prelinks stuff to fix GNU_STACK RWX
[22:49:42] <blueness> so i wrote a seperate package for it
[22:49:49] <blueness> that will be out in elfix-0.9
[22:49:54] <blueness> i'll email people when i do
[22:49:57] <blueness> next ...
[22:50:17] <blueness> i'm working on a GLEP which requires package management systems to export VDB information
[22:50:23] <blueness> in particular NEEDED.ELF.2
[22:50:47] <blueness> the reason is because that linkage information is important to form a graph between elf object and the libraries they link against
[22:50:55] <blueness> this is for revdep-pax migrate-pax etc etc
[22:51:00] <blueness> portage does this
[22:51:04] <blueness> paludis does not
[22:51:18] <blueness> it already has the council's okay
[22:51:56] <blueness> with that we will be able to support consistent pax markings between libraries and the exes that consume them
[22:52:15] <blueness> on paludis systems and exherbo ... i don't know if they care but whatever
[22:52:24] <blueness> next ... backing up to 1.0 toolchain
[22:52:52] <blueness> i finally got unlazy and built ppc-uclibc stages.  i got vanilla working but hardened is broken.  i have not had a chance to debug why.
[22:53:17] <blueness> but ppc-uclibc-hardened will "complete" the set of all arches that are used for embedded stuff --- like real embedded stuff
[22:53:28] <blueness> eg the mikrotik 1000 series is ppc arch
[22:53:42] <blueness> okay i'm done
[22:53:48] <blueness> (sorry for being out of order)
[22:53:58] <blueness> (btw, did i mention my parents are crazy :)
[22:54:34] <Zorry> next
[22:54:57] <Zorry> 5.0 Profiles
[22:54:59] <blueness> perfinion, you're right  -r1/2 instead of -r2/3
[22:55:24] <blueness> okay mgorny has been pushing out the multilib ABI stuff
[22:55:58] <blueness> they're okay in vanilla amd64 and x86 and so they are okay in hardened
[22:56:14] <blueness> there is an stacking problem for vanilla mips and therefore for hardened mips :(
[22:56:22] <blueness> there is no problem for ppc64
[22:56:27] <blueness> ppc is not multilib
[22:56:41] <blueness> and arm is not multilib although we're working on naming the abi there
[22:56:56] <blueness> and the independant uclibc musl (which don't inherit from arch) are okay
[22:57:09] <blueness> so hardened + mips is still a problem
[22:57:30] <Zorry> it have been some talks in the -dev ml about to redo the profiles but no work on it
[22:57:34] <blueness> the issue is if you select multilib with only n32 as the main abi, you get both n32 and o32
[22:57:46] <blueness> Zorry, it will not happen
[22:58:05] <blueness> the way *I* redid the profiles for uclibc was to cut out arch and default
[22:58:13] <blueness> and collapse them into hardened/linux/uclibc
[22:58:18] <blueness> but that was pretty daring
[22:58:28] <blueness> no one will do that with the main profiles
[22:58:52] <Zorry> blueness: agree it need a lot of work if one will change the profiles
[22:58:58] <blueness> in my opinion, the profiles are the singal worst design flaw in gentoo which we are stuck wiht
[22:59:25] <blueness> okay that's all for profiles
[22:59:39] <Zorry> the parent file should be in /etc/portage/make.profils/
[22:59:53] <Zorry> but is a long way to it
[23:00:00] <Zorry> any one else?
[23:00:04] <Zorry> next
[23:00:25] <blueness> Zorry, yeah intreesting idea.  we need to just start creating a parallel set of profiles and *abandon* the sinking ship
[23:00:43] <perfinion> the funtoo mixin thing for profiles is a pretty nice idea
[23:00:50] <Zorry> blueness: eselsect/portage need the support
[23:00:57] <Zero_Chaos> blueness: when I work on funtoo styel profiles, you and I will be archetecting things properly from teh start ;-)
[23:01:12] <Zero_Chaos> blueness: but that's after defcon, so mid-august
[23:01:14] <blueness> shouldn't be a problem hacking eselect, portage is more owrk
[23:01:24] <specing> why not just backport funtoo stuff?
[23:01:33] <blueness> Zero_Chaos, yeah seriously let's do this thing
[23:01:42] <blueness> specing, maybe we will
[23:01:45] <Zero_Chaos> blueness: we will, after defcon.
[23:01:48] <blueness> k
[23:02:07] <blueness> its like every time someone wants to do something, no you can't because it will break X or Y
[23:02:09] <Zero_Chaos> blueness: is number two on my priority list after helping likewhoa merge his aufs stuff into genkernel
[23:02:19] <Zorry> 6.0 Docs
[23:02:53] <blueness> 1. i added some documentation on EMULTRAP to the kernel config file saying we need it for python in gentoo
[23:03:16] <blueness> 2. i added similar documenation to the pax-quickstart guide, but its a big document and its buried
[23:03:38] <blueness> there is just so much about pax its hard to reduce it to just a few lines
[23:04:15] <blueness> that's it for me
[23:04:34] <Zorry> next?
[23:04:51] <Zorry> 7.0 Bugs
[23:05:05] <Zorry> anyone?
[23:05:12] <likewhoa> blueness: i'll make sure he moves his ass with my patch for genkernel
[23:05:31] -*- Zero_Chaos shakes his ass at likewhoa 
[23:05:38] <likewhoa> he's to busy getting ready to go to vegas to have fun with old granny midgets
[23:05:39] <blueness> Zorry, nothing on bugs that ihaven't already mentioned
[23:05:55] <Zorry> okay
[23:06:00] <Zorry> 8.0 Media
[23:06:20] <blueness> i will be blogging about the virtuals of exporting VDB!
[23:06:27] <blueness> probably tomorrow
[23:07:15] <blueness> that's it for me
[23:07:27] <blueness> (Zorry can we have a 9.0 Miscellanea)
[23:07:48] <Zorry> okay
[23:08:04] <Zorry> next then ^^
[23:08:32] <blueness> i've been doing lots of other stuff that isn't hardened but i think i should mention fyi
[23:08:53] <blueness> 1. i'm trying to save ppc/ppc64 - you might have seen those emails on the gentoo-dev@ list
[23:09:13] <blueness> not enough manpower, if anyone here wants to help, we can get an account on timberdoodle
[23:09:42] <blueness> 2. i'm helping hasufell get libressl into gentoo.  i'm mostly worried about libressl + hardened and/or uclibc/musl
[23:10:01] <blueness> i have a patch into uclibc to get it working there -> http://lists.uclibc.org/pipermail/uclibc/2014-July/048437.html
[23:10:15] <blueness> again testing welcome
[23:10:29] <blueness> um ... i think that's it
[23:10:43] <Zero_Chaos> blueness: might want to wait till libressl actuall works, considering I hear it isn't a drop in replacement at all.
[23:10:59] <blueness> nope not at all
[23:11:13] <blueness> but it will be in openbsd 5.5
[23:11:20] <blueness> its just getting it to work with linux world
[23:11:55] <blueness> Zero_Chaos, so libressl does *actually work* on openbsd 5.5
[23:12:11] <blueness> the issue is porting it, which is I guess our job
[23:12:32] <blueness> "wait till it works" -> means we do that work
[23:13:00] <blueness> okay i'm done
[23:13:14] <Zorry> okay
[23:13:24] <Zorry> 10.0 Open Floor
[23:13:44] <Zorry> ty for the meeting