[gentoo-hardened] Meeting 2011-12-14 20:00UTC log

[Magnus Granberg <zorry@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 45 bytes --]

Hi
Here is the meeting log.

/Magnus (Zorry)

[-- Attachment #2: meeting-2011-12-14_20:00UTC.log --]
[-- Type: text/x-log, Size: 30593 bytes --]

[21:05:15] <Zorry> 1.0 toolchain
[21:05:21] <klondike> Pong
[21:06:17] <Zorry> we hit a bug with binutils 2.22 and the crtbeginTS support bug 391899
[21:06:20] <willikins> Zorry: https://bugs.gentoo.org/391899 "sys-devel/binutils-2.22: static bins segfault after __libc_csu_init on hardened"; Gentoo Linux, Core system; RESO, FIXE; beber:hardened
[21:07:14] <Zorry> and ended up to change stuff in the piepatch to bug 393321
[21:07:16] <willikins> Zorry: https://bugs.gentoo.org/393321 "sys-devel/gcc: rename crtbeginTS.o: rename to crtbeginP.o"; Gentoo Linux, Core system; RESO, FIXE; vapier:hardened
[21:07:53] <Zorry> all the stuff have with static files to do
[21:09:17] <Zorry> on gclibc upgrade from 2.12 to 2.13 some user hit this bug 394453
[21:09:21] <willikins> Zorry: https://bugs.gentoo.org/394453 "egrep: relocation error: egrep: symbol __guard, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference"; Gentoo Linux, Library; RESO, WORK; morlix:toolchain
[21:09:30] <Zorry> glibc*
[21:09:56] <Zorry> __guard is from old gcc 3.* ssp stuff
[21:10:01] <blueness> Zorry, i didn't undertand that bug, __guard is the old ssp, why did it show up?
[21:10:12] <blueness> *collision*
[21:10:35] <Zorry> blueness: bad updates of the user
[21:10:45] <blueness> oh upgrade path
[21:10:54] <Zorry> so the symbol was still left in the system
[21:11:00] <blueness> yeah
[21:12:37] <Zorry> working on the piepatchset for gcc-4.7  need some patchses to get upstream (the specs -D/-U thing)
[21:13:06] <Zorry> addding some more checks in configure
[21:13:30] <Zorry> else it will be a bump of the 0.5.0 piepatchset
[21:13:52] <Zorry> need to test the x32 support to
[21:14:09] <Zorry> done
[21:14:24] <Zorry> any one else?
[21:14:44] <blueness> nope, all good
[21:15:04] <Zorry> next then
[21:15:08] <Zorry> 2.0 kernel
[21:15:21] <prometheanfire> I'll start
[21:16:23] <blueness> (i'll talk about XT_PAX in 4.0 Pax/Grsec)
[21:16:23] <prometheanfire> kvm running on a uderef host seems to work well, I am testing for performance right now, but I am seeing near native as far as I've seen thus far
[21:16:51] <prometheanfire> here are my results on two seperate hosts (all I've tested thus far) http://dpaste.com/673435/plain/
[21:17:32] <blueness> prometheanfire, hardened guest?  hardened host? both?
[21:17:36] <prometheanfire> If everything seems like it performs well enough I suggest we get rid of hiding uderef in the virtualization profile in the kernel
[21:18:05] <prometheanfire> blueness: kernel definitions are for host, times are for kernel compiles of guests
[21:18:43] <blueness> prometheanfire, okay tell me what version of the kernel i should start and i'll reenable uderef
[21:18:44] <prometheanfire> and make a note that uderef interferes with kvm if you do not have nested pages
[21:19:02] <prometheanfire> blueness: not yet, I want better numbers first
[21:19:05] <blueness> k
[21:19:22] <SwifT> prometheanfire: I might be wrong here, but isn't that a 10% overhead?
[21:19:26] <blueness> prometheanfire, i'll wait for you to pass stuff to me then, next kernel will still have uderef off in VIRTUALIZATION
[21:19:39] <SwifT> user code: 733 seconds vs 666 seconds
[21:19:42] <prometheanfire> SwifT: diferent host CPUs too
[21:19:50] <SwifT> ah, k
[21:19:55] <klondike> prometheanfire: AMD or Intel?
[21:19:57] -*- blueness smacks SwifT around!  10% vs 1000% before!
[21:20:08] <SwifT> oh, didn't realise it was that bad before ;)
[21:20:14] <blueness> SwifT, impossibly bad
[21:20:16] <prometheanfire> both intel
[21:20:52] <klondike> MARRY ME!
[21:21:08] <prometheanfire> I'm going to be using a non-uderef enabled kernel on the host and get times so that they compare better
[21:21:24] <prometheanfire> top was an i7 920, bottom an i5-2520
[21:21:35] -*- klondike will try with his Zacate and try poking imobilis to turn the Campus Party system on
[21:22:06] <prometheanfire> I'm done
[21:22:33] <blueness> prometheanfire, when you're finish experimenting, pass on to me all the necessary data
[21:22:40] <prometheanfire> blueness: yessir
[21:22:44] <blueness> and i'll make the change
[21:22:53] <blueness> i can also test on amd if you can't
[21:23:04] <prometheanfire> I cannot
[21:23:07] <blueness> one of the biggest problems i had with this work was that there were too many variables
[21:23:17] <quantumsummers|c> blueness: what family cpu on amd?
[21:23:24] <blueness> opteron
[21:23:38] <quantumsummers|c> I have a few and would love to test this. I meant, like amdfam10 , etc
[21:23:45] <blueness> model name        : AMD Opteron(tm) Processor 6134
[21:23:45] <quantumsummers|c> what series opty/
[21:23:48] <quantumsummers|c> gotcha
[21:23:59] <quantumsummers|c> btw, amdfam10 works well on those
[21:24:02] <quantumsummers|c> for cflag
[21:24:06] <prometheanfire> all you need to do is test something cpu intesnive on a kvm guest with the host enabling and disbling uderef
[21:24:07] <blueness> quantumsummers|c, i would very much appreciated it if you could test because it would take time for me
[21:24:14] <prometheanfire> the host has to have nested page support though
[21:24:21] <blueness> prometheanfire, these do
[21:24:22] <quantumsummers|c> no prob, I have a dev machine right next to me
[21:24:27] <prometheanfire> kk
[21:24:38] <blueness> prometheanfire, wait, does this not work if nested page support is not available?
[21:24:42] <quantumsummers|c> prometheanfire: can you provide the config options that are required?
[21:24:53] <klondike> Guys, what if we go for the Spec benchmarks as a test?
[21:24:54] <Bunta> and if you could blog the results or something ... could prove very useful! ^^
[21:25:19] <prometheanfire> blueness: it does not work if nested page support is not available
[21:25:25] -*- klondike may be able to get a package ready for running them
[21:25:36] <blueness> prometheanfire, then i will unhide uderef but set it to off
[21:25:51] <blueness> the user will have to turn it on and we should document this <- klondike okay?
[21:25:52] <prometheanfire> blueness: not yet though :P
[21:26:00] <blueness> right
[21:26:02] <blueness> not yet
[21:26:04] <quantumsummers|c> prometheanfire: what is the CONFIG_ name for nested page?
[21:26:05] <klondike> blueness: no problem will document it
[21:26:14] <prometheanfire> no config name
[21:26:17] <prometheanfire> it's a cpu feature
[21:26:18] <blueness> quantumsummers|c, nested pages is a cpu
[21:26:20] <blueness> thingy
[21:26:33] <blueness> its part of the MMU
[21:26:35] <quantumsummers|c> what is the flag name
[21:26:49] <prometheanfire> svm or ept
[21:26:51] <blueness> good question, is there a flag name for it?
[21:26:58] <prometheanfire> ^^
[21:27:11] <blueness> svm is amd and ept is intel?
[21:27:18] <quantumsummers|c> ok, amd uses svm
[21:27:30] <prometheanfire> yep
[21:27:31] <quantumsummers|c> I have it on a Phenom II
[21:27:57] <quantumsummers|c> and on Opty 6172
[21:28:10] <blueness> the opterons have it
[21:28:21] <quantumsummers|c> and on opty 2380
[21:28:24] <blueness> okay move on (for time sake?)
[21:28:46] <prometheanfire> yes
[21:28:57] <klondike> I don't have it on my core 2 :(
[21:29:34] <blueness> other news in kernel (not XT_PAX which I'll discuss later), there may be a bug in slub for some recent kernels, but i haven't verified
[21:29:47] <blueness> if/when i do, i'll remove those from the tree
[21:30:16] <blueness> other than that, i have not had too many new bugs with the kernel, some boo boo's by spender, but stuff that was caught quickly
[21:30:34] <blueness> there was a problem with 3.0.9 insmod, the kernel would freeze when inserting a module
[21:30:46] <blueness> but we caught it within 1 day and no one submitted a bug
[21:30:59] <blueness> also, there is a new kernel feature for PaX
[21:31:12] <blueness> it will be related to the gcc plugin to constify kernel pointers
[21:31:36] <lejonet> quantumsummers|c: svm is the AMD-v, aka hardware virtualization flag for AMD iirc
[21:31:42] <blueness> users will need to know about it because they'll ahve to choose between two methods
[21:31:48] <quantumsummers|c> lejonet: gotcha
[21:32:01] <blueness> 1) BTS which works only for modules with source code
[21:32:12] <blueness> 2) OR which works for modules which have binary blobs
[21:32:22] <quantumsummers|c> trade-offs?
[21:32:25] <blueness> that is new as of the latest 3.1.4
[21:32:35] <blueness> quantumsummers|c, that's what i have yet to get familiar with
[21:32:40] <prometheanfire> quantumsummers|c, blueness: the cpu flag on amd for nested pages is 'rvi'
[21:32:41] <quantumsummers|c> I see
[21:32:50] <blueness> pipacs introduced it about 1 week ago
[21:33:09] <blueness> i knew it was coming but no other details, so i'll have to see what we should do about it for our users
[21:33:38] <blueness> that's about it for just kernel stuff ... XT_PAX later
[21:33:50] <blueness> i'm done unless there are questons
[21:34:08] <klondike> I have one
[21:34:24] <blueness> shoot
[21:34:31] <klondike> What will happen regarding UDEREF on CPUs requiring MMU emulation?
[21:34:48] <klondike> Aka those without nested pages
[21:34:52] <prometheanfire> the default should stay disabled
[21:34:58] <blueness> yep
[21:35:16] <blueness> right now if you choose VIRTUALIZATION, it will force UDEREF off and hide it from the user
[21:35:33] <klondike> That's not my point
[21:35:39] <blueness> oh?
[21:35:56] <klondike> my question is, should we hope for a silver bullet still or pipacs has left it aside?
[21:35:56] <blueness> i'm not sure i understand then
[21:36:17] <blueness> oh, take the conservative approach
[21:36:30] <blueness> this will probably be long lasting problem
[21:36:51] <prometheanfire> I think that pipacs has mostly set aside the uderef slowness for kvm now that it is semi fixed, could be wrong though
[21:37:12] <klondike> So we'll have the problem roaming around for now, I see
[21:37:16] <klondike> Thanks :D
[21:37:52] <Zorry> next then?
[21:37:55] <prometheanfire> I supose I could also mention my experience with uefi
[21:37:56] <blueness> np, anything else?
[21:38:11] <prometheanfire> uefi was not working with PAX at all
[21:38:12] <blueness> prometheanfire, yes actually do
[21:38:32] <blueness> what does that mean?
[21:38:51] <blueness> you have to turn off all pax protection, or it will not work with a pax patched kernel?
[21:38:57] <prometheanfire> now it is, with one caveat, some mem is rwx
[21:39:08] <prometheanfire> it would not work at all with a pax patched kernel
[21:39:10] <blueness> so paxctl -m
[21:39:26] <blueness> prometheanfire, what violations do you get in dmesg?
[21:39:47] <prometheanfire> some mem is marked rwx at boot and left that way by the kernel
[21:39:59] <prometheanfire> the kernel works (I am using it now)
[21:40:07] <prometheanfire> no dmesg badness
[21:41:14] <prometheanfire> the problem is that efi needs it rwx for a time (the efi dev said), I could not get him to confirm if the behavior of keeping it rwx was needed
[21:41:31] <blueness> prometheanfire, let us know if you make any headway, but i would appreciate if you wrote up a quick howto on what you did so i can try to reproduce with our efi boxes here
[21:41:45] <prometheanfire> are they uefi or plain efi?
[21:41:54] <blueness> plain efi
[21:42:01] <prometheanfire> dunno if it would be the same then
[21:42:18] <prometheanfire> I'll discuss it with you after the meeting
[21:42:21] <prometheanfire> done
[21:42:23] <blueness> k
[21:42:52] <blueness> next?
[21:43:01] <Zorry> 3.0 selinux
[21:43:18] <SwifT> my queue ;-)  policy updates are, as usual, coming in. rev 8 is in hardened-dev overlay, I'll push that one to the main tree when I stabilize rev 6 (tomorrow or friday). There is also some ebuild cleanup done, just to make sure it doesn't become too ugly
[21:43:40] <SwifT> Anarchy found the issue of a regression we have with newrole
[21:44:14] <SwifT> as weird as it sounds, if newrole is setuid root, it doesn't properly source stuff in (like /ec/profile), but if you drop the setuid, it works well (and it uses capabilities to do its workings)
[21:44:24] <SwifT> so just remove the setuid bit and you're all set
[21:44:52] <SwifT> I'm going to implement that in a next policycoreutils bump, just waiting a bit for bug #393401 as that might too require some change there
[21:44:55] <willikins> SwifT: https://bugs.gentoo.org/393401 "net-misc/openssh: uid for SSHD causes shell problems for SELinux newrole"; Gentoo Linux, Core system; UNCO; pdd:selinux
[21:45:06] <SwifT> but if that bugs stays behind too much, I'll bump it regardless
[21:45:38] <SwifT> furthermore, sudo (in portage, ~arch) now supports selinux natively, meaning you can add ROLE= and TYPE= information in /etc/sudoers as well as use sudo -r <role> -t <type> if needed
[21:46:08] <SwifT> I'm also slowly but surely adding the proper DEPEND lines on main tree packages to depend on the proper sec-policy/selinux-* stuff
[21:46:29] <SwifT> of those developers that reacted, they all said "just do it yourself yo lazy bum" (but somewhat more professionally ;-)
[21:46:43] <Zorry> :)
[21:47:08] <SwifT> I also think I found the cause of bug #377203, whch might require a very small update on openssh code. It's registered in the upstream bugzilla and I'll see if it is correct or not
[21:47:10] <willikins> SwifT: https://bugs.gentoo.org/377203 "sshd segfaults in glibc when operating in kernel_t SELinux context"; Gentoo Linux, Unspecified; CONF; shiningarcanine:swift
[21:47:29] <SwifT> however, it's a very minor issue, only occurs if you run with selinux, in permissive mode, and with totally wrong labels on your system
[21:48:01] <SwifT> that's about it for selinux from my side (others is profiles and doc)
[21:48:38] <Zorry> any one else?
[21:49:00] <Zorry> k
[21:49:16] <Zorry> 4.0 Pax/Grsec
[21:49:24] <blueness> k
[21:49:26] <blueness> two items
[21:49:57] <blueness> 1) XT_PAX - i built a test system which removed EI_PAX and PT_PAX markings from all elf binaries and only put pax markings in xattrs
[21:50:05] <blueness> the howto is here -> http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=blob;f=HOWTO.txt;h=9edc600f0d81d5e77c6cd7e961a05b56f51b51ec;hb=4e9ef12a7985007118030c407f14d4e33ddefcb6
[21:50:23] <blueness> actually two test systems x86 and amd6
[21:50:25] <blueness> 64
[21:50:30] <blueness> prometheanfire, helped test too
[21:50:39] <blueness> it works but there are issue to be ironed out
[21:50:56] <blueness> a) pipacs is currently looking at the code and will include it soon in the kernel
[21:51:40] <blueness> b) there is a userlan utility paxctl-ng which set the flags, but its still unclear if we'll use it or some patch against pipacs's paxctl, he has 0.6.0 but has not released it yet
[21:52:18] <blueness> c) the package management system will need some xattr support in copying from $D to $ROOT during qmerge phase
[21:52:45] <blueness> the pms people are working on that, there are two approaches but they'll get it straight i'm sure
[21:53:10] <blueness> once these are ironed out, we'll have two options for backward compat for marking PT_PAX and XT_PAX
[21:53:18] <blueness> EI_PAX will *finally* be removed forever
[21:53:27] <blueness> done with issue 1, any questions?
[21:53:43] <Zorry> nope
[21:54:09] <blueness> i know i've said this before and i'm repeating myself but its best to keep communication with everyon
[21:54:10] <blueness> e
[21:54:46] <blueness> 2) revdep-pax - i'm working on making it more user friendly.  it basically migrates pax markings from libraries to the binaries that link against them
[21:55:24] <blueness> so far there are two issues that i still haven't worked out
[21:55:53] <blueness> a) what constitutes the set of binaries?  and what constitutes the set of libraries
[21:56:20] <klondike> blueness: you could look for the main symbol :PO
[21:56:28] <prometheanfire> ya, stuff under opt would get missed a lot of the time
[21:56:37] <prometheanfire> if done via path
[21:57:04] <blueness> klondike, prometheanfire i'm afraid that if i just look at everything under /lib /lib64 etc or /bin /sbin i'll be opening up security holes
[21:57:21] <blueness> so for that reason i want to just use the stuff that portage knows about
[21:57:36] <blueness> ie the stuff in /var/db/pkg
[21:57:46] <blueness> but there still more
[21:58:00] <klondike> Well we can have two modes
[21:58:04] <klondike> Portage mode
[21:58:07] <klondike> And manual mode
[21:58:18] <blueness> b) i can follow the DT_NEEDED chain, ie libraries that link against libraries etc, but i can't do much about dlopen()
[21:58:22] <klondike> with manual mode we check the dir passed as argument for elf files
[21:58:23] <blueness> klondike, not a bad idea
[21:58:34] <blueness> yeah, i can think along those lines
[21:58:36] <klondike> Then ask user for confirmation
[21:58:57] <blueness> the problem is, no matter what, linkage system wide is messy
[21:59:02] <klondike> Regarding dlopen we can do little, it is magic :P
[21:59:11] <blueness> indeed
[21:59:35] <blueness> so i'll keep tidying it up, but i think some messiness will remain and we'll just have to document the "gotchas"
[21:59:41] <blueness> like /opt
[21:59:48] <blueness> like dlopen'ed libraries
[22:00:24] <blueness> finally, on a more practical note, i tested it against libGL.so.1 and its working, i just have to add libexec to the path in the next bump
[22:00:47] <blueness> ie to the $PATH where executables are assumed to live
[22:01:13] <blueness> any questions? comments? criticisms?
[22:01:45] <Zorry> have kde 4.7.4 runing with mesa and llvm stuff :)
[22:02:04] <blueness> Zorry,  did you use revdep-pax?
[22:02:13] <Zorry> yes
[22:02:31] <blueness> the -e flag was a good idea, to just mark the executables rather than following the entire DT_NEEDED chain
[22:02:42] <Zorry> yep
[22:02:59] <blueness> but it is a little dangerous because if an exe links against a library which links against libGL.so.1, it will be missed
[22:03:05] <blueness> only directly links are caught that way
[22:03:26] <blueness> to be complete, you must go through all the libraries, and there are hundreds!
[22:03:41] <blueness> okay i'm done
[22:03:59] <Zorry> yep u still need to look in the logs if you still miss something
[22:04:42] <Zorry> revdep-pax fix most thing
[22:04:50] <Zorry> done
[22:05:02] <Zorry> any one else?
[22:05:27] <Zorry> 5.0 Profiles
[22:05:50] <Zorry> SwifT blueness ^^
[22:05:53] <SwifT> okay
[22:06:12] <SwifT> well, the old v2refpolicy selinux profiles have been (finally) deprecated, so now we only use the newer, easier to maintain ones
[22:06:36] <SwifT> we started off with just the hardened/*/selinux ones, but we had at least one user (probably more ;-) that want to use selinux for vanilla profiles
[22:06:51] <SwifT> so we now also have the default/linux/*/selinux ones for x86 and amd64
[22:07:20] <SwifT> we didn't have any issues with having those profiles in too
[22:07:37] <SwifT> the documentation has also been updated to reflect this
[22:07:53] <SwifT> unless I forgot something, that's about it. blueness ?
[22:07:54] <prometheanfire> but not no-multilib yet (so cannot test)
[22:07:58] <schmitt953> sorry just joined in SwifT, I'm curious which documentation is updated?
[22:08:27] <SwifT> schmitt953: the gentoo hardened selinux documentation, to include information on using the "defult/linux/*/selinux" profiles
[22:08:39] <SwifT> prometheanfire: no no-multilib for non-hardened, no
[22:08:56] <blueness> nah its that simple :)
[22:09:09] -*- blueness was busy making a commit ... 
[22:09:09] <prometheanfire> oh wait, I'm on hardened, that's right
[22:09:17] <SwifT> blueness: work-a-holic
[22:09:28] <blueness> SwifT, that' syou!
[22:10:25] <blueness> SwifT,  Zorry et al. the only think i'm not clear on policy wise is at what point after marking profile deprecated can you just remove it from the tree
[22:10:32] <schmitt953> if you're updating I have a few suggestions about what to add
[22:10:34] <schmitt953> if you want them
[22:10:35] <blueness> eg. we just removed the old old old hardened/arch profiles
[22:10:55] <SwifT> schmitt953: sure, but wait a bit until after the online meeting ;)
[22:11:01] <schmitt953> ok
[22:11:18] <blueness> schmitt953, yep contribution much appreciated
[22:11:28] -*- blueness has a dog that can't wait till this meeting is finished!
[22:11:34] <SwifT> blueness: well, there are people that wait quite some time before --sync'ing (which is bad, but still happens). I'd wager at least a year before removing it
[22:11:47] <Zorry> +1
[22:11:48] <klondike> blueness: need the dog to commit his necessities?
[22:12:05] <SwifT> klondike: if you want to help him finish the meeting in time, keep it on-topic :p
[22:12:09] <blueness> SwifT, good point, there's some rule about being able to update from 1 year back
[22:12:28] <SwifT> there is? hmm.. mine was just based on the feedback I have frmo #gentoo ;-)
[22:12:52] <blueness> SwifT, i don't know i just remember seeing it discussed in some context
[22:12:58] <klondike> SwifT: we can always ask on -dev for feedback regarding removing deprecated profiles, can't we?
[22:13:08] <blueness> but i cannot remember, although syncing bakc 1 year is risky
[22:13:32] <SwifT> klondike: well, right now is too soon, so the answer that gentoo-dev would give, we'll forget anyhow
[22:13:38] <blueness> there's no way to guarantee that level of coherence between hundreds of devs all doing their own thing
[22:13:46] <SwifT> klondike: better to ask in a few months (or so) and see if they agree to remove it ;)
[22:14:10] -*- SwifT tends to download one portage snapshot every 3 months in case users have problems ;)
[22:14:16] <blueness> klondike, there is not central point for discussing it with all users except via news
[22:14:22] <blueness> s/not/no
[22:14:34] <blueness> and there's little feedback in news
[22:15:03] <klondike> blueness: that's why I targeted -dev but well after all you are the profile experts
[22:16:27] <klondike> Anyway I agree with SwifT we should psuh this later unless we aim to remove the old hardened profiles too
[22:17:43] <Zorry> any one else ? next then
[22:17:54] <Zorry> 6.0 Docs
[22:18:16] <SwifT> i have some about selinux docs
[22:18:38] <SwifT> I pushed out the selinux bugreporting guide with some basic best practices when you report issues with selinux policyes
[22:18:43] <SwifT>         http://www.gentoo.org/proj/en/hardened/selinux-bugreporting.xml
[22:19:19] <SwifT> other documents on selinux have been updated as well, like the SELinux FAQ (information about run_init & authentication as well as the impact of having nosuid mount partitions with SELinux)
[22:20:02] <SwifT> finally, I'll start linking the SELinux module specific documents. These documents contain use information for specific modules (like cron, portage, ...) such as which file contexts to use, which booleans there are, etc.
[22:20:21] <SwifT> this also allows us to document stuff that we cannot (or will not) modify in the policy but still might want to tell the users
[22:20:27] <SwifT> like what happened on bug #392699
[22:20:30] <willikins> SwifT: https://bugs.gentoo.org/392699 "sec-policy/selinux-logwatch lacks permission to read root home area"; Gentoo Linux, Hardened; IN_P; stsander:swift
[22:20:47] <SwifT> list of currently documented modules:         http://www.gentoo.org/proj/en/hardened/selinux/modules/index.xml
[22:21:09] <SwifT> also the SELinux development guide (on how to update policies, create patches) has been updated a bit to reflect recent developments
[22:21:24] <SwifT> that's it about docs for selinux
[22:21:34] <Zorry> k
[22:21:37] <klondike> ^
[22:21:50] <klondike> Well regarding other docs
[22:22:10] <klondike> I'm still very busy with my end of Career project
[22:22:23] <klondike> So I try to snap a little time from where I can
[22:22:33] <klondike> I gave a talk on Gentoo Hardened on Murcia
[22:22:58] <klondike> And users seemed very interested on the idea of a more user-friendly Gentoo Hardened
[22:23:25] <klondike> I'll upload the updated slides including info on gcc plugins to the project page when I get some minutes
[22:23:46] <klondike> Little more, if anybody wants to help with docs please poke me, I don't mind teaching GuideXML
[22:24:39] <SwifT> if you like wiki's, use wiki.gentoo.org and then ask klondike or me for help in converting guidexml when needed ;)
[22:24:55] <klondike> Yep, the wiki is cool :P
[22:25:07] <klondike> And converting a doc is way less work than creating a new one
[22:25:18] <blueness> whoah!  i didn't even know we had one -> Welcome to the official Gentoo Wiki!
[22:25:22] <blueness> official!
[22:25:39] <klondike> blueness: they sent an announcement
[22:25:53] <blueness> i don't read docs, i just hack the stuff till it works and then commit the changes :P
[22:26:12] <klondike> yeah that's what I have to do WRT my project now U_U
[22:26:13] <SwifT> it's very nice... haven't taken the time to contribute much there, but the wiki guys did a very smooth job
[22:26:39] <klondike> I gave some fixes to the Gentoo Hardened page but little more
[22:27:18] <blueness> you guys are the doc guys, i don't know if you want to maintain two sets of documentations though
[22:27:33] <blueness> the xml and the wiki stuff, might be extra work duplicating
[22:28:01] <SwifT> maintain, not really... I do most of my documentation development offline so wiki is a big nono for me
[22:28:02] <klondike> Well to me wiki looks better than even our git overlay
[22:28:09] <SwifT> but there are many people that contribute perfect documents on wiki's
[22:28:22] <klondike> That too
[22:28:33] <SwifT> having them both is nice... but let wiki live its (contributers) life, I'll keep the .xml ones up to date
[22:28:36] <klondike> And wikis are more user firnedly than GuideXML
[22:28:55] <blueness> the incremental nature of wikis makes it easy
[22:29:13] <klondike> Well that's all by me
[22:29:17] <blueness> i would contribute more to a wiki because if i make some change that needs documentaiton, its just a few lines in a wiki usually
[22:30:16] <Zorry> next ?
[22:30:24] <klondike> yup
[22:30:35] <blueness> yes
[22:30:35] <Zorry> 7.0 bugs
[22:31:27] <Zorry> any one ?
[22:31:40] <blueness> Zorry, i'm not sure we didn't discuss the bugs in the context of each section
[22:31:50] <blueness> so i think we covered them
[22:32:03] <SwifT> yup, no bugs here to discuss
[22:32:13] <Zorry> k next then
[22:32:14] <blueness> i have no *big ones* that need the attention of the community
[22:32:49] <Zorry> 8.0 Media
[22:32:56] <klondike> Yay
[22:33:02] <klondike> I made the identi.ca account
[22:33:13] * klondike has changed topic for #gentoo-hardened to: "http://www.gentoo.org/proj/en/hardened/index.xml | Newer stages http://www.jmbsvicetto.name | Use hardened/linux/${arch} profiles | GCC-4.5.3 stable with SSP/PIE support enabled | Latest stable hardened-sources 2.6.32-r68 and 3.0.4-r5 | Twitter/identi.ca @GentooHardened | Meeting 2011-12-14 20:00UTC Agenda http://pastebin.com/AJANa3K7"
[22:33:22] <klondike> So we are expanding slowly :P
[22:33:29] <klondike> Let's see what happens with this onee
[22:33:42] <klondike> Also the talk propossal for Fosdem got rejected
[22:33:47] <SwifT> :(
[22:33:48] <Zorry> :(
[22:33:56] <klondike> if we want to send any one still we should talk with track organizers
[22:34:05] <Zorry> k
[22:34:18] <klondike> so i'd like to know
[22:34:24] <klondike> which track should we aim for?
[22:34:34] <SwifT> that or we hijack one... :p
[22:35:06] <klondike> Tsk don't say it loud or they will discover why there was an ill ponent at FSCONS :P
[22:35:30] <blueness> klondike, what did you propose?
[22:35:47] <klondike> blueness I propossed a talk explaining how hardened features work
[22:35:58] <klondike> but I did that maybe on the inappropriate part
[22:36:00] <blueness> did they give a reason why it was rejected?
[22:36:04] <klondike> nope
[22:36:23] <blueness> we should look at accepted proposals as models
[22:36:24] <klondike> But I suppose that the deadline for main track talks passing might be a reason
[22:36:42] <blueness> email me the name of some contact at FOSEM if you have one
[22:36:55] <blueness> FOSDEM
[22:37:19] <klondike> blueness: I don't
[22:37:21] <blueness> the trick to getting a paper published, or an article accepted, etc is to look at what has been accepted in the past
[22:37:30] <klondike> not one that I know :/
[22:37:43] <klondike> But we could poke the people who gave talks on Gentoo last year
[22:37:47] <blueness> klondike, well someone in the gentoo community has so we could bug them
[22:37:53] <klondike> jmbsvicetto: NeddySeagoon ping
[22:38:00] <blueness> mid air!
[22:38:16] <klondike> Well this is mostly all regarding media
[22:39:03] <blueness> when does FOSDEM run anyhow?
[22:40:06] <NeddySeagoon> klondike, pong
[22:40:13] <Zorry>  3-5 feb i think
[22:40:23] <NeddySeagoon> first weekend in Feb
[22:40:24] <klondike> NeddySeagoon: do you happen to know how can we get a talk into Fosdem?
[22:40:36] <prometheanfire> 51 days until FOSDEM.
[22:40:56] <NeddySeagoon> klondike, apply for one if its not already too late - look on the fosdem.org website
[22:41:00] <blueness> NeddySeagoon, more specifically do you have some model proposal that we could look at
[22:41:53] <klondike> Anyway for the sake of blueness' and Zorry's dogs can we move to Open Floor?
[22:42:18] <blueness> lol yeah, he's going nuts right now!
[22:42:34] <Zorry> 9.0 Open floor then
[22:42:37] <NeddySeagoon> blueness, Jorge did the one last year I think.  It may have been Betelgeuse.
[22:42:59] <klondike> Well congrats ago on being a new dev
[22:43:19] <SwifT> yup! freshmeat(.net) !
[22:43:34] <klondike> LOL
[22:43:44] <klondike> prometheanfire: keeping up with traditions :P
[22:43:46] <prometheanfire> :D
[22:43:54] <NeddySeagoon> I won't make FODSEM this year - I have to go to the USA in January  :(    I will miss SCALE too as I'll be in Florida
[22:44:00] <blueness> he's not here otherwise we could kick him :)
[22:44:21] <klondike> prometheanfire: kicked him first :P
[22:44:28] <klondike> Well I need to leave now
[22:44:29] <blueness> haha
[22:44:42] <klondike> I'll try to get a doc on revdep-pax as soon as I can
[22:44:44] <klondike> cya
[22:44:47] <Zorry> ty for the meeting
[22:44:59] <blueness> done?
[22:45:00] <klondike> ty for being such a cool lead Zorry :D
[22:45:05] <Zorry> meeting done
[22:45:10] <Zorry> :)
[22:45:11] <SwifT> if it's the end of the meeting, just want to say thank you all; great work on getting gentoo hardened in the shape it is (and will be ;-)