Meeting log 2013-08-29 20:00UTC

[00:24:39] <Zorry> 2.0 Toolchain
[00:24:48] <klondike> calling lejonet_
[00:24:55] <prometheanfire> sure
[00:25:00] <klondike> He says today he is in charge of the pub and can't join :(
[00:25:08] <prometheanfire> oh
[00:25:11] <prometheanfire> so don't call?
[00:25:14] <Zorry> gcc 4.8.1 will sone be unmasked
[00:25:23] <klondike> prometheanfire: do call blueness please
[00:26:11] <Zorry> and the hardenedno* will work
[00:26:25] <Deda_Zych> hehe
[00:26:44] <prometheanfire> he'll be here in a sec
[00:26:46] <Deda_Zych> so optimistic
[00:27:06] <Zorry> still no progress on the asan thing
[00:27:06] <klondike> Hi pipacs, welcome :)
[00:27:13] <miniBill> http://arstechnica.com/apple/2013/08/rendering-bug-crashes-os-x-and-ios-apps-with-string-of-arabic-characters/
[00:27:28] <Zorry> it have more hardcoded addresses
[00:27:30] <blueness> Zorry, prometheanfire lost in thought!
[00:27:32] <blueness> so sorry
[00:27:40] <Zorry> miniBill: meeting
[00:27:42] <SwifT> miniBill, Deda_Zych - please wait until the online meeting is over
[00:28:02] <klondike> Or we'l have to moderate :(
[00:28:12] <Deda_Zych> okay, sorry
[00:28:17] <SwifT> Zorry: is the asan thingie being picked up upstream?
[00:28:21] <SwifT> or is it just silent?
[00:28:31] <Zorry> SwifT:  will upstream it
[00:28:54] <Zorry> it affect llvm and gcc for it use the same thing
[00:29:14] <blueness> Zorry, no matter what i did with those various parameters, i could not get it to work with a pax kernel
[00:29:27] <miniBill> ack
[00:29:35] <Zorry> blueness: yee it have more stuff hardcoded
[00:29:50] <pipacs> blueness, you mean under uderef, right? 'cos without uderef it should work
[00:30:01] <Zorry> pipacs: yes
[00:30:04] <blueness> pipacs, yes
[00:30:12] <blueness> i should have been more specific
[00:30:27] <klondike> so asan + UDEREF is bad
[00:30:35] <blueness> klondike, correct
[00:30:55] <klondike> Shrug will add it to the fuck (pun intended)
[00:31:06] <Zorry> pipacs: is there some way to check if we have uderef enable?
[00:31:09] <pipacs> does asan work under windows?
[00:31:18] <blueness> bug #458706
[00:31:19] <Zorry> pipacs: think so
[00:31:20] <willikins> blueness: https://bugs.gentoo.org/458706 "PaX: Max. per-task virtual memory too small for llvm asan and gcc-4.8 asan"; Gentoo Linux, Hardened; IN_P; klaus.kusche:hardened
[00:31:28] <blueness> pipacs, i didn't try it
[00:31:57] <pipacs> zorry, well, lately dmesg will have a message about the kind of uderef used (only if it's enabled in config), and you can also look at the address space size (like where the initial stack is)
[00:32:11] <Zorry> okay
[00:32:27] <blueness> pipacs, doesn brk() return that value?
[00:32:32] <pipacs> i'm just asking about windows because it also has a smaller userland address space than linux and its 47 bits
[00:32:47] <pipacs> nope, brk returns an address 'close' to the main executable
[00:33:10] <Zorry> pipacs: powerpc to have lower to and it have code allover the plase in asan
[00:33:15] <blueness> pipacs, so how would we get the initial stack addr?
[00:33:45] <pipacs> take the addr of any local variable ? ;)
[00:33:54] <pipacs> or just look at argv, env strings, etc
[00:34:02] <pipacs> or in proc/pid/maps
[00:34:07] <blueness> pipacs, yeah but that's randomized
[00:34:27] <pipacs> doesn't matter, the generic area (top 4 bits) will remain the same
[00:34:45] <blueness> ah yes, good point we're up in the 46, 47 bit range
[00:35:01] <blueness> okay that's doable
[00:35:19] <pipacs> but ideally you should follow the model used for windows/ppc/whatever in asan
[00:35:30] <pipacs> and make the uderef address space size a similar case
[00:36:06] <pipacs> also for pcid based uderef (introduced very recently) i could restore the  full address space but that'd cost (even more) performance
[00:36:32] <Deda_Zych> what the asan is?
[00:36:44] <Zorry> pipacs: no need to restore
[00:36:44] <pipacs> address sanitizer, rest is on google
[00:37:45] <Deda_Zych> stupid practice for monkeys afaik
[00:37:45] <blueness> pipacs, when you say " make the uderef address space size a similar case" do you mean by editing the kernel or asan?
[00:37:51] <Deda_Zych> * imfo
[00:37:58] <Deda_Zych> *imho
[00:38:31] <Zorry> blueness: asan have code for the powerpc/window with lower address specs
[00:38:41] <blueness> Zorry, like we were trying
[00:38:49] <Zorry> blueness: yepp
[00:38:55] <Deda_Zych> good-written program never have a memory errors
[00:38:55] <blueness> but it failed for us
[00:38:59] <Deda_Zych> never was
[00:39:03] <Deda_Zych> never will
[00:39:34] <Zorry> so upstream it and wait
[00:39:38] <blueness> k
[00:39:41] <Zorry> next
[00:39:45] <blueness> k
[00:39:46] <pipacs> blueness, editing asan
[00:39:59] <blueness> pipacs, okay that's what Zorry and i were tring
[00:40:17] <klondike> Zorry: you mean send upstream the bug or the fixes?
[00:40:26] <blueness> the bug and suggested fixes
[00:40:32] <pipacs> i'd naively think that you just have to find all ifdefs for those archs and add a uderef case ;)
[00:40:34] <Zorry> klondike: upstream the bug
[00:41:28] <pipacs> but that'd be just a proof of concept solution, for real use you want to get rid of hardcoded addresses/constants and make it runtime selectable, but that's probably a whole lot more work
[00:41:51] -*- klondike nods
[00:41:59] <klondike> And maybe less efficiency
[00:42:58] <Zorry> can we do next point?
[00:43:08] <klondike> Oki for me
[00:43:23] <klondike> prometheanfire: are you back home?
[00:43:24] <blueness> yes
[00:43:54] <Zorry> 2.1 -fstack-check enable by default on gcc 4.8.1
[00:44:13] <Zorry> do we enable it on all arches or only on some?
[00:44:44] <blueness> Zorry, good question, i know what happens with ffmpeg in amd64
[00:44:57] <blueness> there even 10 registers isn't enough for some of the asm in one of the drivers
[00:45:02] <blueness> err ... codecs
[00:45:10] <klondike> blueness: because they are stupid
[00:45:14] <blueness> indeed
[00:45:17] <prometheanfire> klondike: ya
[00:45:18] <Zorry> blueness: even libav have problems
[00:45:30] <blueness> but i don't know how -fstack-check is implemented in x86 or the other arches
[00:45:46] <blueness> so maybe it doesn't need a free register for x86
[00:45:46] <klondike> Zorry: because they inherited ffmpeg's code ;)
[00:45:50] <blueness> not sure, has anyone tried
[00:45:55] <Zorry> klondike: figut that
[00:46:22] <klondike> I have talked with lu_zero, he'll help me upstream the fix on libav thus earning a lot of respect points from me :)
[00:46:25] <SwifT> what's the goal for us - filter the fstack-check option on those ebuilds that can't take it?
[00:46:45] <blueness> that was the most intense use of registers i've ever seen, i think we should just edit the ebuild and add -fno-stack-check only for ffmpeg and only for hardened
[00:46:57] <blueness> i don't think anything else will break
[00:47:10] <blueness> so ffmpeg and libav are corner cases
[00:47:55] <SwifT> i'd say enable it on all arches - we'll be notified soon if it does cause huge havoc in some (and can then still decide to drop it for those arches, right?)
[00:48:05] <Zorry> yep
[00:48:17] <SwifT> better soon (now that it still has to be unmasked) than later (when it would be already stable :p-
[00:48:26] <klondike> blueness: as for ffmpeg I can talk to you on that later
[00:48:39] <blueness> klondike, okay
[00:48:43] <blueness> so i'm with SwifT
[00:48:49] <klondike> But the issue was basically overoptimization by keeping some constants on registers instead of memory
[00:48:50] <Zorry> SwifT: +1
[00:48:52] <blueness> enable it globally on all arches
[00:49:11] <blueness> klondike, yeah but upstream will never accept that fix
[00:49:22] <klondike> libav will :]
[00:49:27] <blueness> why?
[00:49:27] <klondike> To me that's enough
[00:49:35] <blueness> libav is reasonable?
[00:49:39] <klondike> Because lu_zero is a reasonable guy ;)
[00:49:42] <blueness> k
[00:49:59] <blueness> lu_zero is upstream libav?
[00:50:03] <klondike> yep
[00:50:07] <blueness> k
[00:50:41] <blueness> i think we're done with this issue
[00:51:48] <Zorry> blueness: do you have any thing on uclibc?
[00:52:03] <blueness> Zorry, nothing new really, just maintaining steadily
[00:52:30] <SwifT> how's lilblue going?
[00:52:36] <blueness> i should say mips32r2 takes 2 weeks for both hardened and vanilla stages on a ubiquity router station!
[00:52:39] <blueness> but it does compile
[00:53:02] <blueness> SwifT, amede has shown interest and people are using it, i've got a binhost at about 6000 packages but its not ready yet
[00:53:16] <SwifT> blueness: wouldn't emulating mips on a faster machine help with the builds?
[00:53:20] <blueness> you know things are taking off when users submit their own patches upstream to work on lilblue!
[00:53:27] <SwifT> hehe
[00:53:38] <blueness> SwifT, probably not, qemu-mips is just as slow
[00:53:54] <SwifT> bleh
[00:53:57] <blueness> its gcc-4.8.x which is the beast
[00:54:02] <klondike> blueness: but you can multithread that ;)
[00:54:13] <blueness> klondike, maybe yes
[00:54:18] <blueness> there might be some gain
[00:54:28] <blueness> if it gets worse, i'll have to switch to cross building
[00:54:37] <blueness> which is not too hard, but it does have some dangers
[00:54:59] <blueness> eg. the NOP command on the lemote mips64el is borked and i'm not sure how a cross compile would do there
[00:55:03] <SwifT> buy a more expensive ubiquity router :p
[00:55:06] <blueness> native hardware is always better
[00:55:26] <blueness> SwifT, actually i have one, a mips64 that i've been using for other stuff
[00:55:41] <blueness> a ubiquity edge router lite
[00:55:49] <SwifT> that uniquity router, is that one of the imagination donated ones?
[00:55:50] <blueness> it might be worth trying
[00:55:53] <blueness> yes
[00:55:57] <SwifT> cool
[00:56:29] <blueness> i've got to bug markos for his kernel because the SD card isn't the most table
[00:56:31] <blueness> anyhow
[00:56:39] <blueness> real life steppe din
[00:56:43] <blueness> stepped in
[00:57:14] <Zorry> next ?
[00:57:19] <blueness> yes
[00:57:20] <SwifT> yup
[00:57:44] <Zorry> lead or kernel ?
[00:57:52] <SwifT> lead first
[00:57:54] <Zorry> ok
[00:58:01] <blueness> I vote for "not me"
[00:58:03] <blueness> :)
[00:58:04] <Zorry> 1.0 leads
[00:58:23] <Zorry> any on projects lead?
[00:58:42] <blueness> leave them i think
[00:58:50] <SwifT> I nominate all current leads for their current project, and put myself in position for those subprojects I already lead :p
[00:58:59] <Zorry> okay
[00:59:04] <blueness> SwifT, +1
[00:59:11] <Zorry> klondike: prometheanfire ?
[00:59:36] <klondike> Just for the sake oof plurality I present my self as current hardened project leads ;)
[00:59:49] <klondike> I'll also like to keep PR if possible
[00:59:58] <prometheanfire> +
[00:59:59] <prometheanfire> +1
[01:00:01] <prometheanfire> bah
[01:00:46] <klondike> Other than that I second SwifT's nominations
[01:00:48] <blueness> klondike, what do you mean?
[01:01:08] <prometheanfire> the +1 was for swifts nominations
[01:01:56] <klondike> blueness: That for the sake of plurality I'm presenting young me as an alternative to Zorrys non dictatorships ;)
[01:02:18] <blueness> klondike, oh okay i'm confused because we were talking about subprojects
[01:02:30] <klondike> Maybe I'm choosing the worst word, nominating may be a better one :P
[01:02:37] <blueness> Zorry, so vote on subproject leads remaining the same?
[01:02:56] <Zorry> blueness: yes looks that way
[01:03:09] -*- blueness votes yes
[01:03:13] -*- SwifT too
[01:03:29] <Zorry> +1
[01:03:31] <klondike> I vote no, I want SwifT to take over Doc if he already hasn't :P
[01:03:42] <SwifT> there's no doc subproject :p
[01:04:14] <klondike> Ohh then I go for yes ;)
[01:04:38] <Zorry> Done...
[01:04:56] <Zorry> next main lead me or klondike
[01:05:05] <Zorry> if i got klondike right
[01:05:14] <klondike> You copied me
[01:05:21] -*- blueness votes for Zorry 
[01:05:33] <klondike> Down with Zorry's democracy up with klondike's dictatorship :P
[01:05:35] <SwifT> well, although klondike can put a lot of weight in, I vote for Zorry
[01:05:46] <klondike> I vote for Zorry too
[01:05:46] <SwifT> (pun intended ;)
[01:06:33] <klondike> prometheanfire: who do you vote for?
[01:06:38] <blueness> prometheanfire, ???
[01:06:59] <prometheanfire> 16:02 <  prometheanfire@> the +1 was for swifts nominations
[01:07:11] <SwifT> so current leads - including zorry ;)
[01:07:14] <prometheanfire> yep
[01:07:24] <klondike> Oki
[01:07:37] <SwifT> great - settled. congrats to all, and make sure you don't slack!
[01:07:39] <Zorry> so look like i was reselected as lead
[01:07:40] <SwifT> next topic?
[01:07:44] <Zorry> next
[01:07:47] <blueness> yes next
[01:08:06] <klondike> Unanimity then
[01:08:06] <Zorry> 3.0 Kernel and Grsec/PaX
[01:08:38] <Zorry> blueness: pipacs ^^
[01:09:04] <pipacs> any questions? ;)
[01:09:17] <blueness> there's nothing new to report really, i'm looking to stabilize a 3.10.x kernel soon, but there were some early boot freezes, i'm going to test the latest after thing meeting
[01:09:36] <blueness> bug #482010
[01:09:38] <willikins> https://bugs.gentoo.org/482010 "=sys-kernel/hardened-sources-3.10.7* early boot panic"; Gentoo Linux, Hardened; CONF; chutzpah:blueness
[01:10:02] -*- klondike has been suffering strange OOPs on sys_pax_exit or something like that with 3.9.6
[01:10:17] <pipacs> that should be fixed but the reporter isn't too active
[01:10:31] <SwifT> oh I can test on that as well, had the same issue
[01:10:35] <blueness> pipacs, i haven't tested, i was waiting for him to answer, but i'll test
[01:10:57] <blueness> SwifT, i'll have the next set up in a few hours
[01:11:09] <pipacs> i'm pretty certain he's got a haswell and the invpcid code blew up there 'cos it wasn't well documentend and i was trying to save on something
[01:11:14] <pipacs> but now i went for the safer code
[01:11:17] <SwifT> oh wait, that's another oops
[01:11:25] <pipacs> so i hope it'll work, but anyone on haswell can help test it
[01:11:47] <SwifT> i had bug #481790
[01:11:48] <willikins> SwifT: https://bugs.gentoo.org/481790 "sys-kernel/hardened-sources-3.10.7-r1 - kernel crash in KVM guest"; Gentoo Linux, Hardened; UNCO; alexander:hardened
[01:11:58] <blueness> SwifT, might be the same, no?
[01:12:11] <pipacs> that's fixed already
[01:12:25] <blueness> k
[01:12:36] <blueness> pipacs, also, is there a relationship between the two SLOB bugs
[01:12:45] <SwifT> it's fixed upstream, but it still needs to be pulled in a hardened-kernel, not?
[01:12:45] <blueness> bug #480548
[01:12:46] <pipacs> SLOB = death wish
[01:12:46] <willikins> blueness: https://bugs.gentoo.org/480548 "=sys-kernel/hardened-sources-3.9.9 fails to compile with CONFIG_SLOB=y"; Gentoo Linux, Hardened; CONF; mk:hardened
[01:12:50] <klondike> pipacs: do you know anything about cpu_idle cusing either panics or oops?
[01:12:58] <blueness> and bug #349837
[01:12:59] <willikins> blueness: https://bugs.gentoo.org/349837 "sys-kernel/hardened-sources-2.6.36-r6: SLOB Allocator + PAX_USERCOPY causes PaX to kill all processes"; Gentoo Linux, Hardened; CONF; jgolonko:hardened-kernel
[01:13:14] <pipacs> klondike, no idea, never saw it myself
[01:13:23] <blueness> pipacs, should we set it BROKEN if pax is enabled?
[01:13:31] <klondike> Oki I'll photo it if it happens again :)
[01:14:12] <pipacs> blueness, well, that's one way of 'fixing' it ;P
[01:14:32] <blueness> pipacs, hmm ... i like hitting bugs so we know they are there at least
[01:14:33] <pipacs> klondike, also use something recent, not 3.9
[01:14:49] <blueness> when people open bugs against SLOB we can remind them SLOB = death wish
[01:15:59] <Zorry> pipacs: will you support 3.10 as longterm kernel?
[01:16:28] <pipacs> no we won't
[01:16:32] <Zorry> k
[01:16:48] <pipacs> we'll probably choose the next such kernel next year, probably the one ubuntu lts settles on
[01:17:04] <blueness> pipacs, works for us
[01:17:10] <Zorry> k
[01:17:30] <klondike> Who wants LTS anyways? :P
[01:18:01] <blueness> life on the hemoraging edge
[01:18:21] <klondike> BTW, which are the current LTS? 2.6.32 and any other?
[01:18:35] <pipacs> and 3.2
[01:18:54] <blueness> pipacs,  and 2.6 no?
[01:19:00] <klondike> Ohh that's one too many IMHO :)
[01:19:23] <blueness> https://grsecurity.net/download_stable.php
[01:20:02] <pipacs> i no longer support 2.6.32 myself, spender keeps it alive only because some sponsors pay for it
[01:20:48] <klondike> Jokes aside pipacs we appreciate your work, a few weeks ago I had to update from a 3.1 or so I had in Valencia
[01:21:00] <blueness> brb guys, i must take care of my dog
[01:21:24] <yac> jfyi: I love the live coverage on twitter
[01:21:50] <klondike> yac: thanks, glad to see it's helpful :)
[01:21:54] <Zorry> next then?
[01:22:14] <SwifT> next
[01:22:17] <Zorry> 4.0 Selinux
[01:22:41] <SwifT> nothing major - policycoreutils has been bumped with a few patches on rlpkg and selocal
[01:23:04] <SwifT> rlpkg now displays the setfiles command that it executes in the background, because we had a few reports about filesystem relabeling that wasn't complete
[01:23:10] <SwifT> the command should help us debug that if it occurs again
[01:23:31] <SwifT> that, and the magic behind precompiled expressions (libpcre) makes it really... challenging ;)
[01:24:04] <SwifT> other than that, nothing to report - we're following upstream quite nicely and i'm probably going to push our rev3 of the policies soon (~arch)
[01:24:29] <SwifT> that's it
[01:25:46] <Zorry> next?
[01:25:52] <SwifT> yup
[01:25:54] <Zorry> 5.0 System Integrity
[01:26:13] <SwifT> for IMA and EVM, a patch that I have been waiting for has been put in the Linux kernel when I wasn't looking
[01:26:23] <SwifT> it's in 3.9.5 and hgiher, perhaps also lower (didn't look further)
[01:26:35] <SwifT> so that means IMA/EVM now works again with custom policies
[01:27:19] <SwifT> next on the agenda is to check the kernel module signature based protection
[01:27:30] <SwifT> which, when I get a 3.10.x kernel to boot, should be fairly easy to document
[01:28:01] <klondike> I think I know how it works
[01:28:19] <SwifT> looks fairly simple, just need to play around with it for a while
[01:28:33] <klondike> They basically generate a digest of the binary module then sign it with their own key
[01:28:49] <SwifT> i'll be working on gentoo security baselines in the next few weeks (SCAP based content) so expect some chatter on that on wiki/mailinglist soon
[01:28:56] <klondike> You probably should start by the Makefiles, looks for calss to openssl ;)
[01:29:22] <SwifT> yeah, there's a sign-file script available as well
[01:29:31] <SwifT> anyway - that's it for integrity
[01:30:04] <blueness> SwifT, make it easy because if i have to learn one more complicated thing, my mind will explode
[01:30:30] <klondike> blueness: unification theories :P
[01:30:31] <SwifT> not my fault security is difficult :p
[01:30:49] <blueness> you're all lazy!
[01:30:53] <blueness> :P
[01:30:58] <blueness> push the work on me!
[01:31:40] <SwifT> nah, you'll need to read [email protected] and digest it for us :p
[01:31:44] <SwifT> you're on the council :p
[01:32:53] <SwifT> next?
[01:33:08] <klondike> LOL
[01:33:35] <Zorry> 6.0 Profiles
[01:33:40] <blueness> sure
[01:33:53] <blueness> i have one profile i added to hardened, very very experimental
[01:34:03] <klondike> x32?
[01:34:08] <blueness> no hardened/linux/musl
[01:34:21] <blueness> its an even more slim libc
[01:34:36] <blueness> i've almost got an entire stage3 but still needs some work and it hardened well but ...
[01:34:48] <blueness> i think i should restructure things a bit in the future
[01:35:01] <blueness> and have default/linux/uclibc and default/linux/musl
[01:35:17] <blueness> and then have hardened/linux/uclibc and hardened/linux/musl inherit from them
[01:35:21] <blueness> it makes mroe sense
[01:35:39] <blueness> right now i have vanilla as USE=-hardened on those profiles which is backwards
[01:35:44] <SwifT> Next month on #gentoo-hardened: blueness wrote his own libc :p
[01:35:59] <blueness> at some point i'll email gentoo-dev@ and suggest the idea
[01:36:16] <blueness> SwifT, libc are very very important!  like kernels
[01:36:21] <klondike> xD
[01:36:31] <blueness> klondike, yes?
[01:36:51] <klondike> blueness: just found SwifT comment funny
[01:36:51] <blueness> anyhow, on the question of the profiles, doesn't that make more sense?
[01:37:10] <klondike> I'm all in fro blibc ;)
[01:37:10] <Zorry> to have default yes
[01:37:29] <blueness> okay, i've been very busy with teaching but i'll try to push that out
[01:37:32] <SwifT> blueness: yes, it makes it more predictable (the profiles)
[01:37:34] <blueness> i would add default first
[01:37:37] <blueness> then wait
[01:37:37] <klondike> blueness: from an elegance PoW having default instead of hardened makes sense
[01:37:41] <blueness> and then switch to inheriting
[01:38:17] <blueness> it does mean i'll have to change my catalyst scripts but i can do that
[01:38:24] <Zorry> blueness: or have profiles/musl/...
[01:38:29] <Zorry> as uclibc have
[01:38:42] <blueness> Zorry, the profiles/uclibc is in a very very bad place
[01:38:47] <Zorry> k
[01:38:48] <blueness> i don't know who uses it
[01:39:26] <Zorry> did use it before to test uclibc
[01:39:50] <blueness> Zorry, well that's originally why i went with hardened/linux/uclibc because i needed to start over
[01:40:01] <blueness> i should ask vapier
[01:40:33] <Zorry> next?
[01:40:33] <blueness> okay i'll investigate and report back next month
[01:40:35] <blueness> no need to rush
[01:40:39] <blueness> sure next
[01:40:45] <klondike> hum
[01:40:53] <klondike> blueness: you may want to ask solar
[01:41:10] <klondike> I think he knows the most about hardened + embedded here
[01:41:15] <blueness> probably
[01:41:31] <blueness> at least the older stuff
[01:41:33] <klondike> other than that next
[01:41:55] <Zorry> 7.0 Docs
[01:42:02] <klondike> SwifT!
[01:42:22] <SwifT> well, I moved our project space from www.gentoo.org/proj/en/hardened to wiki.gentoo.org/wiki/Project:Hardened
[01:42:44] <klondike> :)
[01:42:45] <SwifT> the documents that I think are still relevant are also moved to the wiki (most of them in the Project:Hardened)
[01:42:58] <SwifT> not all of them are moved though, I think we have a few documents in CVS that aren't accurate anymore
[01:43:01] <blueness> SwifT, i noticed, nice work!
[01:43:02] <SwifT> like the hardenedxorg.xml one
[01:43:31] <klondike> We should mark them as outdated then
[01:43:32] <SwifT> but other than that, it means you guys can now no longer pull the "I don't know GuideXML" card anymore ;)
[01:43:46] <klondike> SwifT: I never pulled that one :P
[01:43:51] <klondike> Who can edit these?
[01:43:55] <SwifT> all developers
[01:44:07] <SwifT> if a document is under "Project:" only developers can edit it
[01:44:22] <SwifT> I tend to move my user documents to the general one and just watch the documents, because I have faith :p
[01:44:27] <Zorry> SwifT: nice work
[01:44:50] <SwifT> like https://wiki.gentoo.org/wiki/SELinux/FAQ (and not Project:SELinux/FAQ)
[01:44:56] <SwifT> but that's a matter of choice
[01:45:03] <blueness> SwifT, but now i don't know wiki markup!
[01:45:14] <SwifT> hehe
[01:45:28] <klondike> blueness: I'm so going to go fetch a stick and use it with you until you learn ;)
[01:45:41] <SwifT> anyway, I can work on the wiki documents from time to time to make them more wikified and such over time, no biggie
[01:46:20] <SwifT> we just need to get blueness' wiki account to become Developer, because right now I had to put Zorry as lead for his projects on the wiki
[01:47:12] <SwifT> other than that, a warm request to you all to review the documents and update them when you notice they're stale (for isntance when they are still talking about paxctl instead of paxctl-ng and what not)
[01:47:12] <klondike> BTW there are WYSIWYG editors for wikis
[01:47:51] <blueness> klondike, i didn't know that, cna you name one
[01:48:12] <klondike> libreoffice can export to wiki markup IIRC
[01:48:15] <SwifT> and as a second topic for docs - and also the reason I wasnt' as active for gentoo as before - was that I was busy writing a book on SELinux System Administration (http://www.packtpub.com/selinux-policy-administration/book but the title will change from policy -> system)
[01:48:18] <blueness> i'm okay with just good ol' wiki markup, but maybe a wysiwyg would teach me a thing or two
[01:48:31] <SwifT> it refers to gentoo hardened on many occasions of course ;)
[01:48:31] <klondike> And there are also some js ones ;)
[01:48:38] <klondike> Plus the wikimarkup editor
[01:49:00] <SwifT> but the chapters have been accepted now, so that work is done and I can put more energy in gentoo again ;)
[01:49:04] <blueness> SwifT, i didn't know you authored a book for pakt
[01:49:18] <SwifT> you do now ;)
[01:50:04] <SwifT> rest assured though, I still aim to get our documents to be top-notch (and not to move all my documentation effort to the commercial side)
[01:50:08] <blueness> SwifT, i'm goign to have to pirate it as soon as it comesout
[01:50:13] <SwifT> hehe
[01:50:18] <blueness> how long is it?
[01:50:33] <SwifT> 117 pages (about 89 pages of real content)
[01:50:37] <klondike> FWIW I have announced it ;)
[01:51:02] <blueness> nice
[01:51:14] <klondike> But you know my policy on this stuff
[01:51:18] <SwifT> the order was to make a small book on selinux (which is quite a challenge) which also focuses on real-life work (so no theoretical part - also a challenge with selinux)
[01:51:45] <klondike> I prefer to pay SwifT directly his royalties + a little bit more and pirate it :P
[01:52:01] <Zorry> klondike: some beer's?
[01:52:06] <blueness> this one is by one of my students -> http://www.packtpub.com/yii-1-1-using-php-framework-application-development-starter/book
[01:52:06] <SwifT> i like
[01:52:11] <klondike> That also works :)
[01:52:33] <SwifT> blueness: php framework development - i hope he took security as an important requirement in it ;)
[01:52:41] <SwifT> anyway, that's about docs for me
[01:52:45] <Zorry> any thing else?
[01:52:51] <klondike> Yeah
[01:52:55] <Zorry> next then
[01:53:04] <Zorry> 8.0 Bugs
[01:53:06] <blueness> next
[01:53:09] <klondike> SwifT: announce the book on the gentoo-hardened list when it's out
[01:53:17] <SwifT> will do
[01:54:12] <Zorry> any bug or next?
[01:54:24] <SwifT> well, about bugs - the #481790 one mentioned that it would be fixed in the next (pax?) patch - blueness, do you know if/when this one will be available in the tree?
[01:54:44] <SwifT> pipacs said it was already fixed, so I guess I just need to wait until 3.10.7-r2 or so ?
[01:54:48] <klondike> When pipacs is done with it as always :P
[01:55:11] <blueness> SwifT, this evening (about 4 hours) after i put it through the testing
[01:55:30] <SwifT> blueness: great
[01:56:30] <Zorry> next?
[01:56:35] <klondike> go!
[01:56:45] <Zorry> 9.0 Media
[01:57:04] <klondike> Well as unusual I have been tweeting the meeting
[01:57:39] <klondike> I also sent ical + google calendar invites to the meeting in the hope they helped which seems wasn't the case :P
[01:58:03] <klondike> Other than that I have not much more to report
[01:58:19] <klondike> I haven't given any talks and I think none of us has
[01:58:40] <klondike> As always suggestions and so are more than welcome :)
[01:59:20] <Zorry> 10.0 Open floor
[01:59:27] <klondike> I also am considering creating a simple meeting congregator on Haskell to handle the icals for me and mail sending for Zorry  :P
[01:59:50] <Zorry> any thing else the meeting is done
[01:59:59] <blueness> nope
[02:00:05] <Zorry> ty all for the meeting