Here is the meeting log from the meeting. /Magnus
[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 gentoo-dev@g.o 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
