Hi We did move the meeting to 2013-02-07 and here is the log. /Magnus
[21:02:31] <Zorry> 1.0 Toolchain [21:03:05] <Zorry> 4.8 is on stage4 so i will start with the patches next week [21:03:22] <Zorry> and i need some help to test it on arm/ppc/mips [21:03:33] <blueness> no problemo! [21:03:41] <Zorry> and it will be on the h-overlay [21:04:10] <blueness> Zorry, ping me when you want the testing and i'll do it [21:04:26] <Zorry> and the hardenedno options may be need to go away [21:04:56] <blueness> Zorry, as we discussed, that's fine, we don't really used them anyhow [21:05:04] <blueness> ebuilds should add the correct flags anyhow [21:05:23] <blueness> eg if we need to turn off -nopie etc [21:05:30] <Zorry> yep [21:06:21] <Zorry> when 4.9 get to stage1 i will try upstream the patches one more time but this time seperated [21:06:26] <Anarchy> Zorry, do we patch anything for hardened in binutils? [21:06:51] <Zorry> Anarchy: only pax and relro stuff [21:06:53] <blueness> Anarchy, yes for pax [21:07:25] <blueness> but not that i know for toolchain hardening, correct Zorry ? [21:07:46] <Zorry> blueness: only relro but that is on as default for gentoo [21:07:56] <blueness> oh yeah [21:08:10] <Zero_Chaos> is there a way to disable the constify plugin for gcc in an ebuild? Like if I want to build kernel modules that havne't been hardened [21:08:18] <Zorry> so relro and now need to be enable by default later on when 4.9 hit the tree [21:09:42] <Zorry> don't have any more on the toolchain [21:09:49] <Zorry> blueness: uclibc ? [21:09:59] <blueness> yes 1 sec [21:10:04] <klondike> Zorry: about the no* [21:10:08] <blueness> lol my wife callede me! [21:10:17] <klondike> Those are useful for devs trying to isolate problems [21:10:28] <klondike> What would be the alternative? [21:10:36] <blueness> uclibc: nothing new just continuing maintenance of mips/mipsel/amd64/x86 and arm [21:10:42] <blueness> didn't touch ppc [21:10:45] <Anarchy> Zorry, I am a bit curious why the push has not been made to add http://dpaste.com/913814/ to binutils [21:11:13] <Zorry> klondike: use cflags and ldflags to disable the stuff as it should do [21:13:21] <Zorry> Anarchy: blueness know more about it [21:13:23] <blueness> Anarchy, ask vapier, he wants that out of binutils, which means we'll be moving to pure XATTR_PAX [21:13:58] <blueness> i think he's pushing quickly but we are ready to do pure XATTR_PAX [21:14:08] <blueness> i'll speak more on the minor issues remaining later [21:14:25] <Zorry> do any one else have anythng? [21:14:53] <Zorry> next then [21:15:07] <Zorry> 2.0 Kernel and Grsec/PaX [21:15:18] <prometheanfire> I have a question to start us off here [21:15:24] <blueness> k [21:15:31] <prometheanfire> 3.7.0 sucks, why have we not marked a newer one stable [21:15:41] <blueness> prometheanfire, i was just about to get to that [21:15:50] <wip_> please do :P [21:16:14] <blueness> i've been trying to respect the 1 month but i think i need to do a rapid on 3.7.5, have you tested? [21:16:35] <blueness> 3.7.5 was only added one week ago [21:16:42] <prometheanfire> tested 3.7.4 [21:16:49] <Anarchy> blueness, I have 3.7.5 running on stable amd64 with no issues to report. [21:16:52] <prometheanfire> I will test 3.7.5 then [21:16:56] <blueness> okay 3.7.4 or 3.7.4-r1? [21:17:04] <Anarchy> Linux bull 3.7.5-hardened #1 SMP Thu Feb 7 13:20:46 CST 2013 x86_64 Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz GenuineIntel GNU/Linux [21:17:17] <blueness> Anarchy, i'm good with 3.7.5 too [21:17:19] <prometheanfire> r1 [21:17:56] <blueness> i'm okay with a rapid stab at 3.7.4-r1 and remove 3.7.0 but not the earlier ones [21:18:22] <blueness> is that okay with everyone? [21:18:27] <Anarchy> I am not good with 3.7.4 or 3.7.4-r1 both had issues with ext4 [21:18:41] <klondike> blueness: you should be able to stabilize if it has been for at least 2 weeks without issues [21:18:44] <klondike> IIRC [21:19:01] <prometheanfire> Anarchy: thanks for warning me :D [21:19:13] <blueness> Anarchy, what was the ext4 issue? [21:19:16] <shadowdaemon> 3.7.0 killed my ext3. ='( [21:19:17] <blueness> that's news to me [21:19:26] <Anarchy> prometheanfire, I have a strange setup, but 3.7.0 and 3.7.5 worked fine [21:19:28] <SwifT> i'm on 3.7.4 for a few weeks, no troubles and the system has been falling short of power a few times. no apparent fs problems [21:19:40] <Anarchy> blueness, was hitting an oops during fsck [21:19:53] <blueness> Anarchy, you didn't report them? [21:20:14] <Anarchy> blueness, haha I have to much work to report most bugs, I either fix locally or use ~arch for testing. [21:21:16] <blueness> okay here are my options 1) stabilize 3.7.4-r1 now or 2) wait a week and do 3.7.5 [21:21:31] <blueness> 1 week in the tree is too short we may be trading one problem for another [21:21:31] <Anarchy> blueness, I also had an issue with initramfs compiled into kernel on 3.7.4 [21:21:57] <SwifT> wait a week for 3.7.5 then [21:22:07] <blueness> okay: option 2 intensive testing for one week and i'll stab 3.7.5 [21:22:11] <blueness> ty SwifT [21:22:17] <Zorry> +1 [21:22:20] <Anarchy> +1 [21:22:20] <prometheanfire> 2 weeks is fine as a stablization period, if the current stable sucks [21:22:25] <prometheanfire> +1 [21:22:31] <SwifT> i'll push to 3.7.5 tmorrow and do testing on that here as well [21:22:37] <Aleister> state it in topic that 3.7.0 can be trouble :) [21:23:02] <prometheanfire> ya, I've had to tell a couple of people that 3.7.0 sucks [21:23:29] <Anarchy> prometheanfire, defines sucks when refering to your issue please. [21:23:30] <blueness> okay can we move on to the next issue? [21:23:48] <prometheanfire> next [21:24:06] <blueness> Anarchy, eg -> https://bugs.gentoo.org/show_bug.cgi?id=455534 [21:24:09] <blueness> among others [21:24:26] <blueness> let's move on and we can talk about this later amongst ourselves [21:24:39] <blueness> this one is important the PaX flag migration [21:24:39] <Aleister> i should be able to test 3.7.5 in a few vm tomorrow :) [21:24:49] -*- Aleister notes down [21:25:10] <blueness> so, i have the documentation done, in fact, i went "overboard" with PaX in general so our quickstart is not so quick :) [21:25:29] <blueness> i'm done with the userland utilities [21:25:41] <blueness> we have three which cover different bases: paxctl -> only PT_PAX [21:25:51] <blueness> paxctl-ng -> PT_PAX and XATTR_PAX [21:25:57] <blueness> scanelf -> PT_PAX [21:26:04] <blueness> and ... (i guess its four) [21:26:11] <laen> I'm starting to think that using non-unique-ID user accounts was a bad bad idea ;p [21:26:12] <blueness> set/getattr -> XATTR_PAX only [21:26:25] <blueness> the eclass has to decide which to use [21:26:35] <SwifT> getfsattr you mean? [21:26:55] <blueness> SwifT, yes i did the c function by that name [21:27:16] <blueness> actually its getfattr [21:27:38] <SwifT> yes, sorry... too many mainframe talks today, my mind is truobled :p [21:27:47] <blueness> back to the eclass ... the thing I'm missing is that we have pax-mark -C and pax-mark -z [21:27:58] <blueness> and even pax-mark -c [21:28:11] <blueness> these are only appropriate for paxctl ... creating a PT_PAX header [21:28:43] <blueness> pageexec suggest ignoring them and just doing paxctl -Cc blindly for all PT_PAX markings because paxctl will automatically do the right thing [21:28:45] <blueness> and [21:29:00] <blueness> -C -c are kinda useless for XATTR_PAX [21:29:29] <blueness> bottom line, i'll be updating the eclass on the hardened-dev overlay and with the current in tree pax-mark ebuilds [21:29:43] <blueness> if it works then i'll propose it to the gentoo-dev list [21:29:58] <blueness> moving forward, pax-mark should not have -C or -c flags [21:30:09] <blueness> ^^^ I hope I explained that correctly [21:30:55] <blueness> take a look at bug #445948 [21:30:57] <willikins> blueness: https://bugs.gentoo.org/445948 "eclass/java-vm-2.eclass: should not use Cm flag combination"; Gentoo Linux, Java; CONF; AlphatPC:java [21:31:51] <SwifT> blueness: so, you're going to run "paxctl -Cc" automatically on binaries if the user needs PT_PAX markings? that's the "tl;dr" ? ;-) [21:32:12] <blueness> SwifT, that's what pageexec is suggesting [21:32:37] <blueness> alternatively [21:32:50] <blueness> i could just ignor that flag for paxctl-ng and still use it for paxctl [21:32:57] <blueness> that's the more conservative approache [21:33:31] <blueness> the idea of playing with the ELFs this way is a bit worrying, which is why it would be nice to see only XATTR_PAX in the far future [21:33:45] <blueness> SwifT, go with the conservative approach? [21:34:00] <SwifT> yes, I can understand the frustration on that part. I would too pick the conservative approach here if I were you [21:34:42] <blueness> SwifT, okay i'll code that way ${flags/C/} [21:34:44] <blueness> done! [21:35:32] <blueness> okay so that should be done by next meeting, i'll test over the weekend, and then propose to #gentoo-dev [21:35:48] <blueness> next? [21:35:59] <prometheanfire> yarp [21:36:07] <Zorry> 3.0 Selinux then [21:36:16] <SwifT> ok my turn [21:36:36] <SwifT> policy r10 is stable (which is r9 plus a small fix on the udev policies we hit with recent udev stabilization) [21:37:14] <SwifT> r11 is also in the tree, with quite a few upstream changes in it (little on my part - busy month), and most likely stabilized next week or, if there are big issues with it, it'll have to wait on r12 [21:37:28] <SwifT> r12 is pending (changes are already in repository, so live ebuilds will pick them up) [21:37:48] <SwifT> i haven't been able to upstream many patches since december, hopefully that'll change again beginning next week [21:38:21] <SwifT> also, libsepol has been updated to fix a problem with permissive modules (SELinux supports running in enforcing mode for all domains, but have a few domains run in permissive, so you don't need to run your entire system in permissive mode) [21:38:46] <SwifT> the SELinux eclass has also been updated to support removing SELinux modules frmo the SELinux policy stores when unmerging the packages [21:38:57] <SwifT> in the past, this wasn't done, so the module stores remained big [21:39:16] <SwifT> some users reported problems with, for instance, an unused store that had (too many) modules in it [21:40:06] <SwifT> that's about it for SELinux from my part. I have a bug I want to ask for help with (#443630) which is about libvirt and selinux and segfaults, but my system doesn't have libvirt and it pulls in too many dependencies to run here :( [21:40:13] <SwifT> but perhaps that's for the end of the meeting [21:40:29] <Zorry> !bug 443630 [21:40:34] <willikins> Zorry: https://bugs.gentoo.org/443630 "SELinux + >app-emulation/libvirt-0.9.13-r1 - Segfault starting qemu domains."; Gentoo Linux, Applications; UNCO; gentoo:selinux [21:41:15] <Zorry> SwifT: take that on the bug point [21:41:20] <SwifT> k [21:41:21] <prometheanfire> SwifT: what about the ruby stuff? [21:41:39] <SwifT> prometheanfire: what ruby stuff again? [21:42:13] <prometheanfire> sec [21:44:20] <prometheanfire> can't find it now [21:44:27] <prometheanfire> :( [21:44:37] <SwifT> ok, if you remember it as a bug, comment on it again that it hits my eye ;) [21:44:41] <blueness> brb (nature is reminding me that i am human) [21:45:08] <prometheanfire> SwifT: it's something you started updating code for but stopped [21:45:11] <SwifT> that's it for SELinux then, unless someone else has things to say on it [21:45:26] <SwifT> prometheanfire: sounds like swig :p [21:45:33] <prometheanfire> ya, it was swig [21:45:40] <SwifT> i hate swig [21:45:43] <prometheanfire> didn't know if that was it, but it was at the top of my list [21:45:48] <prometheanfire> so, what's up with that :P [21:46:02] <SwifT> we have a nasty problem with setools depending on swig-1 and libselinux depending on swig-2. both are not cmopatible with the other swig, and swig is not slotted [21:46:30] <SwifT> i've sent "a" patch for swig-2 support for setools upstream, but wasn't applied and it broke apol in ways I don't know how to handle [21:47:01] <prometheanfire> would it be easier to slot it? [21:47:19] <SwifT> it has an ugly build system too [21:47:29] <prometheanfire> well, thst sucks [21:47:45] <SwifT> i find it easier to ignore the problem. it's a build-time dependency, not run-time, so users that hit it can "emerge -u setools" and then just continue again [21:48:12] <prometheanfire> ah, I hit it a bunch because I do --with-bdeps=y [21:48:29] <SwifT> i know, not user friendly... but it's either working weeks and weeks on that single problem, or working on a few dozen other things to make more users happy [21:48:30] <prometheanfire> I'll emerge -u it though [21:48:40] <prometheanfire> next? [21:48:44] <SwifT> I remember that I worked on that swig issue for several weeks and it made me very unhappy [21:48:46] <SwifT> yes, next please ;) [21:48:50] <Zorry> next then ? [21:49:19] <Zorry> 4.0 Profiles [21:49:38] <Zorry> jump over it [21:49:50] <prometheanfire> til blueness is back [21:49:56] <Zorry> yep [21:50:06] <Zorry> 5.0 System interity [21:50:09] <Zorry> SwifT: ^ ^ [21:50:14] <SwifT> yup [21:50:30] <SwifT> ok, Linux 3.7 and IMA/EVM is now finally stable (upstream), so we can now support it as well in hardened [21:50:46] <SwifT> the documentation on our site is available; it currently marks IMA/EVM as "development only" as it is fairly new [21:51:03] <SwifT> but if you don't deviate from the default policy available, it works pretty well [21:51:17] <blueness> back [21:51:25] <blueness> (sorry) [21:51:32] <SwifT> i've been working ogether with the ima folks to support custom policies too (so that we an integrate selinux and ima better) and we have a nice fix, but it was too late for inclusion in 3.8 [21:51:54] <SwifT> in hardened-dev, you'll find ima-evm-utils package with the necessary userland utilities as referenced in the docs [21:52:04] <SwifT> i'll move it to the main tree as soon as possible [21:52:43] <SwifT> so that's about it. I'm hoping to make a test vm soon with selinux, ima & evm enabled in enforcing mode for peple to play around with [21:52:52] <SwifT> (promises, promises, I know) [21:52:55] -*- blueness raises his hand [21:53:08] -*- SwifT points to blueness "speak and your mouth will open" [21:53:35] <blueness> SwifT, ty, i have a question about ima/evm and selinux integration, you are going to keep that optional, correct? [21:53:44] <SwifT> of course [21:53:54] <blueness> okay [21:54:17] <SwifT> ima/evm is a lot less hassle to work with/configure than selinux [21:54:19] <blueness> i'm wondering how this will work with grsec's srbac [21:54:23] <blueness> rbac [21:54:36] <SwifT> it shouldn't influence it at all afaik [21:54:45] <blueness> SwifT, that doens't say much everything is easier to configure that selinux! [21:54:53] <SwifT> ;) [21:55:15] <blueness> SwifT, well maybe we have to look at how rbac might hinder userland utilities from doing their thing [21:55:19] <SwifT> let's say I see no need to write a "IMA/EVM handbook" ;) [21:56:02] <blueness> SwifT, i haven't looked at ima/evm at all, but i remember tripwire + rbac were messed up [21:56:21] <SwifT> blueness: probably because tripwire is a userland utility, so rbac applies to it [21:56:24] <blueness> if you had had tripwire reading large numbers of system binaries then that had to be learned etc etc [21:56:47] <blueness> okay now my ignorance of ima/evm is showing, is there NO userland utility at all? [21:56:59] <SwifT> not for validating integrity or enforcing it [21:57:16] <blueness> SwifT, nice i look forward to using it [21:57:42] <SwifT> there are only userland utilities for generating digital signatures once, or generating hashes if for instance you aren't running an IMA kernel at the point you want to register the hashes [21:58:31] <blueness> k one can turn off rbac learning for that one time stuff [21:58:51] <blueness> i like this already, maybe we'll document a section on best practices with rbac [21:59:03] <SwifT> yes, please document it ;) [21:59:25] <blueness> okay i'm done [21:59:32] <prometheanfire> blueness: eudev meeting? [21:59:45] <Zorry> 4.0 Profiles then? [21:59:47] <blueness> prometheanfire, after profiles [21:59:56] <blueness> okay this is quick ... [22:00:23] <blueness> 1) i've marked all ...hardened.../{desktop,server,developer,minimal} profiles as deprecated [22:00:43] <blueness> only Zero_Chaos complained afaik [22:00:56] <blueness> but it was getting crazy [22:01:20] <blueness> i'm thinking after the pax xattr migratino is done, i'll work with scarabeus to try to "shallow up" all our profiles [22:01:21] <blueness> so [22:01:36] <blueness> users will be albe to manually add stacks in /etc/profiles somehow [22:01:54] <blueness> ie, have their own parent [22:02:16] <blueness> i'm not sure yet, but the deep profile structure we have is a problem .... which leads to my next point ... [22:02:21] <blueness> 2) the 13.0 profiles [22:02:50] <blueness> so there's no easy way to add them because all inheritance of profiles goes through hardened/linux [22:03:01] <blueness> and that inherits directly from 10.0 [22:03:38] <blueness> so its not like i can avoid that without creating a parallel structure which means repeating profile stuff at another level :( [22:03:51] <blueness> so [22:04:07] <blueness> i think just for testing purposed i'll create a hardened/linux/13.0 [22:04:18] <blueness> i'll only support amd64 and x86 under there [22:04:43] <blueness> these will have some duplicate profile structure from hardened/linux/{amd64,x86} [22:04:59] <blueness> i will NOT add them to profiles.desc so they don't show up in eselect profile [22:05:04] <blueness> i will call for testing [22:05:31] <blueness> then in about 6 months i will just change all our profiles, one shot, from 10.0 to 13.0 in hardened/linux/parent [22:05:44] <blueness> and deprecate/remove hardened/linux/13.0 [22:05:56] <SwifT> +1 from me on that [22:06:03] <prometheanfire> yep [22:06:06] <blueness> the big difference will be EAPI=5 is required for 13.0 so we need to make sure we're all on EAPI=5 [22:06:26] <Zorry> yep [22:06:28] <blueness> okay, its not the best but there's no way around this issue [22:06:39] <SwifT> not EAPI=5 required, a package manager that supports EAPI=5 is required iirc [22:06:44] <blueness> if we're all okay with that, i'll implement it starting today [22:06:50] <ryao> How is the EAPI=5 requirement enforced? [22:06:53] <blueness> SwifT, that's what i meant [22:06:59] <blueness> ryao, no idea! [22:07:18] <SwifT> it just masks out package manages that don't support EAPI=5 [22:07:22] <blueness> um ... just remove portage ebuild that doesn't support it i guess [22:07:35] <blueness> SwifT, right [22:07:36] <prometheanfire> SwifT: lolnope [22:07:45] <prometheanfire> oh, managers [22:07:47] <prometheanfire> ya :D [22:08:00] <SwifT> ya, my an away [22:08:14] <blueness> okay i'm done [22:08:14] <SwifT> i accidentally a lette [22:08:36] <Zorry> next then ? [22:08:39] <blueness> (i'll be jumping to eudev for that meeting ... there's nothing more for me to say really) [22:08:56] <Zorry> 6.0 Doc [22:08:58] <Zorry> blueness: okay [22:10:24] <Zorry> i don't have any thing new on Docs [22:10:27] <klondike> Nothing from me [22:10:31] <Zorry> SwifT: do you have anything? [22:10:35] <SwifT> blueness updated the various pax documents, and I noticed a few new stuff in hardenedfaq from Zorry and klondike :p [22:10:53] <SwifT> but no major changes other than the pax ones [22:10:55] <klondike> Yes because I'm that cool :P [22:11:19] <SwifT> Zorry: nope, only smaller changes on selinux and integrity (sais cvs ;) [22:11:37] <Zorry> k [22:11:40] <klondike> SwifT: you have to teach me how you do that [22:12:26] <Zorry> next the? [22:12:37] <Zorry> 7.0 bugs [22:13:00] <SwifT> As I mentioned, I have a problem with bug #443630 [22:13:03] <willikins> SwifT: https://bugs.gentoo.org/443630 "SELinux + >app-emulation/libvirt-0.9.13-r1 - Segfault starting qemu domains."; Gentoo Linux, Applications; UNCO; gentoo:selinux [22:13:19] <SwifT> libvirt, with selinux, is segfaulting, but I'm not able to test it out myself [22:13:36] <SwifT> I hope someone here has libvirt and selinux that can help in the bug? [22:14:11] <SwifT> if not, i'll need to talk the guy through using gdb for finding out the segfault, but the problem with gdb is that it disables selinux transitions (selinux behaves differently when using gdb) so it might not help at all [22:14:55] <SwifT> strace doesn't show much useful information either, and we've tried to enable most stuff (in policies) with no avail [22:15:56] <SwifT> no-one? *snif* [22:16:17] <prometheanfire> dunno what to say :( [22:16:28] <SwifT> "don't use libvirt" ;) [22:16:59] <Aleister> SwifT: need hardware to such testing :( [22:17:12] <blueness> klondike, SwifT the only thing about the docs is maybe we should clean up that front page [22:17:35] <SwifT> blueness: the hardened project page you mean? [22:17:35] <blueness> i was going to try to categorize the links to the subdocs better, but never did [22:17:46] <blueness> SwifT, yeah we have all those links at the bottom [22:17:59] <blueness> might be nice to categorize and indent the way we did with selinux [22:18:05] <blueness> err ... you did with selinux :) [22:18:08] <SwifT> blueness: yea, but I know there is some talk to move project pages to wiki.gentoo.org soon, so it might solve itself ;) [22:18:46] <klondike> Well now that you got that... [22:18:46] <SwifT> blueness: otherwise just create subprojects for grsec/pax and define the resources there, then they'll be indented automatically [22:19:22] <klondike> What do you think on moving userguides to wiki.g.o? I'd appreciate specially input from blueness [22:19:43] <blueness> klondike, move or duplicate? [22:19:49] <klondike> The idea is keeping technical doc in project space and the userguides in userspace since they may benefit [22:19:53] <SwifT> i don't like duplication... so "move" ;) [22:20:08] <blueness> hmm ... [22:20:12] <blueness> yeah maybe [22:20:14] <klondike> blueness: move and keep a link to the last "reviewed" version on project page [22:20:34] <klondike> The idea is allowing users to fix small issues that may arise [22:21:05] <blueness> i'm okay with that, i'm a wiki fan [22:21:27] <blueness> like i don't want to fix every tiny typo i make, users should be allowed that [22:21:40] <klondike> So since the rest of the team seemed to be okay, any complaints? [22:21:45] <prometheanfire> non [22:22:04] <klondike> blueness: I think we can benefit even more since users can add how they fix the corner cases they hit [22:22:11] <SwifT> no complaints here either [22:22:26] <SwifT> I can move stuff like selinux-faq to the wiki quickly [22:22:41] <blueness> klondike, go ahead and spearhead that, what would you need from me? [22:22:49] <klondike> blueness: nothing [22:22:57] <klondike> SwifT: has all the tools needed [22:23:23] <klondike> Just wanted the blessing from pappa hardened blueness ;) [22:23:39] <blueness> klondike, go with pax my son! [22:23:40] <Zorry> do it [22:23:48] <SwifT> yeah, I have a guidexml2wiki stylesheet here... just needs a few more hours of love to fix some formatting, but i've used it succesfully to move some other guidexml docs to wiki already [22:24:29] <klondike> Cool [22:24:31] <SwifT> see gxml2wiki.xsl at https://github.com/sjvermeu/small.coding/tree/master/gxml2docbook [22:24:59] <SwifT> too many ideas, too many unfinished projects :p [22:26:01] <klondike> SwifT: I use a note file for this stuff [22:27:18] <Zorry> docs and bugs done? [22:27:25] <klondike> yes [22:27:37] <Zorry> 8.0 Media then [22:27:59] <klondike> Ohh that's a me [22:28:10] <klondike> Saddly hypertasking didn't allow me to tweet the meeting [22:28:27] <klondike> Instead I'll prepare and send the highlights to the mailing list later today [22:28:45] <Zorry> k [22:28:52] <klondike> The idea is doing that from now on since that is easier to do than plains logs and easier to read for most users [22:29:10] <SwifT> klondike: i'll have them in a blog post in a minute or so as well ;) [22:29:34] <klondike> Going back to the talk at FOSDEM as I think all except blueness and lejonet know it was a huge success [22:29:41] <klondike> We had a lot of interested people [22:29:52] <ryao> klondike: In Hardended? [22:29:54] <klondike> And I think we had a really productive roundtable [22:29:59] <blueness> klondike, can you post links to all the talks? [22:30:03] <blueness> well all our talks [22:30:04] <klondike> ryao: yes, hardened [22:30:30] <ryao> klondike: Cool. [22:30:35] <klondike> So shall we go for a fast 30 minute talk "What have we changed since last year" and another round Table next year? [22:30:48] <Zorry> sound fine by me [22:31:28] <SwifT> perhaps more focus on what has changes (ooo, new and shiny) versus the introduction? 'cause now it was almost 45 minutes introduction ;) [22:31:48] <klondike> SwifT: the idea is having 30 minutes what has changed :P [22:31:54] <klondike> And no intro anymore [22:32:09] <SwifT> fine by me, yes [22:32:36] <Aleister> having a nice selinux twist on the whole talk wouldnt be bad SwifT :) [22:32:56] <klondike> What has changed: SELinux is now cool :P [22:33:07] <SwifT> yes, yes, I know [22:33:15] <Aleister> kinda like selinux is not only a RH thing .... [22:33:15] -*- blueness has to go ... bye bye [22:33:17] <ryao> klondike: Cooler than PaX/GrSecurity? [22:33:21] <prometheanfire> blueness: cya [22:33:21] <SwifT> bye blueness [22:33:29] <klondike> ryao: they are not conflicting [22:33:31] <ryao> blueness: Bye. [22:33:39] <klondike> I got that same question in the round table [22:33:45] <ryao> klondike: I thought that you didn't need SELinux if you had GrSecurity. [22:34:01] <klondike> ryao: only if you use RBAC [22:34:10] <klondike> or RSBAC not sure how the grsec one is called [22:34:12] <SwifT> they're complementary... even RBAC and SELinux have some good use together [22:34:19] <ryao> Cool. [22:34:22] <klondike> Anyway any other questions? [22:34:29] <SwifT> yeah, I miss between those too often as well... RS?BAC ;) [22:34:55] <klondike> Zorry: for me we can go to next then [22:35:16] <ryao> Does Gentoo Hardened have any protection against RoP attacks? [22:36:30] <SwifT> is that like ret2libc? [22:36:55] <prometheanfire> I think klondike mentioned we help protect against it [22:37:45] <klondike> ryao: yes we do [22:37:54] <klondike> It used to be called ret2libc earlier [22:38:10] <klondike> Basically canaries and ASLR help against them [22:38:22] <klondike> If you want the details ask after meeting [22:38:38] <Zorry> next then [22:38:46] <Zorry> 9.0 Open floor [22:39:17] <Zorry> any thing else the meeting is done [22:39:24] <Zorry> ty all for the meeting
