Hi
Log from the meeting
/Magnus (Zorry)
[21:10:22] <Zorry> 1.0 toolchain
[21:10:34] <klondike> pong
[21:10:42] <Zorry> :)
[21:11:28] <Zorry> have gcc 4.7 in hardened-dev overlay for testing
[21:12:22] <Zorry> needed to fix gcc4.5.3 so it don't compiles with pie
[21:12:36] <Zorry> to lower the hw and meme use for x86
[21:12:55] <Zorry> as we allready do with 4.6
[21:14:14] <Zorry> i hope i get the -D/-U fix upstream on gcc 4.7
[21:14:43] <Zorry> else we will have some probs with kernel (__KERNEL__)
[21:14:49] <blueness> yep
[21:15:32] <blueness> did you submit that patch yet?
[21:16:03] <Zorry> blueness: yes that way i needed the copy assingment on FSF
[21:16:11] <blueness> ah okay
[21:16:23] <Zorry> so i can summit more pathes upstream
[21:17:21] <blueness> Zorry, since we don't have a tinderbox for hardened testing, what's the best way to test gcc-4.7?
[21:17:30] <Zorry> glibc-2.15 have hit the tree and no need to change the patchset for it
[21:17:32] <blueness> i've been just cloning vms and upgrading to see what breaks
[21:18:28] <prometheanfire> ditto
[21:18:40] <Zorry> blueness: update and build packages
[21:19:00] <Zorry> you can do it esly with pkcore
[21:19:14] <Zorry> do have the script some whare
[21:19:28] <Zorry> the hard part is to look at the logs
[21:19:30] <blueness> prometheanfire, are you cloing kvm machines?
[21:19:36] <Zorry> and fix useflags
[21:19:43] <blueness> right
[21:19:51] <prometheanfire> yes
[21:20:03] <blueness> we're doing the same thing then
[21:20:12] <prometheanfire> though my test VM is broken atm, it will be fixed soon
[21:20:20] <Zorry> that way i try to do it with some frontend
[21:20:38] <prometheanfire> though I think we are both probably only testing amd64
[21:20:57] <blueness> prometheanfire, no i test both
[21:21:01] <blueness> x86 and amd64
[21:21:27] <blueness> maybe we should systematize this so we go through a checklist, i'll think about that
[21:21:51] <Zorry> gcc4.7 is still on stage3 but sone on stage4 and then rc version will hit
[21:22:29] <blueness> Zorry, have you looked at hardening for the new 32-bit abi?
[21:22:30] <Zorry> and it use g++ to compile stage2 and 3
[21:22:57] <Zorry> blueness: nope but should work ot of the box i think
[21:23:01] <blueness> (g++ to compile stage2 and 3 is wierd)
[21:23:09] <klondike> blueness: can you share a link to said abi?
[21:23:22] <blueness> Zorry, i have all the stuff vapier gave me and it works but i haven't tried to hardened
[21:23:31] <blueness> klondike google for -mx32
[21:23:42] <blueness> and look at dev.gentoo.org/~vapier/x32
[21:24:07] <Zorry> blueness: i still need to add the target to configure checkes
[21:24:41] <blueness> i figure, but i can hack that up the way i did for mips + ssp
[21:24:50] <Zorry> k :)
[21:25:49] <blueness> next?
[21:26:24] <Zorry> need to add some uclibc .32 check to so we kan enable ssp
[21:26:47] <blueness> yep
[21:26:57] <Zorry> else i don't have any more on it
[21:27:01] <blueness> should i talk about uclibc now?
[21:27:11] <blueness> under toolchain?
[21:27:15] <Zorry> go a head
[21:27:18] <blueness> k
[21:27:31] <blueness> I got {i686,amd64} uclibc 0.9.32.1 {vanilla,hardened} working
[21:27:57] <blueness> now ssp is done the same as it is in glibc
[21:28:09] <blueness> with NPTL/TLS, before we were using ncopa's hack
[21:28:16] <Zorry> yep
[21:28:43] <blueness> so we have PIE, SSP and the uclibc equivalent of _FORTIFY_SOURCES=2
[21:28:53] <Zorry> :)
[21:29:01] <blueness> the tarbarlls are here -> http://opensource.dyc.edu/pub/stage4-uclibc/
[21:29:03] <SwifT> nice
[21:29:19] <blueness> and the overlay for the profiles and a few ebuilds are here ->
[21:29:23] <Zorry> need to test that so i get good configure checks :)
[21:29:24] <blueness> http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=shortlog;h=refs/heads/uclibc
[21:29:40] <blueness> they're on the uclibc branch of hardened-dev overlay
[21:29:51] <blueness> a few points too keep in mind
[21:30:19] <blueness> 1) the ebuild for uclibc-0.9.32.1 is NOT for cross compiling, and it doesn't give you option to use your own config file
[21:30:45] <blueness> 2) i had to force a few flags here and there and so the profiles needed tweeking
[21:31:00] <blueness> but the stages work and i have running vms with PaX hardened kernel
[21:31:08] <Zorry> nice
[21:31:19] <quantumsummers|c> sweet sweet nectar
[21:31:21] <blueness> i may make those available too
[21:31:49] <blueness> okay that's it for uclibc, i think from this point on we can maintain full hardening like we do on glibc
[21:32:04] <blueness> done with that
[21:32:07] <Zorry> k
[21:32:20] <Zorry> any one else?
[21:32:26] <blueness> or questions?
[21:32:35] <klondike> blueness: do you expect to offer crosscompiling?
[21:32:50] <blueness> klondike, no, it was painful
[21:33:01] <blueness> buildroot kept producing a borked toolchain
[21:33:14] <blueness> it was some issue with how the end files were beeing built
[21:33:26] <blueness> so either -static didn't work and dynamic did
[21:33:28] <blueness> or vice versa
[21:33:34] <blueness> or shared objects were borken
[21:33:38] <klondike> :(
[21:33:50] <blueness> so i upgraded from my old uclibc images using a manual technique
[21:34:04] <blueness> ROOT=rootfs emerge --keep-going -eq world
[21:34:11] <blueness> and then fixing one thing at a time
[21:34:17] <ralos> better that way
[21:34:18] <blueness> so first upgrade gcc with nptl
[21:34:33] <blueness> then do that above trick
[21:34:37] <blueness> yeah ralos that what i found
[21:35:33] <Zorry> next then?
[21:35:36] <blueness> yes
[21:35:47] <Zorry> 2.0 Kernel
[21:36:03] <blueness> me again, let me make this quick
[21:36:09] <blueness> 1) RSBAC is back in the tree ~arch
[21:36:25] <blueness> upstream has been supporting rsbac and someone has been testing
[21:36:39] <blueness> so i tested, looked "good enough" and i put it back
[21:36:58] <blueness> right now i'm just doing pure RBAC not RSBAC + PaX but i'll do that in the future
[21:37:07] <blueness> we'll see if people start using it again
[21:37:22] <blueness> for those of you who don't know, RSBAC is very similar to GRSEC
[21:37:27] <RobbieAB> Hmmm?
[21:37:34] <blueness> uh oh!
[21:37:41] -*- RobbieAB is building a hardened box
[21:37:42] <blueness> i knew that would raise eybrows
[21:37:58] <RobbieAB> I have no idea what the differences are! :D
[21:38:13] <RobbieAB> Zorry: Why would you do a 2.0 kernel? :o
[21:38:14] <blueness> okay there's not much more to say about that now, we'll see if it builds up a user basse
[21:38:28] <Zorry> RobbieAB: we have a meeting
[21:38:32] <SwifT> we'll need to polish up our docs on thsi, not?
[21:38:41] <RobbieAB> Oh. Sorry. :(
[21:38:41] <blueness> 2) next issue is that i tweaked the SERVER/WORKSTATION/VIRTUALIZATION definitions
[21:38:57] <blueness> SwifT, yes, we need to relink the RSBAC documentaiton
[21:39:16] <ralos> bluenessL FYI we only ever had about 2 users of RSBAC in the entire time it was in the tree
[21:39:42] <blueness> ralos, well i'm at 50% then because i've got one!
[21:39:52] <SwifT> =)
[21:40:11] <klondike> SwifT: regarding docs I don't think just relinking will suffice
[21:40:21] <klondike> docs there are ZOMG old so...
[21:40:25] <blueness> it doesn't seem like a lot of work and so i'll maintain it unless upstream goes quiet
[21:41:18] <blueness> i can take a look and see what state they're in
[21:41:27] <blueness> i'll get Issiah to look to, he's using it
[21:41:44] <blueness> any more on rsbac?
[21:41:55] -*- klondike sent a request for help regarding RSBAC docs but nobody answered U_U
[21:42:03] <blueness> you did
[21:42:33] <blueness> okay should i move on to my point 2 --- sorry i was going to fast above?
[21:42:48] <Zorry> do it
[21:43:02] <blueness> 2) next issue is that i tweaked the predefined GRSEC settings for the hardened-sources
[21:43:19] <blueness> upstream has been adding some more hardening options and i've been testing them
[21:43:24] <blueness> so i added the following
[21:43:34] <blueness> GRKERNSEC_SYSFS_RESTRICT – hardening of /sys by restricting read
[21:43:41] <blueness> on SERVER only
[21:43:52] <blueness> people didn't like it on WORKSTATION or VIRTUALIZATION
[21:43:57] <blueness> also
[21:44:02] <blueness> RKERNSEC_AUDIT_PTRACE – add ptrace logging
[21:44:11] <blueness> GRKERNSEC_SETXID – propagate uid/gid/caps to children threads
[21:44:20] <blueness> PAX_RANDKSTACK – randomize all task’s kernel stack, like PAX_RANDUSTACK for userland
[21:44:26] <blueness> PAX_MEMORY_STACKLEAK – zero kernel stack before return
[21:44:28] <blueness> and
[21:44:41] <blueness> CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR <- this is for KERNEXEC
[21:44:53] <blueness> its the return address method
[21:45:08] <laen> Mmm, like.
[21:45:08] <blueness> the last one has is not forced, but on by default
[21:45:31] <SwifT> i thought the new glibc had all apps read from /sys?
[21:45:49] <blueness> _OR is more effiecient that _BTS but it does not work for binary modules
[21:46:10] <blueness> SwifT, the hardening of /sys means the perms are tightned up
[21:46:17] <blueness> so root can still read from /sys
[21:46:43] <prometheanfire> but desktop plugs for users cannot (like wicd and battery monitoring)
[21:46:44] <blueness> with the desktop the problem was that some unprivileged KDE apps (if i'm not mistaken) needed /sys
[21:46:53] <blueness> prometheanfire, right
[21:47:12] <blueness> so no big deal
[21:47:48] <blueness> i have received no bug reports with the other options. they are forced on with any predefined gentoo GRSEC setting
[21:48:18] <blueness> any questions/comments with that stuff?
[21:49:13] <Zorry> go on
[21:49:20] <SwifT> dan walsh (redhat) sais that /sys/devices/system/cpu/online will be read by every application due to changes in glibc
[21:49:34] <SwifT> not sure if it is rhel-specific or something that we'll see
[21:49:42] <blueness> SwifT, okay i'll keep that in mind
[21:49:44] <SwifT> also don't know if this is something that can be ignored or not
[21:49:49] <SwifT> k
[21:49:54] <blueness> if i have to, i can relax _SYSFS_RESTRICT
[21:49:55] <prometheanfire> does spender know that? he should probably
[21:50:08] <blueness> i'll bring it up
[21:50:30] <blueness> but remember, only those processes without root/wheel will have problems
[21:51:07] <prometheanfire> is the sysfs perms relaxable via a group perm?
[21:51:10] <blueness> this is a lot like tightening up /proc where some apps need access say to smaps
[21:51:34] <prometheanfire> true
[21:51:40] <blueness> prometheanfire, not right now but that's not something thats hard to add
[21:52:04] <SwifT> looks like the patch in glibc doesn't have the app fail when it isn't readable/available, so that might be ok
[21:52:08] <blueness> so if we wanted our own modified perms we could, like allowing some privileged group
[21:52:44] <blueness> SwifT, where are you looking for this info?
[21:53:23] <SwifT> I googled on that path + glibc ;-)
[21:53:26] <SwifT> http://repo.or.cz/w/glibc.git/commitdiff/84e2a551a72c79b020694bb327e33b6d71b09b63
[21:53:32] <blueness> ty
[21:53:55] <SwifT> yw
[21:54:21] <blueness> actually that was very useful
[21:54:28] <blueness> it is the same issue with /proc again
[21:54:32] <blueness> -> pen_not_cancel_2 ("/proc/stat", flags);
[21:54:39] <blueness> -> open_not_cancel_2 ("/proc/stat", flags);
[21:54:45] <blueness> and
[21:54:53] <blueness> open_not_cancel_2 ("/sys/devices/system/cpu/online", flags);
[21:55:01] <blueness> so they're addressing both the same way
[21:55:22] <blueness> oh yeah i remember, it was the gnome system monitor that broke with the restrictions on /proc
[21:55:32] <blueness> back in the day
[21:56:07] <SwifT> *snif* the good ol' days *snif*
[21:56:12] <blueness> there robbat2 came up with a patch that relaxed that problem
[21:56:18] <blueness> lol yeah
[21:56:21] <SwifT> okay, 'nuf sweetness, let's continue ;)
[21:56:25] <blueness> k
[21:56:51] <blueness> i'm done, just want to say that the next stable kernel will have those additional restrictions in the predefined GRSEC settings
[21:57:08] <blueness> then i'll deal with the bug reports :)
[21:57:26] <blueness> next?
[21:57:36] <Zorry> 3.0 Selinux
[21:58:01] <Zorry> SwifT prometheanfire ^^
[21:58:02] <SwifT> okay; after a small hiatus the next set of policy updates came around a week or so ago
[21:58:21] <SwifT> some bugs are still popping up, but unrelated to new changes (more because we get more and more users)
[21:58:47] <SwifT> i've currently didn't find the time to work on those yet, I first wanted to get us to suport initramfs systems as some users have legitimate need for them
[21:58:53] <SwifT> sadly, no luck there yet though :(
[21:59:29] <SwifT> i'll be working on updating the policies for the remaining bugs the next coming days, so rev 12 should hit hardened-dev overlay before FOSDEM ;)
[21:59:40] <prometheanfire> I've not noticed anything yet (knock on wood) need to test more actively though and start doing more policy dev
[21:59:48] -*- prometheanfire needs to be prod'd
[21:59:58] <SwifT> community feedback is positive tough, many users are well versed in selinux and are trying to help us get it in better shape
[22:00:10] <SwifT> yes, prometheanfire will do phpfpm ;)
[22:00:17] <prometheanfire> one of these days
[22:00:30] <prometheanfire> and then a few others that are on my list :D
[22:00:56] <SwifT> I noticed some of the changes that we still need to do (like proper /lib and /lib64 translations) aren't possible with our current policies yet, since the necessary changes were brought in refpolicy just after the release of 2.20110726
[22:01:12] <SwifT> given refpolicy history,I can imagine that a new stable erlease will be made in a month or so
[22:01:50] <SwifT> acceptance of our patches in refpolicy is slow but ok, not that many patches were rejected (only one that I know of now)
[22:02:16] <SwifT> still quite a lot of patches waiting in the queue for review
[22:02:45] <blueness> SwifT, can you explain the issue with initramfs + selinux?
[22:02:49] <SwifT> also, now that the necessary virtualization stuff is in, we can see to get libvirt support improved within gentoo on selinux
[22:02:59] <blueness> (when youre done with other sutff)
[22:03:00] <SwifT> sure
[22:03:52] <SwifT> without initramfs, init (the first process called) quite quickly loads in the selinux policy and re-exec()'s itself, so that it transitions from the kernel sid to (load policy) kernel_t to (re-exec) init_t
[22:04:18] <SwifT> because it does that so quickly, no changes have been made to the system yet, so selinux isn't complaining about anything
[22:04:38] <prometheanfire> sleep 1s
[22:04:46] <SwifT> with initramfs, many activities are done prior to switch_root (and calling init), which has all those activities run in the kernel sid
[22:05:04] <SwifT> as a result, labels are set incorrectly and processes run in the wrong context (if they run at all)
[22:05:31] <SwifT> the largest problem is that device files are wrongly labeled, and the moment the policy is loaded, the kernel_t domain has no rights to relabel
[22:05:59] <SwifT> one way to resolve it is to "fix" the labels before loading the policy (but that means we need to be able to set labels without a loaded policy)
[22:06:03] <blueness> okay this is a problem
[22:06:13] <SwifT> the other is to bring in the selinux policy in the initramfs and load it prior to the activities
[22:06:26] <klondike> SwifT: can't we set an initial policy then load a second one?
[22:06:32] <SwifT> I think the latter is the "most secure" part, but also the least manageable, since the policy is modified way more often than the initramfs
[22:06:44] <blueness> i was just going to suggest having selinux policies in initramfs
[22:06:45] <SwifT> klondike: yes we can
[22:06:54] <blueness> sounds like painful amount of work though
[22:07:08] <klondike> Nope
[22:07:08] <quantumsummers|c> you can stack initramfs
[22:07:10] <SwifT> reloading a new policy isn't the problem, but policies can be incompatible
[22:07:14] <SwifT> that's what you really don't want
[22:07:27] <quantumsummers|c> which would require a script to update the policy initramfs when it changes
[22:07:42] <SwifT> there is a workaround, i.e. to have the system boot in permissive and only switch to enforcing later in the process, but that's not the "secure" way of working
[22:07:57] <blueness> SwifT, what about starting with selinux permissive and then at the end of initramfs switch to enforcing
[22:08:04] <klondike> SwifT: can we get a file to policy assignment?
[22:08:10] <blueness> or would process still be in the wrong context?
[22:08:31] <SwifT> blueness: nope, the moment switch_root occurs and init loads, the processes start running correctlyt
[22:08:48] <SwifT> also, it looks like no "remaining" processes are there (for instance udev is stopped before init is called)
[22:09:04] <SwifT> blueness: but production systems don't have development support (i.e. permissive)
[22:09:11] <blueness> no processes from initramfs should survive the switchroot
[22:09:29] <SwifT> perhaps I can make a permissive-enabeld system still somewhat more hardened (so that "setenforce 1" cannot be undone, like grsec_lock feature)
[22:09:33] <blueness> SwifT, i mean temporarily
[22:09:50] <prometheanfire> well, if dracut can manage the policies, then that could work
[22:10:11] <blueness> dracut = fedoras' initramfs builder?
[22:10:15] <prometheanfire> ya
[22:10:19] <blueness> yeah see what they do
[22:10:30] <prometheanfire> I don't know what the caps of it are though
[22:10:35] <SwifT> dracut is easy to tweak, but I think it is more realistic to either work with permissive and switch to enforcing early in boot runlevel
[22:10:46] <prometheanfire> but less secure
[22:11:02] <SwifT> that's something currently being discussed (part of the trusted boot stuff)
[22:11:04] <blueness> the windows is just the boot period
[22:11:16] <blueness> i'd be okay with that
[22:11:40] <blueness> there's no remote access and no one on console during intramfs, so its pretty safe
[22:12:24] <SwifT> I think i'll work out both cases... one when servers really don't want to enable development mode for selinux (which means include policy in initramfs) and one for the rest, which switches to enforcing early in boot (oh, and one as-is for those that don't need initramfs ;)
[22:12:38] <klondike> blueness: actually
[22:13:28] <klondike> There is a legit case where you need remote access on initramfs on servers
[22:13:34] <klondike> Well indeed a few more
[22:14:00] <blueness> klondike, encrypted hd?
[22:14:03] <klondike> In my case this is required to unlock the encrypted root disk
[22:14:03] <blueness> or partition
[22:14:08] <blueness> yeah
[22:14:08] <SwifT> remote access on initramfs? sounds ucky
[22:14:18] <klondike> Yes but it can also be needed to fix a broked system
[22:14:25] <klondike> *broken
[22:14:27] <SwifT> use a server with decent remote support :p
[22:14:30] <blueness> SwifT, klondike is right but i wouldn't do it on a production box
[22:14:38] <blueness> iLO
[22:14:51] <SwifT> that, or DRAC
[22:14:59] <SwifT> depends on your underlying hardware
[22:15:11] <SwifT> but that's outside the scope of the current discussion ;)
[22:15:20] <SwifT> any other questions on SELinux?
[22:15:38] <blueness> nope, i'm confident you guys will get it
[22:15:50] <Zorry> next then?
[22:15:55] <blueness> sure
[22:16:15] <Zorry> 4.0 Grsec/PaX
[22:16:28] <blueness> yippy me again ... i'll try to be quick
[22:16:50] <blueness> i had a meeting with pipacs, he should have xattr support for pax flags out soon, if not already
[22:16:59] <prometheanfire> 3.2 series?
[22:17:06] <blueness> yeah
[22:17:26] <Zorry> :D
[22:17:37] <blueness> the option will depend on BROKEN for now, so its still experimental, and i'll have to decide how to implement it in gentoo
[22:17:50] <blueness> his implementation will be different from my prototype
[22:18:14] <blueness> 1) the xattr pax flags will live in user.pax name space (like i did)
[22:18:26] <blueness> 2) they will be ascii not binary (i did binary)
[22:18:49] <Zorry> k
[22:18:51] <blueness> 3) they will be set using setfattr and getfattr and he's not sure to what degree he will integrate this with paxctl
[22:19:18] <blueness> 4) if both xattr pax flags are set, and PT_PAX, then they must be identical otherwise the binary will be killed
[22:19:25] <blueness> (i was just ignoring PT_PAX)
[22:19:46] <Zorry> k
[22:19:46] <blueness> 5) the X pax flag will (probably) be deprecated for good
[22:19:55] <blueness> so ....
[22:20:19] <blueness> once its out i'll make it available in some *highly experimental* way
[22:20:44] <blueness> and i'll have to migrate those changes to the pax utilties that i'm bundling in the elfix package
[22:20:52] <blueness> that's easy but still i'll have to do it
[22:21:06] <blueness> any questions on that?
[22:21:18] <blueness> hopefull klondike you'll be able to document some of this stuff
[22:21:48] <klondike> That depends on how well my thesis goes :/
[22:22:03] <blueness> lol k
[22:22:11] <blueness> one last thing ... revdep-pax
[22:22:37] <blueness> klondike brought up the point that when migrating flags from a library to the binary that links against it
[22:22:53] <blueness> you don't want to replace the binary's flags with the libraries, you want to ADD them
[22:23:19] <blueness> so i fixed that, thanks klondike it was a stupid oversight on my part
[22:23:46] <klondike> Varsagod ;)
[22:24:03] <blueness> oh there's also a test suite for revdep-pax at http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=tree;f=tests-only/testrevdeppax;h=297c0498da47f386a74f2917a543d43af207c4d4;hb=88436c1fb641600e9eb403bb1374100bf9b456a4
[22:24:35] <blueness> which i wrote to test klondike's logic for "adding" the back migrated flags
[22:24:40] <blueness> k done
[22:24:59] <Zorry> any one else?
[22:25:11] <Zorry> next then
[22:25:29] <Zorry> 5.0 Profiles
[22:25:56] <blueness> nothing from me
[22:26:08] <Zorry> not me ether
[22:26:41] <Zorry> next then?
[22:27:03] <Zorry> 6.0 Docs
[22:27:15] <Zorry> SwifT: klondike
[22:27:16] <klondike> SwifT: goes first
[22:27:44] <SwifT> nothing major; a week after last online meeting, the selinux handbook got updated
[22:27:57] <SwifT> put in a reboot where needed, added some information on revdep stuff
[22:28:17] <SwifT> other than that, I started working a bit with the gentoo wiki (wiki.gentoo.org/wiki/SELinux)
[22:28:29] <SwifT> but nothing major yet, perhaps for next meeting then ;-)
[22:28:50] <SwifT> yo klondike, your turn ;)
[22:29:22] <klondike> Well since I now have managed to have radeon gallium drivers with hardened
[22:29:31] <klondike> thanks to blueness changes to revdep-pax
[22:29:37] <klondike> I'll document how to do it
[22:29:47] <klondike> Either in the faq or in a separate document
[22:30:04] <klondike> Or in both
[22:30:31] <klondike> I bet a quick guide with 2/3 commands on the faq and a long guide explaining everything would be best
[22:30:44] <klondike> yet I'm very time constrained thanks to XMAS
[22:30:55] <SwifT> the TCP attack?
[22:31:26] <klondike> No, the celebration, I have been 5 weeks in spain
[22:31:34] <klondike> And did little work on my thessis
[22:31:46] <klondike> BTW RobbieAB is asking if Network Manager works on hardened
[22:32:02] <klondike> Answer is yes with Desktop Profile and KNetworkManager
[22:32:24] <klondike> Not sure about gnome counterpart though
[22:32:32] <klondike> Well that's all from me
[22:32:35] <klondike> Questions?
[22:33:04] <Zorry> nope
[22:33:09] <RobbieAB> Should be doable than... If I have time, I might try it on my main laptop soon. Thank you.
[22:33:16] <Zorry> next then
[22:33:29] <klondike> huh
[22:33:29] <Zorry> 7.0 Bugs
[22:33:38] <klondike> s/Dektop/Workstation/g
[22:34:07] <blueness> python!
[22:34:09] <Zorry> the python libffi
[22:34:19] <blueness> the bug that will not die!
[22:34:23] <Zorry> yep
[22:34:37] <SwifT> the library that will not die
[22:34:55] <Zorry> on python we need some #if ....
[22:34:56] <blueness> bug #329499
[22:34:58] -*- klondike looks at haskell
[22:34:59] <willikins> blueness: https://bugs.gentoo.org/329499 "dev-lang/python-2.6 'rwx' mmap() calls prevent loading of ctypes module (possibly others) under new PaX kernels"; Gentoo Linux, Development; CONF; radegand:python
[22:35:23] <Zorry> and libffi we need talk to toolchain
[22:36:18] <blueness> Zorry, there is Arach's patch's plus pipacs' trampoline code
[22:36:34] <blueness> i tried it and it seems to work, but i'm not sure its a final solution
[22:36:42] <Zorry> blueness: yes have seen it
[22:37:03] <blueness> the python people won't talk to me about it
[22:37:16] <Zorry> [Arfrever] whanted some if define .... stuff
[22:37:29] <klondike> !herd python
[22:37:30] <willikins> klondike: (python) bicatali, chutzpah, dev-zero, djc, floppym, lordvan, maksbotan, marienz, nelchael, neurogeek, patrick, radhermit, rafaelmartins, sping
[22:37:58] <blueness> Zorry, what would the define be contingent on, some -D compiler flag?
[22:38:39] <Zorry> blueness: don't know have't check how we could check the thing yet
[22:39:21] <Arfrever> blueness: It's better to avoid conditionally applied patches. Unconditional patches might be accepted by upstream.
[22:39:39] <blueness> Arfrever, ah okay
[22:40:19] <blueness> so we need to think of a way of checking for what we want
[22:40:25] <Zorry> yep
[22:40:44] <blueness> the problem with ./configure checking for stuff like that is that users will boot between pax and non-pax kernels
[22:41:10] <blueness> so its better to just add a flag, --enable-pax which sets a define PAX and gets added to gcc -DPAX
[22:41:32] <blueness> then #if defined PAX .... do pax-ish patch ... #endif
[22:41:47] <Zorry> configure --enable-pax ?
[22:42:03] <blueness> yeah when configuring python to be built
[22:42:25] <Zorry> should work
[22:42:26] <Arfrever> I would suggest --with-pax-compatibility.
[22:42:32] <blueness> Arfrever, okay
[22:42:43] <Zorry> k
[22:42:51] <blueness> i think i can takle this one
[22:43:03] <blueness> i'll add it to my TODO for next meeting
[22:43:08] <Arfrever> But any new options in `configure` would be accepted by upstream only for 3.3 :( .
[22:43:24] <blueness> Arfrever, fine, we'll backport if necessary
[22:43:41] <blueness> whoah 3.3 ... 3.2 is frozen already?
[22:43:56] <Arfrever> New features are allowed only in 3.3.
[22:44:04] <blueness> k
[22:44:15] <Arfrever> 3.2 is stable release for production systems :) .
[22:44:25] <blueness> well if i send a patch upstream i'll do it against their HEAD
[22:45:21] <Zorry> what do we do with libffi then?
[22:45:37] <Zorry> it need some fixing to
[22:45:52] <blueness> yeah, not sure
[22:46:01] <Zorry> a rwx check ?
[22:46:46] <Arfrever> I suggest that you create a separate bug for libffi, assign it to toolchain team and make this bug block bug #329499.
[22:46:49] <willikins> Arfrever: https://bugs.gentoo.org/329499 "dev-lang/python-2.6 'rwx' mmap() calls prevent loading of ctypes module (possibly others) under new PaX kernels"; Gentoo Linux, Development; CONF; radegand:python
[22:47:36] <Zorry> k
[22:48:11] <blueness> yeah i think so too, we need to start separating these issue
[22:48:43] <Zorry> +1
[22:49:42] <blueness> i really hope python doesn't start heading down the path of haskell or go or all these other languages that need rwx mappings for the runtime codegen
[22:50:40] <Zorry> hops that to
[22:50:59] <Zorry> we may need some configure stuff on libffi to
[22:52:08] <blueness> when i see Arach next i'll tell him i'm going to try to get his stuff upstream
[22:52:22] <Zorry> k
[22:52:27] <blueness> any other bugs?
[22:53:05] <Zorry> not from me
[22:53:27] <Zorry> next then
[22:53:36] <Zorry> 8.0 media
[22:53:38] <klondike> next!
[22:53:45] <klondike> Ohh that's me :D
[22:53:56] <Zorry> yes you :)
[22:54:01] <klondike> Well we have a confirmed talk in FOSDEM
[22:54:06] <klondike> (say hurrays)
[22:54:22] <prometheanfire> hurray
[22:54:23] <Zorry> :D
[22:54:27] <klondike> I will kidnap lejonet before the talk so we practice the approach we did at campus Party
[22:54:38] <lejonet> klondike: haha yeah
[22:54:48] <Zorry> will be in the brackground :)
[22:54:54] <Zorry> background*
[22:55:00] <klondike> Which so far seems to have been the most succesful getting to non programmers (based on this and other experiences I had then)
[22:55:16] <klondike> Zorry: if you have a chance I still encourage you to talk about toolchain
[22:55:18] <blueness> nice!
[22:55:43] <Zorry> klondike: will do it next year i think
[22:56:07] <Zorry> blueness: we need to make you come
[22:56:10] <klondike> K Zorry we can try to prepare it during FOSDEM
[22:56:12] <lejonet> klondike: I think one of the main issues with our performance at campus party was that you were speaking spanish while explaining what we were to demonstrate xD
[22:56:29] <lejonet> So I was "lolwhut?!" all the time :P
[22:56:31] <blueness> Zorry, if it were during the summer it would be good, but its hard to get away in the middle of a semester
[22:56:35] <prometheanfire> lejonet: same
[22:56:36] <klondike> This time I speak spanglish ;)
[22:56:48] <lejonet> xD
[22:56:49] <blueness> what i need to do is make arrangements with someone here to take my classes for a week
[22:57:06] <Zorry> k
[22:57:11] <lejonet> blueness: yoink your best student xD
[22:57:31] <klondike> blueness: think about that, good beer & good chocolate, what could go wrong?
[22:57:32] <blueness> yeah that's actually a good idea, let me see if i can get funding for them
[22:58:03] <klondike> Well going back on topic
[22:58:08] <lejonet> I actually gave my teacher in the OS course the proposition that I handle the gentoo part of the course, mainly because he seems waaay overworked
[22:58:43] <klondike> lejonet: if you need a hand poke me
[22:58:53] -*- klondike loves PR
[22:59:17] <klondike> Regarding twitter Flameeyes is making use of the account to ask things so if I come asking thinks I can't not answer you know why
[22:59:30] <lejonet> klondike: hehe will do if it ever comes up for discussion
[22:59:44] <klondike> I'd expect others to do the same as the knowledge of the accounts spreads
[23:00:09] <klondike> I think it is also time to announce them on the gentoo-hardened list
[23:00:32] <klondike> Also if anybody needs the password ask me for it although I think I made all of you aware of it
[23:00:41] <klondike> That's mostly all from media
[23:00:45] <klondike> Questions?
[23:01:04] <Zorry> nope
[23:01:17] <SwifT> nope, not from me
[23:01:41] <Zorry> next then ?
[23:02:00] <klondike> onwards!
[23:02:07] <Zorry> 9.0 Open floor
