[gentoo-hardened] Meeting log 2011-11-17 20:00UTC

[gentoo-hardened] Meeting log 2011-11-17 20:00UTC

[Magnus Granberg]

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

Hi

Here is the meeting log form the meeting 2011-11-17 20:00UTC

/Magnus

[-- Attachment #2: meeting-2011-11-17_20:00UTC.log --]
[-- Type: text/x-log, Size: 27671 bytes --]

[21:07:26] <Zorry> 1.0 Update on revdep-pax and xattr extension for pax flags.
[21:07:30] <Zorry> blueness: ^^
[21:07:34] <blueness> k
[21:07:58] <blueness> 1) revdep-pax = tool to find mismatching pax flags between libraries and binaries
[21:08:11] <blueness> i have had no feedback on testing
[21:08:18] <blueness> but we needed it for the ati driver
[21:08:48] <blueness> we should find someone who has one and ask them to see if it fixes the problem, but who?
[21:08:55] <Zorry> mesa, nvida to
[21:09:03] <blueness> ah good!
[21:09:04] <blueness> i can do that
[21:09:36] <blueness> Zorry,  is there any howto for mesa/nvidia or no?
[21:09:59] <blueness> figure it out from scratch?  (i used to use nv and now nouveau, never tried nvidia)
[21:10:13] <blueness> i'll google
[21:10:37] <Zorry> nvidia need some fix and mark -m on the opengl lib
[21:10:59] <blueness> so use revdep-pax on the opengl lib and see if it fixes things?
[21:11:15] <quantumsummers|a> glad you made it blueness
[21:11:25] <blueness> okay i can do that, that's all i had to say on that
[21:11:26] <quantumsummers|a> SwifT: because I was having fun :P
[21:11:32] <blueness> 2) xattr flags
[21:11:49] <Zorry> on mesa is only the gallium stuff on some  ati card that need -m on the opengl lib
[21:11:58] <Aleister> for now
[21:12:11] <blueness> i now have a userland utility and kernel patch for pax markings using extended attributes rather than elf program headers
[21:12:29] <blueness> i've tested it and it works, but i'm not sure how to make this available to "daring users" to test?
[21:12:54] <blueness> what do you think, make a hardened-dev-sources on my overlay?  and write a little howto?
[21:13:02] <blueness> pipacs is reviewing the approach now
[21:13:23] <SwifT> blueness: can't the patch be included optionally rather than using a different sources package?
[21:13:32] <SwifT> blueness: and yes, having a little howto is definitely worth it
[21:13:41] <Zorry> blueness: we can put it on the testing branch on the hardened-dev ovarlay ?
[21:13:50] <blueness> SwifT, it can but my guess is that pipacs will change things
[21:14:00] <blueness> in particular, we're not sure what xattr namespace to use
[21:14:19] <SwifT> what do you use currently? "security.pax" ?
[21:14:19] <blueness> Zorry, yes!  on the hardened-dev overlay is better, i forgot all about that!
[21:14:43] <blueness> SwifT, no we first chose user.pax so a reguarl user can pax mark
[21:15:29] <blueness> but pipacs thinks he might add an additional patch to security. namespace to allow setxattr there for .pax
[21:15:36] <blueness> my patch is for user.pax only
[21:15:41] <Zorry> k
[21:15:52] <blueness> anyhow, i think i'll follow Zorry's idea.
[21:16:01] <blueness> i'll put the stuff on the overlay
[21:16:13] <blueness> where should i publish the howto?
[21:16:39] <SwifT> blueness: first focus on writing it; I think it's best to put it in the hardened-docs overlay for now
[21:16:46] <Zorry> but way should user be allowd to set the xattre stuff?
[21:16:51] <blueness> k
[21:16:52] <SwifT> we can then convert it to guidexml
[21:17:25] <prometheanfire> wiki :D
[21:17:45] <blueness> Zorry, right, but there is an issue with the kernle functions getxattr and setxattr when the userspace is outside of user.
[21:17:49] <SwifT> wiki's good too, but there's a license incompatibility to be worked out (but I'm considering adding support for cc-by-sa-3.0 on guidexml)
[21:17:58] <Zorry> blueness: okay
[21:18:07] <prometheanfire> wiki.gentoo.org has lic issues?
[21:18:08] <blueness> and a user may not be able to run chmod 111 binaries which are security.pax marked
[21:18:20] <SwifT> prometheanfire: it's CC-BY-SA 3.0 and GDP's docs are CC-BY-SA 2.5
[21:18:35] <prometheanfire> ok
[21:18:39] <blueness> okay, i just wanted to update the community about this
[21:18:53] <blueness> i'm done with 1.0 unless you guys have questions
[21:19:04] <Zorry> fine by me
[21:19:21] <Zorry> next then?
[21:19:26] <blueness> yes
[21:19:31] <Zorry> 2.0 Selinux lead
[21:19:37] <Zorry> SwifT: ^^
[21:19:56] <SwifT> yup; a little before our previous irc meeting, PeBenito wanted to step down
[21:20:26] <SwifT> we had a little discussion on selinux@g.o about it and suggested to PeBenito to stay as developer since we definitely can use his massive knowledge, even though we know he's not going to be around much
[21:20:33] <SwifT> SELinux being his day-job too
[21:20:51] <SwifT> the consensus was also that I would take up the "position" as selinux lead
[21:21:19] <SwifT> so... Q to the meeting: is that okay for you guys?
[21:21:27] <prometheanfire> yes
[21:21:33] <Zorry> +1
[21:22:58] <SwifT> blueness: since you're also actively involved, okay for you too?
[21:23:19] <Zorry> SwifT:  he needed to go 
[21:23:24] <SwifT> ah k
[21:23:24] <Zorry> but will be back
[21:23:45] <SwifT> he can /kick me if he doesn't agree ;)
[21:23:50] <Zorry> but i thin he agree
[21:24:15] <SwifT> k then, thx!
[21:24:21] <Zorry> so SwifT is the new selinux lead
[21:25:15] <Zorry> SwifT: update the hardened frontpage then
[21:25:19] <SwifT> will do
[21:25:39] <Zorry> any one else have some ting?
[21:25:42] <Zorry> else next
[21:25:45] <quantumsummers|a> all hail SwifT
[21:25:48] <quantumsummers|a> ;)
[21:25:54] <SwifT> oh hush you :p
[21:26:36] <Zorry> next
[21:27:01] <Zorry> 3.0 Toolchain
[21:27:22] <Zorry> have two bugs to fix in gcc that i working on
[21:27:40] <Zorry> !bug 380823
[21:27:44] <willikins> Zorry: https://bugs.gentoo.org/380823 "sys-devel/gcc-4.6.1[go] fails to build"; Gentoo Linux, GCC Porting; IN_P; oehme.markus:hardened
[21:28:11] <Zorry> will be fixed in next piepatchset bump on gcc 4.6
[21:28:31] <Zorry> but the libgo lib do have RWX mark :(
[21:28:50] <Zorry> and to fix that will be hard to do
[21:29:05] <blueness> SwifT, 1 sec reading backlog
[21:29:17] <Zorry> it have trampolines allover the code
[21:30:18] <blueness> Zorry, does it need paxctl -m during the build?
[21:30:19] <Zorry> so i thinking to mark the libgo with -m later on
[21:30:25] <Zorry> blueness: nope
[21:30:32] <blueness> but after the build yes
[21:30:40] <Zorry> but any bin/lib that use it
[21:30:47] <blueness> right
[21:31:03] <blueness> more work for revdep-pax
[21:31:09] <Zorry> yep
[21:33:05] <Zorry> !bug 361783
[21:33:09] <willikins> Zorry: https://bugs.gentoo.org/361783 "[4.6] spec rules matching preprocessor flags don't work anymore"; Gentoo Linux, Ebuilds; CONF; alexxy:toolchain
[21:33:46] <Zorry> for now we have a hack fix to fix the problem 
[21:34:20] <Zorry> but is not fun to debug the gcc spec deriver
[21:34:28] <Zorry> driver*
[21:34:54] <blueness> Zorry, is this going to be a recurring problem?  because a similar problem happened with 4.5
[21:35:26] <quantumsummers|a> seems that the goal is to get rid of spec files altogether, if I am not mistaken
[21:35:28] <Zorry> blueness: we need to fix the upstream bug (feature)
[21:35:59] <Zorry> quantumsummers|a: wrong
[21:36:14] <quantumsummers|a> oh, they have dropped it and we still need it?
[21:36:31] <blueness> quantumsummers|a, specs are a necessary aprt of gcc
[21:36:46] <blueness> the problem is their interpreter keeps changing
[21:36:49] <quantumsummers|a> what was Ryan saying then, I totally misunderstood
[21:36:57] -*- quantumsummers|a re-reads
[21:37:00] <Zorry> quantumsummers|a:  thay spelited the preprocesed stuff -D* to -D *
[21:37:11] <blueness> right
[21:37:12] <Zorry> and spec cant use that
[21:37:28] <blueness> its the internal parser that gets confused
[21:37:29] <quantumsummers|a> change for sake of change
[21:37:46] <quantumsummers|a> ok then, so that is a bad deal
[21:38:07] <blueness> quantumsummers|a, i don't know what gcc internals are up to, what i've never understood is why that part of the  code wasn't written with lex/yacc
[21:38:25] <prometheanfire> legacy?
[21:38:30] <quantumsummers|a> would make more sense to use parsers like that
[21:38:37] <blueness> if the spec file were parsed by lex/yeacc generated code it would have been easier to deal with
[21:38:49] <quantumsummers|a> yep hmm
[21:38:51] <blueness> anyhow, we're just dreaming
[21:38:58] <Zorry> yep
[21:39:04] <quantumsummers|a> so there is no way to have 4.6 until that stuff is fixed up?
[21:39:18] <quantumsummers|a> which will require untold hours of work I assume
[21:39:23] <Zorry> quantumsummers|a:  4.6 have workaround but 4.7 will not
[21:39:32] <quantumsummers|a> ah ha
[21:39:34] <quantumsummers|a> ok
[21:39:45] <quantumsummers|a> so we have some time to make solution
[21:40:27] <Zorry> but if the fix get accepted upstream it will be ported to 4.6 to
[21:40:36] <quantumsummers|a> cool, yeah that is good
[21:41:15] <quantumsummers|a> so why not use a good parser then? bundling or extra deps are not desired?
[21:41:56] <blueness> quantumsummers|a, i seriously doubt they will make such a radical change, i was just wondering why they hadn't gone in that directrion from the beginning
[21:42:06] <quantumsummers|a> hmm, radical
[21:42:22] <blueness> seeing as flex = gnu lex and bison = gnu yacc, they had the tools
[21:42:24] <Zorry> don't know but i think the code for the spec driver is wary old
[21:42:32] <blueness> yep
[21:42:53] <quantumsummers|a> ah, well perhaps this is a GSOC project in the making
[21:42:53] <blueness> (coincidentally i'm teaching how to write compilers right now)
[21:42:57] <quantumsummers|a> nice
[21:43:04] <blueness> (general theory)
[21:43:05] <prometheanfire> ouch
[21:43:12] <prometheanfire> that's voodoo
[21:43:27] <blueness> quantumsummers|a, no way, seriously, that would probably be a failure
[21:44:00] <blueness> Zorry, what about your pie patch for upstream?  did that go anywhere?
[21:44:40] <Zorry> blueness: did have alot of work on the tinderbox stuff
[21:44:52] <Zorry> so i will try next version
[21:45:01] -*- quantumsummers|a bows out of the parser discussion
[21:45:20] <blueness> okay because that may help with this issue if they keep changing the spec parser
[21:45:42] <Zorry> blueness:  if gcc have a testcase
[21:45:55] <Zorry> it did't have it before so
[21:46:25] <Zorry> so a patch with a fix and testcase
[21:46:31] <blueness> yep
[21:46:46] <Zorry> gcc 4.7 is in stage3 now
[21:47:00] <blueness> k
[21:47:06] <blueness> so shoot for 4.8
[21:47:23] <Zorry> yep
[21:47:48] <Zorry> else i don't have any more on toolchain
[21:48:17] <Zorry> some one else?
[21:48:25] <blueness> okay fo rme
[21:48:38] <SwifT> still trying to parse what I'm reading here, so don't mind me :p
[21:48:54] <Zorry> 4.0 Kernel
[21:48:58] <Zorry> blueness: ^^
[21:49:05] <blueness> yep
[21:49:40] <blueness> just one thing, i've started removing some of the really old stable kernels, going back 1.5 years
[21:49:59] <blueness> i removed 2.6.32-r23 and -24 today
[21:50:20] <blueness> i want to remove 2.6.32-r9 (very old) but i remember people saying they still used it quantumsummers|a?
[21:50:38] <quantumsummers|a> 2.6.32-r9 <- one of the best kernels for a long time
[21:50:45] <blueness> keep it still?
[21:50:47] <quantumsummers|a> yeah, I have some machines on it still
[21:50:51] <blueness> k
[21:51:01] <quantumsummers|a> if you want to drop it I can move it to my internal overlay
[21:51:15] <quantumsummers|a> up to you, I am not deploying it anymore, but just have some still running there
[21:51:28] <quantumsummers|a> 14:51:21 up 372 days
[21:51:42] <blueness> nah, its fine, there was a string of similar kernels, i'll just keep the last of each of the grsec lines
[21:51:54] <quantumsummers|a> thanks a lot sir
[21:51:57] <blueness> ie 2.1.4 (aka 2.6.32-r9)
[21:52:06] <blueness> all grsec-2.2.0 are gone
[21:52:17] <blueness> i'll keep on grsec-2.2.1 and the latest 2.2.2
[21:52:48] <blueness> i don't remember which hardened sources those map to, but they were all very similar with minor bug fixes in between
[21:52:54] <lejonet> quantumsummers|a: You remember that patch I submitted to kernel last week?
[21:53:41] <quantumsummers|a> lejonet: yeah, I recall
[21:54:01] <quantumsummers|a> lejonet: what happened with it?
[21:54:02] <lejonet> Apparently the fix I submitted was reverted in a commit some month ago, but one of the openwrt dudes agreed that something should be done for the non-automatic bus support by default thing but there isn't a clear way of doing that
[21:54:32] <quantumsummers|a> huh, I see
[21:54:42] <lejonet> Because doing it default y affects the kernel size when doing oldconf enough for it to matter apparently
[21:55:00] <lejonet> But there isn't a clear way to set it as optional but enabled by default IF ath9k is chosen
[21:55:20] <Zorry> lejonet: can you take it later?
[21:55:30] <lejonet> Zorry: sure
[21:55:54] <lejonet> right the meeting? Totally forgot, sorry for the interuppt :)
[21:55:54] <Zorry> blueness: did you have more or some one esle?
[21:56:05] <blueness> nothing out of the ordinary
[21:56:09] <Zorry> k
[21:56:23] <Zorry> 5.0 Selinux
[21:56:28] <blueness> there's some bugs i passed to spender on the recent 3.0.9 kernel and 3.1.1
[21:56:41] <blueness> but jus torindary stuff
[21:56:43] <blueness> done
[21:56:46] <Zorry> SwifT prometheanfire ^^
[21:56:54] <SwifT> okay, policy wise, we're right on track. We currently have he latest stable policies from refpolicy as stable and the older policies have been removed from the portage tree
[21:57:06] <SwifT> same goes for the userspace tools that are associated with them
[21:57:29] <SwifT> support for targeted & strict is going nicely, users are getting it up and running (some with more hurdles than others, right prometheanfire ? ;-)
[21:57:54] <SwifT> mcs has little users yet though, mls none afaik
[21:58:00] <prometheanfire> ya, it's been fun
[21:58:15] <SwifT> that doesn't surprise though, mcs is only interesting for selinux-aware applications that enable that multi-tenancy approach
[21:58:24] <SwifT> and mls is too damn difficult to master
[21:58:55] <SwifT> I'm gradually pushing our policy patches upstream; most of them get accepted after a while (coding style updates, lower privilege enhancements, using right booleans, etc.)
[21:59:19] <SwifT> when the patch is accepted upstream, I also update the patch for our policies and keep track of those so that, when upstream releases a new set, I know which patches need to be ported and what not
[21:59:58] <SwifT> I also notice on the forums that more and more people are starting to use SELinux, so that's good news as well
[22:00:39] <SwifT> I'm currently preparing revision 7 for release somewhere next week, and I hope to have the policy updates going on in a frequent approach
[22:00:49] <SwifT> (rev7 = selinux-base-policy)
[22:01:15] <SwifT> that's about it
[22:01:27] <SwifT> (apart from docs & profiles, but that's for later)
[22:02:00] <Zorry> welcome new dev prometheanfire to hardened/selinux
[22:02:26] <SwifT> yup, prometheanfire has quite some experience with server-side stuff which is a major "customer" for SELinux
[22:02:34] <blueness> congrats again prometheanfire !
[22:02:36] <prometheanfire> :D
[22:02:40] <SwifT> for some reason, I get the feeling prometheanfire has been running every service on the planet somewhere in his data centre :p
[22:02:44] -*- prometheanfire was expecting the boot
[22:02:56] <blueness> nah it gets old
[22:03:05] <blueness> and anyhow, you're expecting it :)
[22:03:09] <SwifT> indeed, now we just load you with bugs
[22:03:24] <prometheanfire> heh
[22:03:30] <SwifT> (after you getting your lvm system booted up properly)
[22:03:55] <SwifT> btw, I also added prometheanfire & klondike to the hardened page
[22:04:15] <prometheanfire> ya, I don't run every server software thing, but I try to run every service
[22:05:08] <Zorry> any one else have something?
[22:05:20] <Zorry> then next
[22:05:27] <blueness> yep next
[22:05:30] <Zorry> 6.0 Profiles
[22:05:41] <Zorry> 6.1 Old Selinux profiles
[22:05:46] <Zorry> SwifT: ^^
[22:06:17] <SwifT> okay, we are currently running two selinux profiles next to each other, the old v2refpolicy one, and the newer one that blueness created
[22:06:37] <SwifT> it's been almost half a year, so we might want to consider deprecating the v2refpolicy one?
[22:06:54] <Zorry> +1
[22:07:04] <blueness> yeah let's get rid of them
[22:07:15] <blueness> shall i do the honors?
[22:07:25] <SwifT> sure
[22:07:26] <prometheanfire> you did the work on the new onew
[22:07:26] <blueness> 1) take the out of the profiles.desc
[22:07:33] <SwifT> since you can't boot prometheanfire, boot the old profiles ;)
[22:07:39] <blueness> wait about 1 month
[22:07:44] <blueness> then
[22:07:49] <blueness> 2) remove them altogether
[22:08:05] <SwifT> wasn't there a way to inform users of the old profile about the new ones?
[22:08:08] <blueness> sound slow enough?
[22:08:21] <blueness> oh, should we do a news item?
[22:08:35] <SwifT> no, something like profiles/hardened/linux/ia64/deprecated
[22:08:53] <SwifT> the moment the user runs "emerge --sync", I think he gets that information immediately
[22:08:54] <Zorry> yep put deprecated
[22:08:55] <blueness> actually that's what i meant by "remove them"
[22:08:59] <SwifT> ah k
[22:09:11] <blueness> sorry i didn't mean delete them
[22:09:21] <SwifT> no need for a news item (no immediate action necessary for the user, nothing that would screw up his system)
[22:09:34] <SwifT> having a nice blog post or gentoo.org news item might be interesting (if not just for the PR of it)
[22:09:41] <blueness> the deprecated effectively stops users from using them
[22:10:16] <blueness> SwifT,  how fast between removing them from profiles.desc to add the deprecation warning?
[22:10:35] <SwifT> blueness: I'm okay with the one month period, for me it can be even sooner
[22:10:40] <blueness> k
[22:10:51] <SwifT> people don't generally read profiles.desc so it's the deprecation warning that does it ;)
[22:10:55] <blueness> i'll start the process tonight
[22:11:02] <SwifT> coolness
[22:11:10] <blueness> yeah you know what, you're right
[22:11:21] <blueness> many people won't even do an eselect profile list
[22:11:32] <blueness> so sure, maybe less than a month
[22:12:03] <blueness> next?
[22:12:14] <Zorry> 6.2 Remove all /hardened/arch
[22:12:47] <blueness> they've been in deprecated mode for years
[22:12:54] <blueness> and they cause confusion
[22:12:54] <Zorry> was thinking to remove the old deprecated hardend/arch profiles stuff
[22:13:23] <Zorry> so we clean the profile
[22:13:23] <blueness> +1
[22:13:27] <blueness> yep
[22:14:05] <prometheanfire> we would move under default/linux/amd64/10.0/no-multilib and the like right?
[22:14:20] <prometheanfire> I thought the 10.0 was deprecated also
[22:14:23] <blueness> so to be clear, remove profile/hardened{amd64, ia64, ppc, ppc64, x86}
[22:14:33] <prometheanfire> ah
[22:14:43] <Zorry> prometheanfire: we use hardened/linux/arch now
[22:15:31] <blueness> Zorry,  i don't see any problems with that and i've been thinking of it for a while too
[22:15:35] <Zorry> blueness: i think we can remove some files in the root to
[22:15:36] <prometheanfire> ah, ok, I saw some stuff here earlier and was confused
[22:15:41] <blueness> especially since it causes confusion
[22:16:03] <Zorry> yep
[22:16:34] <blueness> Zorry, which other ones i just looked at them and they look necessary?
[22:18:05] <blueness> Zorry,  i think we can keep the root files and inherit from them because gentoo, as a whole, does support other kernels
[22:18:20] <blueness> so maybe one day there might be a hardened/freebsd
[22:18:48] <Zorry> yes but now it leead to  confused
[22:19:10] <Zorry> to have files that dont get inherit
[22:19:18] <blueness> right so remove just the directories -> profile/hardened{amd64, ia64, ppc, ppc64, x86}
[22:19:21] <blueness> ah!
[22:19:29] <blueness> you mean remove the parent ones that are not inhertied
[22:20:11] <Zorry> for the hardened/linux dont use any in /hardened
[22:20:21] <blueness> right
[22:20:57] <blueness> Zorry, let me test after the meeting on the hardened-dev overlay profiles branch
[22:21:11] <blueness> just in case, then i'll let you know, then axe them away!
[22:21:19] <Zorry> k
[22:22:03] -*- blueness bows out of the meeting again
[22:22:08] <blueness> sorry folks
[22:22:17] <Zorry> np
[22:22:33] <Zorry> next then?
[22:22:34] <prometheanfire> rpmdev-setuptree
[22:23:18] <Zorry> 7.0 Docs
[22:23:31] <Zorry> SwifT klondike ^^
[22:24:20] <SwifT> okay, SELinux docs have been cross-checked recently to ensure that they still stick with our current policies and tools, which looks like it does. The SELinux handbook has seen a small few udpates recently, but none major
[22:24:56] <SwifT> I will focus a bit more on how to tackle AVC denials since that's the majority of policy development work;, and not everyone understands that giving us what needs to be allowed isn't sufficient
[22:25:29] <Zorry> did see that on the hardened ml
[22:25:30] <Aleister> so a section like: how you can help us help you?
[22:25:40] <Aleister> what information that is needed etc?
[22:25:48] <SwifT> a guide or so on "How to report SELinux policy bugs" or so
[22:25:56] <Aleister> awesome :)
[22:26:00] <Aleister> just what i need :D
[22:26:03] <SwifT> ;)
[22:26:26] <SwifT> that's all I have to say on hardened docs
[22:28:04] <Zorry> sms ing klondike
[22:28:30] <SwifT> yeah, he should be twitter'ing the progress of this meeting :p
[22:28:46] <Zorry> next?
[22:28:55] <Aleister> he said to move on...
[22:29:01] <Zorry> 8.0 Bugs
[22:29:28] <Zorry> do we have any bugs that need disscusion?
[22:30:13] --> Arach (~arach@95-30-210-190.broadband.corbina.ru) has joined #gentoo-hardened
[22:30:21] <Zorry> klondike: will be here in ~10 min
[22:30:32] <SwifT> nothing major here
[22:31:15] <Zorry> k
[22:31:18] <Aleister> i have been trying to track down a nasty nfs4 bug, Dosent seems related to hardened so...
[22:32:27] <SwifT> battousai is still mentioned on our project pages for the "bastille" subproject, but he is retired (bug #34864), what should we do here? just remove the bastille stuff from hardened project page?
[22:32:30] <willikins> SwifT: https://bugs.gentoo.org/34864 "Retire: Bryan Stine (battousai)"; Gentoo Developers/Staff, Retirement; IN_P; dberkholz:retirement
[22:34:26] --> knoc (~knoc@p5B045CAF.dip.t-dialin.net) has joined #gentoo-hardened
[22:35:05] <Zorry> SwifT: should be removed from the page
[22:35:24] <Zorry> do we have any underlaying page for it?
[22:35:58] <SwifT> nope, no underlaying page
[22:36:04] <Zorry> k
[22:37:58] <Zorry> so remove he  from the page then
[22:38:33] <SwifT> done
[22:39:14] <Zorry> so move to open floor and wait for klondike
[22:39:28] <Zorry> 10.0 Open floor
[22:39:52] <Smiley> Why can't the council run their meetings as well as you guys just did...
[22:40:59] <SwifT> we have easier subjects to discuss... harder to comprehend sometimes, but less likely to hit people's ego's ;)
[22:41:18] <Aleister> SwifT: when i find the time i have 4vm`s+host to throw selinux at :)
[22:41:45] <SwifT> btw, I'm considering asking for a git.overlay.gentoo.org repo to put the hardened selinux refpolicy stuff in, should make it easier to contribute for people (like prometheanfire)
[22:42:23] <SwifT> i'll try to get that done before next meeting
[22:42:38] <prometheanfire> ya, I'm going to be building a personal overlay
[22:43:00] <prometheanfire> when lvm is fixed
[22:43:12] <klondike> pong
[22:43:24] <klondike> Sorry for being so awfully late
[22:43:36] <Zorry> klondike: did you have anythin on the docs?
[22:43:43] <Zorry> klondike: np
[22:43:48] <klondike> Yes
[22:43:58] <klondike> We MUST update the primer
[22:44:21] <klondike> dberkholz shared some stats with me and it is the first place users getting in our project places go
[22:44:34] <klondike> So I will take it as my first priority for now
[22:45:03] <Smiley> yeah as a end user, i've looked at it a few times and its great for explaining what hardned IS, and the different sections
[22:45:04] <klondike> We also need to update the project page since prometheanfire has joined and I'm not a non dev anymore
[22:45:16] <prometheanfire> klondike: that's been done by swift
[22:45:20] <Smiley> but it doesn't also explain the implmentiation, and how to fix things so much...
[22:45:36] <klondike> prometheanfire: Updating project page?
[22:45:46] <klondike> Cool so then I'll focus on the primer :D
[22:45:49] <prometheanfire> he added me methinks
[22:46:02] <klondike> I can recheck that
[22:46:14] <klondike> We can also add a link to our twitter account too
[22:46:14] <prometheanfire> he did
[22:46:30] <klondike> Well that's mostly  all regarding docs
[22:46:38] <Zorry> k
[22:46:47] <klondike> Zorry: I hope you don't mind if we do toolchain later
[22:46:50] <SwifT> klondike: if you have the time, you can see if the gentoo hardened page on wiki.gentoo.org gets improved as well
[22:46:54] <SwifT> looks dull for the moment
[22:46:54] <Zorry> klondike: np
[22:47:13] <klondike> SwifT: I fixed some grammar and so there but little more
[22:47:37] <klondike> Anything more or we move to next point?
[22:47:54] <Zorry> next
[22:48:04] <klondike> Ok
[22:48:08] <klondike> so regarding PR
[22:48:21] <klondike> We have gotten a few more followers on our twitter account
[22:48:48] <klondike> So if you don't feel like tweeting the new things just ping me on irc with the message and I'll tweet it
[22:49:02] <klondike> I also thing we can try expanding to identi.ca for now
[22:49:12] <klondike> Anybody against that?
[22:50:10] <Zorry> souds okay
[22:50:31] <klondike> Oki
[22:50:47] <klondike> I'd also apreciate if blueness can say if he advanced on the paper or not
[22:50:55] <klondike> Otherwise we can start using the wiki for that
[22:51:08] <klondike> Since it isn't something we want to keep private
[22:51:22] <klondike> And I bet FOSDEM call for papers will close soon
[22:52:30] <klondike> Finally
[22:53:06] <klondike> I'd also like to try sending propossal for interviews to other medias like Linux Magazine and maybe LWN
[22:53:28] <klondike> So I'd appreciate to know whose of you feels like doing interviews
[22:53:35] <klondike> And I bet this is mostly all
[22:55:10] <Zorry> hate interviews
[22:55:11] <klondike> Anybody has comments on this?
[22:55:19] <Aleister> what about that gentoo dude making that podcast?
[22:55:31] <klondike> Zorry: we are not going to force you  to go to one if you don't want ;)
[22:56:07] <klondike> Aleister: if you can give me his contact we can talk to him
[22:56:19] <Aleister> he is a staffer/dev
[22:56:59] <klondike> I'll ping then on -core and ask :D
[22:57:16] <Aleister> David Abbott
[22:57:39] <Zorry> dabbott on -dev
[22:57:43] <davidk> other david, k
[22:58:24] <klondike> Ohh so its dabbot from PR? cool
[22:58:28] <Aleister> you might want to figure out who is willing to do the interview first of all :)
[22:58:34] <Aleister> klondike: ya :)
[22:59:01] <klondike> So far I bet that at least me, blueness may be willing to and Zorry says no :P
[22:59:05] <Aleister> i wouldnt mind but that would be as a luser :)
[22:59:16] <klondike> Nope
[22:59:33] <klondike> If I get you as an interview it is as a colaborator ;)
[22:59:54] <klondike> Just say you are a community manager and handle querys on the IRC channels ;)
[23:00:17] <Aleister> i was but back then i was paid XD
[23:00:40] <klondike> I say on the Hardened project XD
[23:01:06] <Aleister> yaya, just reminded me of the good old times where money drops if you said opensource :)
[23:01:26] <Aleister> Zorry: have a few mins later?
[23:01:34] <Zorry> Aleister: yes
[23:01:46] <Aleister> unless the meeting is done of course XD
[23:02:21] <Zorry> klondike: do you have anything more?
[23:02:55] <klondike> Nope
[23:03:09] <Zorry> okey ty all for the meeting