On Saturday 17 July 2010 02.39.27 Magnus Granberg wrote: > Hi > > Here is the log from the meeting we did have in > #gentoo-harde...@freenode.net. /Blueness Chainsaw Zorry
[00:40:21] <Zorry> 1.0 Toolchain [00:40:31] <Chainsaw> I assume Zorry has updates on this. [00:41:06] <Zorry> we have 4.5.0 4.4.1-r1 4.4.3-r3 with full support for glibc uclibc still mis the ssp support [00:41:18] <wao> cool [00:41:21] <wao> nice [00:41:37] <Chainsaw> Is the lack of uclibc support stalled on a maintainer? [00:41:42] <Chainsaw> Or on the availability of a patch? [00:41:57] <blueness> Chainsaw, there is a patch [00:42:08] <Zorry> waiting for for grub-0.97-10 to get stable req ~07-25 [00:42:22] <Zorry> Chainsaw: it is pach but it is hack [00:42:29] <Chainsaw> Zorry: Have you looked at grub 1.98 at all? [00:43:03] <Zorry> Chainsaw: have allrdy fixed the ssp/pie upstrem [00:43:08] <Zorry> on 1.98 [00:43:14] <Chainsaw> Zorry: Cool. [00:43:42] <Chainsaw> Zorry: And uclibc will require a "better" patch, so that is to follow at a later date. I think we're done on toolchain then. Good progress :) [00:43:42] <Zorry> the only thing left is the trampolines [00:44:06] <Zorry> Chainsaw: uclibc need to get tls nptl support [00:44:20] <Zorry> else ssp segfault [00:44:27] <Chainsaw> Ah, right. [00:45:08] <Zorry> it have repo with that support but i don't know when it get merge to main repo [00:45:23] <Chainsaw> Stalled waiting for upstream action. [00:45:29] <Zorry> yes [00:45:40] <Chainsaw> Okay, then I think we can move on to the kernel. [00:45:54] <blueness> Zorry, i'm still having problems with uclibc + latest hardened-gcc. i still get the -static problem [00:46:10] <blueness> i may have to open a bug to properly report my findings [00:46:18] <Zorry> will try to make stable req on gcc on -07-25 for 4.4.3-r3 [00:46:21] <blueness> but i'm hoping it will all go away when ntlp and tls is in [00:47:09] <Zorry> hope that to [00:47:28] <Zorry> do we have ny more stuff on the toolchain? [00:47:53] <blueness> mostly we're waiting [00:48:06] <Zorry> yes so next? [00:48:15] <blueness> okay next [00:48:21] <Zorry> 2.0 Kernel [00:48:29] <Zorry> Chainsaw: blueness [00:48:31] <blueness> okay [00:48:41] <blueness> we have 2.6.32-r9 based on vanilla 2.6.32.15 + genpatches + grsec-2.1.14 [00:48:50] <Chainsaw> Which is stable on AMD64, with no bricks through my windows yet. [00:49:06] <Chainsaw> Few arches passed on stabling it, which means dropped keywords later. [00:49:23] <blueness> we are shooting for full stabilization on that one because its the most mature grsec [00:49:36] <blueness> just waiting on x86 [00:49:45] <Chainsaw> I shall motivate them. [00:49:58] <blueness> there are a couple of bugs out, but they are minor with work arounds [00:50:16] <blueness> they should not stop stabilization [00:50:29] <blueness> we also have some other's i've put up. [00:50:38] <blueness> 2.6.32-r10 based on vanilla 2.6.32.15 + genpatches + grsec-2.2.0 [00:50:43] <blueness> 2.6.32-r11 based on vanilla 2.6.32.16 + genpatches + grsec-2.2.0 [00:50:49] <blueness> 2.6.34 based on vanilla 2.6.34.1 + genpatches + grsec-2.2.0 [00:51:00] <blueness> the last one is p.masked [00:51:37] <blueness> upstream is moving fast, and they are getting a lot of bug reports from gentoo users which is helping them get grsec-2.2.0 cleaned up [00:53:10] <blueness> after stabilization of 2.6.32-r9 we should thing about cleaning out some of the older kernel sources [00:53:27] <Chainsaw> Indeed, anything <2.6.32-r9 can then go. [00:53:28] <blueness> kerframil notes that some of them have known security issues [00:53:49] <Chainsaw> I know of none that are actually exploitable under AMD64 with hardening enabled though. [00:54:06] <blueness> Solar wants to keep 2.6.28-r9 because of its longevity [00:54:23] <Chainsaw> I'd prefer to see it go. [00:54:32] <prometheanfire> keyword it? [00:54:54] <blueness> prometheanfire, no. either it stays or goes [00:55:42] <Chainsaw> prometheanfire: No keywording. Killing. With fire. [00:56:19] <kerframil> blueness, nothing before 2.6.32 is worth bothering with in my view. 2.6.32.x is slated for long-term support through both avenues of upstream [00:56:30] <prometheanfire> don't know if it maters, but 2.6.28-r9 will fail to boot as a kvm guest with newer kvm [00:56:51] <blueness> prometheanfire, it does matter. people want that [00:58:05] <blueness> Chainsaw, one question for you about how to approach the issue that grsec/pax move so fast [00:58:25] <blueness> on the one hand gentoo users do lots of testing so we want to have ~arch kernels in the tree [00:58:42] <Chainsaw> blueness: Don't indulge cilly where you feel it is not required. [00:58:44] <blueness> but at the same time we don't want to fill the tree with frivolous ebuilds [00:58:50] <blueness> lol right [00:59:25] <Chainsaw> blueness: I would say one -r per vanilla kernel bump (2.6.32.x to 2.6.32.y) unless something special occurs. [00:59:33] <Chainsaw> blueness: That should keep the number of bumps to a reasonable level. [00:59:35] <blueness> so ... i'll make some judgement about when i think kernels are testable, put them in ~arch, but these may never be put up for stabilization, we'll just kill them as needed [00:59:49] <blueness> Chainsaw, yes, i agree one -r per vanilla [01:00:01] <blueness> i've been doing one -r per vanilla OR grsec bump [01:00:06] <Chainsaw> blueness: Let's keep to that, and be specific about what we stable. [01:00:25] <kerframil> blueness, notwithstanding any bugs that look like they may be addressed by a grsec patch bump I suppose (if anyone feels like trying to fathom an interdiff and putting it to the test) [01:00:31] <blueness> exactly, 2.6.32-r9 is a good point because grsec-2.1.14 matured [01:02:00] <blueness> k i think i'm done with kernel. i want to thank prometheanfire for helping testing with 2.6.34. i know people want it, but hardening it had issues [01:02:31] <blueness> namely bug #328275 [01:02:34] <willikins> https://bugs.gentoo.org/328275 "sys-kernel/hardened-sources-2.6.34 too much early reserved memory with CONFIG_NO_BOOTMEM=y"; Gentoo Linux, Hardened; NEW; bluen...@g.o:hardened-ker...@g.o [01:02:44] <blueness> anything more about kernel? [01:02:56] <Chainsaw> Not from me, no. I'm happy with the progress made :) [01:03:02] <Zorry> not what know [01:03:12] <Zorry> next then? [01:03:14] <Chainsaw> Profiles? [01:03:22] <Zorry> 3.0 profiles [01:03:29] <Zorry> blueness: [01:03:47] <blueness> i updated the profiles on the hardened-dev overlay, rebasing them against what's in the tree [01:04:03] <blueness> i have to add one more mask --- from me actually and then the two are in sync [01:04:04] <blueness> but [01:04:21] <blueness> we have yet to test and then announce and then put them in the tree [01:04:57] <blueness> i have to admit that the profile stuff has complex parent structure, and i'm not 100% sure why it works. [01:05:05] <blueness> gengor assures me it is correct though [01:05:25] <blueness> should we plan to test the profiles and then make the move to add? [01:05:34] <Zorry> it hard to follow all the parent [01:05:57] <blueness> Chainsaw, maybe i should bring you up to date on this. gengor wanted to eliminate the /10.0/ from the profiles [01:05:57] <Zorry> test and do the -dev lm stuff [01:06:04] <blueness> go to a releaseless profile structure [01:06:26] <blueness> Zorry: okay i'll test this week [01:06:34] <Chainsaw> blueness: I heard of that effort, yes. [01:07:14] <Zorry> blueness: will se if a can test soem of it to [01:07:27] <blueness> yes please [01:07:59] <blueness> one more issue with hardened profiles. i discovered that we share a changelog with all profiles! /usr/portage/profiles/ChangeLog [01:08:05] <blueness> isn't that a little crazy? [01:08:14] <blueness> can indivitual profiles have their own? [01:08:52] <blueness> just an aside thought [01:09:30] <Zorry> do we have any more on the profiles? [01:09:43] <Chainsaw> It makes sense to keep a global changelog, even if does get a bit long. [01:09:57] <blueness> Chainsaw, okay [01:09:58] <Chainsaw> (You can keep it manageable by doing all your changes and only then calling echangelog) [01:10:44] <blueness> Chainsaw, well that was the problem i think. if you make a full blown restructuring to your profile, it may get too much to read [01:11:06] <blueness> done with profiles [01:11:13] <Zorry> okay [01:11:30] <Zorry> 4.0 docs [01:11:44] -*- blueness runs [01:11:47] <Zorry> haven't done anything more on that stuff [01:12:08] <blueness> what happened to klondike's work? [01:12:53] <Zorry> we have the work but most lack of time :( [01:13:28] <blueness> I got involved with Anarchy in openrc too [01:13:37] <Zorry> have seen that [01:13:55] <blueness> and maintaining two other packages that people wanted (and I wanted) [01:14:04] <blueness> but they are easy [01:15:17] <Zorry> add doc to staff-needed page ? [01:15:29] <blueness> what we probably need to do is reread the documentation that's there, remove whats old and add whats new rather thant trying to start from scratch [01:15:55] <blueness> Zorry, yes, but the problem is the only people who can write the docs don't want to, they want to do the work [01:16:17] <blueness> its more fun hacking than writing about hacking :P [01:16:25] <Zorry> +1 [01:16:54] <blueness> but we need to be disciplined. i'll try to reread all the hardened docs again and get a clear picture in my mind of what's there [01:16:59] <blueness> see what's old [01:17:16] <blueness> i liked klondike's stuff, just need to figure out where to start putting it [01:18:21] <kerframil> blueness, not everyone is a docbook afficionado either (is there a decent toolchain? I vaguely recall seeing a link in #gentoo-dev for some ajax app) [01:19:07] <Zorry> like it to but most of we are cout up in work with ather stuff [01:19:22] <Zorry> that need to be fixed before [01:19:31] <prometheanfire> blueness: are we gonna be adding docs to the official gentoo wiki? [01:19:49] <blueness> prometheanfire, that's the hope [01:20:21] <blueness> well not wiki [01:20:32] <blueness> the afficial site [01:2[01:21:38] <prometheanfire> the wiki from #gento-wiki , not gentoo-wiki.org.com [01:22:49] <Zorry> wiki -> the proj docs [01:23:37] <blueness> where shoudl it go guys -> http://www.gentoo.org/proj/en/hardened/ [01:23:39] <blueness> ? [01:23:50] <Zorry> yes [01:25:00] <prometheanfire> Official Gentoo Wiki Project | http://www.gentoo.org/proj/en/wiki/ | testing at http://gentoowiki.a3li.li/ [01:25:38] <blueness> you can stage the docs on the wiki and then we'll put htem on the official site [01:26:17] <Zorry> blueness: that is was i was thinking of [01:26:19] <kerframil> blueness, for the record, its name is (or was) beacon [01:26:56] <blueness> kerframil, sorry what are you referring to? [01:27:22] <kerframil> blueness, a snazzy visual guidexml/docbook editor that I recall seeing a link to in the #gentoo-dev topic some time ago [01:27:38] <blueness> ah [01:30:11] <blueness> okay anything more guys? [01:30:28] <Zorry> not from me [01:30:28] <Chainsaw> Not from me. [01:30:32] <Chainsaw> I really could do with some sleep actually. [01:30:39] <Chainsaw> So if there is nothing more... permission to log off? [01:30:41] <prometheanfire> nope [01:30:44] <blueness> okay one more item [01:30:45] <Zorry> okay to put the log on -hardened ml ? [01:30:46] <blueness> 5. Sleep [01:30:56] <Chainsaw> Zorry: Yes. [01:30:58] <blueness> Zorry, it worked having the meeting here [01:31:21] <Zorry> next meeting about 4 weeks same time [01:31:46] <Zorry> meeting done
