Hi
Here is the meeting log.
/Magnus
[21:11:10] <Zorry> 1.0 Toolchain
[21:11:40] <Zorry> gcc 4.8 have gone to stage 3 and may patches did't get in :(
[21:12:39] <Zorry> so will try next version but will try to add some of it to the 4.8 gentoo one so we can support mips
[21:13:30] <blueness> Zorry, what happened?
[21:13:38] <blueness> still debating or were they rejected?
[21:13:48] <SwifT> or ignored
[21:14:00] <Zorry> glibc 2.16 did have som probs with the pie patch that it use have fix that
[21:14:13] <blueness> that was minor
[21:14:21] <blueness> the alphaPC patch?
[21:14:23] <Zorry> blueness: still debating/ignored
[21:14:43] <Zorry> blueness: did my own
[21:14:59] <blueness> k
[21:15:36] <Zorry> blueness: will spilt the pie/ssp/fortify/Wformat stuff to seperated patches
[21:17:20] <Zorry> still need to test if we can get hardenedno* working with the DRIVER_SELF_SPECS stuff
[21:17:40] <Zorry> so we can use that for mips
[21:18:08] <blueness> right, but i could live with no hardenedno* on all arches, i don't know about others
[21:18:27] <blueness> we need to fix all -nopie stuff in the ebuilds via the flags anyhow
[21:18:33] <blueness> there should be no reason to switch profiles
[21:18:39] <Zorry> yep
[21:19:16] <blueness> only for pedagogy or testing would hardenedno* be useful and we can document how to change the CFLAGS to do that manually
[21:19:29] <blueness> anyhow, i don't know how other feel
[21:19:40] <blueness> (I can remember the last time I switched profiles)
[21:19:57] <SwifT> I don't think I ever did
[21:19:59] <Zorry> i think we should mail hardened ml to see
[21:20:38] <blueness> Zorry, maybe even gentoo-dev@ after too to see how people like Anarchy feel about it
[21:20:56] <Zorry> i only use it for debuging
[21:21:01] <blueness> me too
[21:21:03] <Zorry> blueness: that to
[21:22:23] <blueness> (i have some quick report for toolchain when your done)
[21:22:44] <Zorry> mail hardened and -dev when gcc 4.8 is geting closer
[21:23:04] <Zorry> about removing hardenedno*
[21:23:23] <Zorry> any one else?
[21:23:26] <blueness> yep
[21:23:37] <blueness> me!
[21:23:40] <Zorry> yes
[21:23:51] <blueness> quick report on the hardened + uclibc work
[21:24:17] <blueness> previously i was doing stage4s but i am now migrating to catalyst built stages for very clean stages
[21:24:38] <blueness> stage3-{amd64,i686}-uclibc-{hardened,vanilla} is done
[21:25:11] <blueness> stage3-mips32r2-uclibc-{hardened,vanilla} is almost done, i'm tweaking the packages.build for minor dependencies
[21:25:18] <blueness> stage3-arm will be next
[21:25:45] <blueness> little endian mips will be last because the loongson2f has some difficulties with the mips32r2 ISA
[21:26:17] <blueness> i put a page up and i will improve a description of the project pending some criticism from klondike
[21:26:42] <blueness> and that's all for now
[21:26:57] <Zorry> next then?
[21:27:07] <blueness> yep
[21:27:11] <Zorry> 2.0 Kernel
[21:27:33] <blueness> okay here's what's up there
[21:28:02] <blueness> as far as bugs, there is nothing very new
[21:28:13] <blueness> i will be stabilizing the next set soon
[21:28:48] <blueness> however the very latest hardened-sources i put on the tree today have a new patch which enables the user.* namespace on xattrs for tmpfs
[21:29:07] <blueness> i wrote the patch and asked for feedback but didn't get any significant feedback yet
[21:29:17] <blueness> however i tested and it doesn't seem to break anything
[21:29:26] <blueness> nonetheless i will not stabilize those kernesl for a while
[21:29:42] <blueness> the user.* xattrs on tmpfs is necessary for the XATTR_PAX + portage
[21:30:14] <blueness> if we pax mark during building on tmpfs then we need to have tmpfs support all our pax markings
[21:30:24] <blueness> so
[21:30:43] <blueness> i would appreciate testing of the kernle to make sure i didn't break anything
[21:30:56] <prometheanfire> it in 3.6.6? I've been using that
[21:30:58] <pipacs> (blueness, if it works fine and/or someone says it's the only thing needed to do, i'll take into pax)
[21:31:30] <SwifT> I don't use tmpfs for building stuff, sorry
[21:31:36] <blueness> pipacs, works for me, its a one line patch, i just had to convince myself that that was all that was needed
[21:31:40] <blueness> and i'm pretty sure it is
[21:31:57] -*- lejonet uses tmpfs on all his systems more or less
[21:31:57] <pipacs> so does the vfs handle the actual attr content itself?
[21:32:02] <pipacs> no code needed for tmpfs itself?
[21:32:04] <blueness> so take a look at it, it simple says XATTR_USER_PREFIX is a legit prefix for xattrs in mm/shmem.c
[21:32:08] <lejonet> for building that is, so I could upgrade and test it a bit
[21:32:15] <pipacs> i looked at it, but i'm not a vfs guy ;)
[21:32:34] <blueness> pipacs, it worked so i assume that yes,
[21:32:50] <blueness> but your point is well taking, i didn't understand the relationship between tfmps and vfs
[21:33:00] <blueness> but i don't think its like ext4 etc
[21:33:10] <pipacs> well, 'works' as in no oops or 'this is what other file systems do and get away with as well' ;)
[21:34:12] <blueness> pipacs, i'm not sure tmpfs works the same way through vfs, works means no oops and the xattrs are recognized by userland apps
[21:35:03] <blueness> pipacs, do you know a vfs guy that can tell us if we're missing anything?
[21:35:31] <blueness> i did email paris and the other dude
[21:35:34] <pipacs> nope otherwise i'd have asked somebody :P
[21:35:36] <blueness> no response
[21:35:47] <blueness> pipacs, should i try to lkml it?
[21:36:04] <pipacs> uhm, maybe not ;)
[21:36:11] <pipacs> but perhaps fsdevel or whatever it's called
[21:36:15] <SwifT> Miklos Suchanek (on https://lwn.net/Articles/439320/) mentioned that the user.* needed some more thoughts due to "kernel memory use" but I have no idea what he meant
[21:37:14] <pipacs> swift i think that's because .user attrs can come from unprivileged userland
[21:37:21] <pipacs> and hence influence kernel memory usage
[21:37:22] <blueness> SwifT, not sure either but it does seem and easy way to get userland stuff into kernel mem space
[21:37:33] <blueness> yep
[21:37:40] <blueness> what pipacs just said :)
[21:38:04] <SwifT> k
[21:38:20] <pipacs> so maybe some length limits or accounting should be put on the user attrs on tmpfs
[21:38:40] <pipacs> i guess we don't care for portage but for general use, it can be a problem (DoS)
[21:39:20] <blueness> pipacs, there is sanity checking in setfattr and getfattr
[21:39:40] <blueness> and my userland util paxctl-ng sanitizes the flags
[21:39:48] <blueness> so -PPPMMMMMMMMM = -PM
[21:40:06] <blueness> so you can't go over a 5 char limit
[21:40:19] <SwifT> probably more due to users being able to "while true; do setfattr -n user.${i} "hello"; i=$(($i+1)); done"
[21:40:27] <blueness> yep
[21:40:58] <SwifT> perhaps you can restrict the patch to only support the one attr we need?
[21:41:06] <blueness> SwifT, i can
[21:41:45] <klondike> SwifT: then we can do said attr infinite...
[21:42:00] <blueness> SwifT, we don't need any old user.* but just name "user.pax" and 5 char value
[21:42:28] <blueness> okay we have something to think about
[21:42:38] <blueness> i will not be stabilizing anything soon
[21:42:45] <blueness> with that patch i mean
[21:43:14] <pipacs> or quota on tmpfs if xattrs are accounted there
[21:43:14] <pipacs> we can also make it more strict and only allow user.pax for now
[21:43:30] <blueness> yeah that's easy enough
[21:43:31] <Zero_Chaos> steev: yeah pentoo has been hardened for a while
[21:44:37] <blueness> okay i think that's all for kernel, i will talk more about the userland XATTR_PAX later in the agenda
[21:45:01] <Zorry> any one else?
[21:45:03] <prometheanfire> just a quick note
[21:45:11] <blueness> shoot
[21:45:45] <prometheanfire> confirmed that virt is fast now if using nested pages and kernels greater then version hardened-3.5.4-r1 (r2 is prefered)
[21:45:49] <prometheanfire> that's it
[21:46:13] <Zorry> :)
[21:46:42] <Zorry> next then
[21:46:57] <Zorry> 3.0 Selinux
[21:47:07] <SwifT> ok
[21:47:33] <SwifT> policy revision 5 has been stabilized and r6 is in hardened-dev. I'm not going to push r6 to the main tree due to breakage in an admin interface
[21:47:49] <SwifT> i'm doing the last few tests on an r7 as we speak, so I'll probably move that one to hardened-dev later this evening
[21:48:24] <SwifT> next to the policies, the latest userspace utilities are now also in ~arch (just a few days later than our previous meeting) and are going to be stabilized soon
[21:48:50] <SwifT> the one exception is still setools (r5) as that has a fix for swig which is incompatible with apol, and I just can't see a way out of it
[21:49:23] <SwifT> while pushing out the userspace utilities, I also added in support for epatch_user so that makes updatingpatching the packages by us or end users easier to manage
[21:49:51] <SwifT> that's it in a nutshell.
[21:50:29] <Zorry> some one else?
[21:50:55] <prometheanfire> zfs support was added, still needs upstreaming, but was added, feel free to test
[21:51:06] <prometheanfire> SwifT: it going into r7?
[21:51:44] <SwifT> yeah, I'm most likely going to push in changes I find ok in our repo before upstream gets them; they're sometimes making it hard to get stuff in
[21:51:47] <SwifT> prometheanfire: yes
[21:52:02] <prometheanfire> ya
[21:52:33] <Zorry> next then
[21:52:48] <Zorry> 4.0 Grsec/PaX
[21:53:04] <Zorry> blueness: ^^
[21:53:06] <blueness> k
[21:53:13] <blueness> okay continuing my story into userland
[21:53:39] <blueness> vapier is moving fast on *removing* PT_PAX support from the toolchain. i think its too fast
[21:53:56] <blueness> well it depends how fast glib-2.16 hits the tree
[21:54:19] <blueness> if he does then we must migrate pax markings to XATTR_PAX immediately
[21:54:24] <blueness> or asap
[21:54:33] <blueness> there are a few repercussions
[21:54:50] <blueness> 1) the PF_PAGEEXEC etc definitions are got from elf.h
[21:54:52] <pipacs> that's not a wise move from him
[21:55:00] <blueness> which means paxctl doesn't built
[21:55:01] <pipacs> but there's always paxctl -c or -C
[21:55:24] <pipacs> blueness, paxctl builds 'cos it has the defines
[21:55:28] <pipacs> but your tools don't ;)
[21:55:37] <blueness> now it doe
[21:55:39] <blueness> does
[21:56:05] <blueness> so tthat's 2) i already migrated the defs to the elfix packages, but i'll have to stabilize elfix-0.6.0
[21:56:15] <blueness> which we cna do in about 2 weeks or so
[21:56:34] <blueness> and 3) i have to update the pax-utils.eclass to intellegently do pax markings
[21:56:47] <pipacs> what about installing a pax.h that everyone can use instead?
[21:56:51] <blueness> oh and 4) the users really have to know what's going on, so i must document
[21:57:14] <blueness> pipacs, you know, after reading your priv msg that seems like the most sensible thing to do
[21:57:16] <SwifT> was just about to ask about that - migrations or checks that users can do to validate if they're XATTR_PAX-ready
[21:57:21] <blueness> those definitions should be made public
[21:58:03] <pipacs> yeah, as they used to be :P
[21:58:12] <blueness> SwifT, part of installing and maintaining a pax hardened system will entail supporting xattrs on your hardrive partitions
[21:58:14] <blueness> and in tmpfs
[21:58:32] <blueness> so that means linux-2.6.32.60 will be dropped
[21:58:33] <prometheanfire> which means newer kernels
[21:58:40] <blueness> right
[21:59:08] <blueness> i need to build a full xattr_pax system and see if pax-mark -m in ebuilds works
[21:59:31] <blueness> if it does then we can proceed, but i wish we could keep the backwards compat for about 6 months
[21:59:43] <blueness> if glibc-2.16 takes that long, then we can live with it
[22:00:21] <SwifT> blueness: yes, but I can imagine that having all prereqs satisfied doesn't automatically turn stuff into XATTR_PAX. Will there be a "remark world" command for users to execute (I assume you don't want them to "emerge -e @world" just to hit the new pax-utils.eclass)
[22:00:26] <blueness> btw, the new pax-utils.eclass is on the hardened-dev overlay in the deprecated XATTR branch
[22:00:35] <blueness> let me get the url, and please criticise it
[22:00:58] <blueness> SwifT, i will have scripts for that
[22:01:23] <blueness> so it will be a migrate2xattr.py or something
[22:02:00] <blueness> http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=commit;h=eb3a2e198c926aca7063aa036793bb94bfbec1ef
[22:02:26] <blueness> there's the commit of the eclass ^^^ after elfix-0.6.0 is stable i can email gentoo-dev@ and get feedback
[22:02:59] <blueness> okay any questions or (more likely) concerns?
[22:03:45] <SwifT> what would happen if vapier stabilized 2.16 before we are ready?
[22:04:16] <blueness> SwifT, i asked for this work to be a blocker, but as he said, he doesn't mind edging people along
[22:04:28] <SwifT> and if it's a "bad thing", can be at least DEPEND="!>sys-libs/glibc-2.16" in the previous versions of elfix (or other tools that hardened users would have)?
[22:04:52] <blueness> actually its a bit more complicated
[22:04:53] <SwifT> that way, as long as our tools aren't ready, portage will not try to upgrade glibc
[22:04:57] <SwifT> crap
[22:05:00] <SwifT> as usual :p
[22:05:03] <blueness> here's what would happen exactly ...
[22:05:23] <blueness> if glibc 2.16 goes in we loose the definition of PF_PAGEEXEC etc in elf.h
[22:05:39] <blueness> in which case things that need that will no longer build. this is an esay fix
[22:06:05] <blueness> but we can still build with PT_PAX phdr because of patch 63 in binutils
[22:06:20] <blueness> when that goes then we loose PT_PAX all together
[22:06:37] <blueness> there is paxctl -C and -c but i don't know ... that reduces us to the otehr distros
[22:07:00] <blueness> but, if he holds off on leaving PT_PAX in for longer, i can bridge past 2.16 by installing our own pax.h
[22:07:29] <blueness> and then we would just have to #include <pax.h> wherever we needed the definitions for PF_PAGEEXEC, PF_MPROTECT etc
[22:07:32] <pipacs> blueness, i can break the defs into a separate header in paxctl
[22:07:37] <pipacs> then you'll install that
[22:07:52] <blueness> pipacs, we just need to make sure our two packages don't collide
[22:08:05] <blueness> so i would think leave paxctl as it, since i nhas the built in defs
[22:08:10] <blueness> and i'll break mine out
[22:08:26] <klondike> Hum
[22:08:41] <klondike> Why don't just keep the header in a separate package for everybody?
[22:08:50] <pipacs> paxctl it the source of all userland pax stuff, isn't it ;)
[22:08:57] <pipacs> so i'm happy to make it provide the public header
[22:09:18] <pipacs> pax users will need paxctl anyway
[22:09:29] <blueness> pipacs, what about other distros
[22:09:36] <pipacs> what about them?
[22:09:43] <pipacs> they'd install the header as anyone body else
[22:09:55] <pipacs> esp, when paxctld is implemented
[22:10:05] <pipacs> will make your lives easier too i think
[22:10:09] <blueness> pipacs, how do we avoid a collision of headers?
[22:10:15] <pipacs> err
[22:10:17] <pipacs> what collision?
[22:10:25] <blueness> if i were to break it out of paxctl-ng
[22:10:29] <pipacs> there'd be only one canonical source of the pax defs
[22:10:52] <blueness> yeah okay that does make sense, i'll just include it then
[22:10:55] <pipacs> and being the auhtor of pax, i'd like to tie it to something i maintain/provide already
[22:10:56] <blueness> easy enough
[22:11:06] <blueness> yeah never mind totally makes sense
[22:12:27] <blueness> okay anything else?
[22:12:57] <pipacs> maybe paxctld i hinted at above ;)
[22:13:08] <pipacs> i was talking to spender some time ago about it
[22:13:15] <blueness> yeah what's that?
[22:13:19] <pipacs> a userland daemon responsible for maintaining pax flags
[22:13:44] <blueness> what's the advantage ofmaking it a daemon?
[22:13:45] <SwifT> where would it store its definitions?
[22:13:47] <pipacs> one of the *notify APIs in the kernel should be usable for it these days
[22:13:53] <pipacs> a simple config file
[22:13:59] <pipacs> just paths/regexps
[22:14:17] <pipacs> on a matching file creation the pax flags would be set
[22:14:27] <SwifT> similar to restorecond for selinux labels
[22:14:28] <pipacs> easiest would be for xattrs
[22:14:31] <blueness> oh yeah
[22:14:33] <pipacs> SwifT, yes
[22:15:16] <pipacs> now for portage you don't really need it, but if you're a developer and constantly forget about relaxing some flags, it'd be a godsend
[22:15:27] <pipacs> and i do enough of it that i figured i might as well automate it ;p
[22:15:40] <prometheanfire> just have a dir that it watches for conf file update
[22:15:46] <prometheanfire> like udev almost...
[22:16:51] <pipacs> anyway, i just mentioned it to float the idea
[22:17:02] <pipacs> if anyone has ideas,etc, email me
[22:17:16] <Zorry> sound as a good idea
[22:17:41] <Zorry> next then?
[22:17:59] <Zorry> 5.0 Profiles
[22:18:10] <blueness> me me me!
[22:18:13] <SwifT> for selinux, just one thing: the old selinux profiles are gone now
[22:18:23] <blueness> (go ahead Swift)
[22:18:29] <SwifT> nope, that was my one thing ;)
[22:18:36] <SwifT> you're all free
[22:18:42] <blueness> lol mine is a two liner
[22:19:01] <blueness> i made hardened/linux/uclibc/{amd64,x86,mips} public
[22:19:35] <blueness> this was needed for catalyst because it will not run for any old profile path, only paths in /usr/portage/profiles/profiles.desc
[22:20:03] <blueness> anyhow, no one should try to switch, and even if they do accidentally, there would be so many blockers, so i don't think its that dangerous
[22:20:13] <blueness> taht's it
[22:20:30] <blueness> ans SwifT good for taking out those ancient profiles
[22:20:47] <Zorry> have masked orc (jit) dev-lang/orc use jit and some packages use that
[22:21:42] <Zorry> thats is all from me
[22:21:51] <Zorry> next then?
[22:22:00] <blueness> yep
[22:22:13] <klondike> Hum
[22:22:13] <DemonWitch> Can someone check my rkhunter.log? I run rkhunter --check, got some warnings and i have no idea if those are false positives. http://bpaste.net/show/58053/
[22:22:14] <Zorry> 6.0 System interity
[22:22:25] <klondike> Zorry: before we move
[22:22:26] <Zorry> DemonWitch: we still have meeting
[22:22:33] <SwifT> not that much to say - I'm mainlyu waiting for kernel 3.7 to be ready
[22:22:33] <klondike> About the orc stuff
[22:22:35] <DemonWitch> Zorry, i forgot
[22:22:41] <SwifT> oh, klondike go ahead
[22:22:46] <klondike> Do we have jit use masked too?
[22:23:02] <Zorry> klondike: nope only -jit
[22:23:11] <klondike> Then why do we mask orc?
[22:23:51] <klondike> I don't mind either default disabling or masking but we should be consistent over what we do
[22:24:14] <Zorry> klondike: the discripsion don't say any thing of jit
[22:24:34] <Zorry> will most likly unmask it later on
[22:24:37] <klondike> So we open a bug to get the description fixed :P
[22:24:59] <Zorry> klondike: thay don't whant to do it
[22:25:01] <klondike> But Ok, was wondering if you were planning masking forever or not
[22:25:16] <klondike> Hum Zorry can I see the bug number?
[22:25:30] <Zorry> i wanthe to rename the use flag to jit but no no..
[22:25:50] <klondike> Well bugzilla is now down anyways, so PM the bug later please
[22:25:56] <SwifT> =)
[22:26:05] <klondike> I think updating use.desc should work better though
[22:26:38] <Zorry> klondike: haven't any bug about it talked to de devs
[22:26:56] <klondike> Okey then I'll open a bug :P
[22:27:24] <SwifT> ok, so on system integrity - like I said, I'm mainly waiting for 3.7 as that will contain the IMA appraisal support as well (which allows you not only to report on integrity, but also act on it)
[22:27:50] <SwifT> the docs are already on that (not fully finished, but still) and the packages that we need to get IMA supported are now in hardened-dev overlay
[22:28:21] <SwifT> but beyond that, that's about it for system integrity for now (didn't have a vacation to work on it thorougly yet)
[22:28:48] <Zorry> okay
[22:29:00] <Zorry> any one else?
[22:29:11] <Zorry> next then
[22:29:21] <Zorry> 7.0 Docs
[22:29:41] <Zorry> klondike: SwifT ^^
[22:29:46] <SwifT> for SELinux, the policy constraints (and how they work) are now also documneted on our site
[22:30:18] <SwifT> and the SELinux handbook has been updated a small bit (and the changes at the end of the document as well) to reflect the use of named initrc scripts
[22:30:33] <SwifT> i didn't touch any other hardened-docs though
[22:31:01] <blueness> brb 5 mins
[22:31:28] <Zorry> next then
[22:31:38] <Zorry> 8.0 Bugs
[22:32:27] <Zorry> still waiting for upstream on the libffi bug to applay the patch
[22:32:31] <klondike> Nothing on docs from me
[22:32:51] <SwifT> meh, just in time that I moved r7 to hardened-dev; git.overlays.gentoo.org is down as wel
[22:33:24] <Zorry> and i got some good respont from upstream about the fix
[22:34:11] <Zorry> any one else?
[22:34:44] <SwifT> nope, not from me
[22:34:54] <Zorry> okay next then
[22:34:55] <klondike> Not from me
[22:35:02] <prometheanfire> non
[22:35:05] <Zorry> 9.0 Media
[22:35:30] <Zorry> klondike: ^^
[22:35:37] <klondike> So we had this cozy talk on FSCONS
[22:36:06] <klondike> Had a lot of public and good following, so let's hope we get more people since most understood the issues presented
[22:36:33] <klondike> We should also star working on whatever we'd like to present at FOSDEM if anything
[22:36:41] <klondike> I'm open to suggestions on that
[22:37:39] <klondike> And now is when I was expecting discussion on that
[22:38:28] <Zorry> do not even know if i can get there
[22:38:49] <klondike> Zorry: what's the problem for you?
[22:39:09] <Zorry> klondike: may not have any work
[22:40:21] <Zorry> but will try to get there
[22:40:51] <klondike> Well we can try to fix something for you
[22:41:15] <klondike> Worst case we both pick a bus here and you can pass as many nights as you need in my place at Göteborg :P
[22:41:29] <prometheanfire> Zorry: or in my hotel room
[22:41:33] <klondike> I'm sure SwifT may be willing to lend you a little bit of floor if you need it
[22:41:35] -*- prometheanfire needs to order that room...
[22:42:10] <Zorry> klondike: mouny is not the prob but the unplyment rules
[22:42:14] <lejonet> Zorry: It'll sort itself :) We'll make sure of that
[22:42:33] <klondike> Zorry: can't you say it is formation?
[22:42:51] <klondike> Because IIRC FOSDEM orgs can make assistance certs if needed
[22:43:00] <lejonet> Zorry: klondike has a point, you are allowed to go out of country for education, which you could argue that FOSDEM is
[22:43:14] <Zorry> lejonet: iknow
[22:43:34] -*- klondike has been breaking munching on laws since he was a little child
[22:43:42] <klondike> Ehum
[22:43:58] <klondike> munching only, all was always legally on the edge :P
[22:44:44] <klondike> Anyway what about the rest, should we prepare a talk for the crossdistro track?
[22:45:02] <lejonet> Zorry: we will help you get the permissions etc needed when it comes closer, don't worry :)
[22:45:03] <SwifT> I was hoping for a security devroom, but alas... security isn't hot anymore lately :p
[22:45:26] <klondike> SwifT: we had a security track at FSCONS :P
[22:46:02] <prometheanfire> klondike: I'd be open to it, but dunno what to say other then your talk last year
[22:46:31] <klondike> Well I can open a thread on the ML to see what users want
[22:47:06] <Zorry> we could do that
[22:47:18] <klondike> And Zorry even if it means getting the Work minister in a legal spike rest assured I'll try to get you to FOSDEM :)
[22:47:31] <klondike> Though lejonet may know more of the laboral stuff than me
[22:48:03] <klondike> Well that's all for media
[22:48:09] <lejonet> klondike: I have some experience about it :)
[22:48:15] <prometheanfire> :D
[22:48:22] <klondike> Fan with so many thing in my head forgot to send the meeting through twitter :(
[22:48:35] <Zorry> i was on the gentoo miniconf
[22:48:37] <lejonet> Worst case scenario is that we fool the rules with my company, because you are allowed to go out of country for work :)
[22:49:38] <Zorry> blueness: back?
[22:51:34] <blueness> Zorry, i am but busy with pipacs :)
[22:51:49] <blueness> side chat, but i can put my 2 cents in
[22:52:02] <blueness> where arewe at in the agenda?
[22:52:20] <Zorry> blueness: the subprojets
[22:52:34] <blueness> oh yes
[22:52:52] <blueness> i think we might want to consolidate the kernel/grsec/pax into one project
[22:53:07] <blueness> because as yo usee from the meeting, there is such a confluence between them
[22:53:33] <Zorry> thats fine with me
[22:53:39] <blueness> it just seem funny to have split the kernel from that, i'm not sure what that means, so i can email a proposal alter but i wanted to see what people think
[22:53:45] <blueness> the only thing is that pax spills in to userland
[22:53:50] <blueness> but its still mostly kernel
[22:54:29] <klondike> blueness: I'll present strong resistance if it involves changing the docs structure
[22:54:42] <klondike> Other than that, meh!
[22:55:09] <pipacs> blueness, expect more spill in the future ;P
[22:55:12] <pipacs> such as plugins ;)
[22:55:41] <blueness> klondike, no not really why would you think it would involve docs?
[22:56:10] <klondike> Because nowadays some docs are a little spread out amongst the subproject folders
[22:56:13] <blueness> pipacs, every time we talk about kernel in these meetings, its always pax and it slurs across the lines
[22:56:29] <klondike> And moving documents causes big PITAS to amongst other translators
[22:56:45] <blueness> klondike, no not my concern at all
[22:56:59] <klondike> Cool then, you got my meh! :P
[22:57:23] <blueness> the division between the hardened-kernel subproject and pax/grsec is artificial despite the userland spillage
[22:58:06] <blueness> i'll email a proposal to hardened-dev@
[22:58:19] <blueness> i think no pages moved, just the main page with coallesced points
[22:59:06] <blueness> even if we just put 2.0 Kernel + 3.0 Pax/Grsec in our meetings it will work better so that the one can lead into the other :)
[22:59:28] <blueness> today we talked about pax under kernel and pax gain under pax/grsec, with selinux in the middle
[22:59:41] <blueness> see my point about organic linkage between the two subprojects
[22:59:50] <blueness> <end-o-rant>
[22:59:53] <blueness> :)
[22:59:56] <Zorry> will merge them in next meeting
[23:00:01] <blueness> yeah okay
[23:00:27] <blueness> next!
[23:01:09] <Zorry> 10.0 Open floor
[23:01:15] <klondike> FOSDEM mail sent
[23:01:16] <Zorry> any one?
[23:01:30] <Zorry> else is the meeting done
[23:01:44] <Zorry> ty all for the meeting
