Agenda for meeting 2014-01-23 20:00UTC and log from last meeting 2013-12-19 20:00UTC

[21:16:00] <Zorry> 1.0 Toolchain
[21:16:15] <Zorry> not that much new stuff
[21:16:54] <Zorry> will fix up some patches so we can enable ssp as default in the toolchain
[21:17:41] <Zorry> blueness: do you have annything?
[21:17:52] <blueness> not really
[21:18:14] <blueness> i've just been maintaining the uclibc stags, but nothing new
[21:18:42] <blueness> i do have a question though
[21:18:57] <Zorry> go
[21:19:00] <blueness> so asan stuff, still the same situation as last month?
[21:19:06] <Zorry> yes
[21:19:11] <blueness> okay
[21:20:02] <alsoSwifT> next?
[21:20:06] <Zorry> next
[21:20:06] <blueness> yes next
[21:20:23] <Zorry> 2.0 kernel Grsec/PaX
[21:20:41] <blueness> okay a few things
[21:20:43] <prometheanfire> people are asking, so I'll ask
[21:20:44] <prometheanfire> lts?
[21:20:56] <blueness> not sure
[21:21:15] <prometheanfire> just wanted it official, thanks
[21:21:27] <blueness> 3.12 is lts at kernel.org but i don't know whether or not spender will maintain it lts
[21:21:40] <blueness> err .. wait no
[21:21:48] <prometheanfire> upstream goes off of ubuntu lts
[21:22:04] <blueness> 3.10 is lts and it is not maintained by grsec pax
[21:22:11] <blueness> whether 3.12 will be i 'm not sure
[21:22:37] <blueness> okay let me get my couple of points out
[21:22:45] <blueness> 1) grsec-3.0 is out
[21:23:00] <alsoSwifT> \o/
[21:23:07] <blueness> the latest kernels are grsec-3.0, and they require gradm-3.0
[21:23:32] <blueness> it was a rough start but the kernels in the tree now are okay for at least testing
[21:23:36] <blueness> earlier once were panicking
[21:23:53] <blueness> i'll be stabilizing one of ht elast 2.9.1's in a few days
[21:24:22] <blueness> 2) install.py wrapper.  i've started work on the c wrapper version of that
[21:24:33] <prometheanfire> I'm running 3.12.4 without issue (without grsec rbac)
[21:24:43] <blueness> becuase install.py is too slow for large number of files
[21:25:05] <blueness> so i'm hoping by next month i can get the portage team to switch out install.py for my compiled version
[21:25:17] <blueness> the compiled version should be much faster
[21:25:32] <blueness> but i won't know for sure until i've finished writing it
[21:25:54] <blueness> hi pipacs
[21:26:00] <blueness> okay that's it for me
[21:26:03] <blueness> questions?
[21:26:03] <Zero_Chaos> sorry, internet bad at 587mph.
[21:26:06] <pipacs> evening, sorry for being late
[21:26:12] <Zorry> pipacs: np
[21:26:21] <blueness> pipacs, no problem i just menitons spender's up to grsec-3.0
[21:26:23] <pipacs> but let me know if i was needed for something ;P
[21:26:25] <blueness> mentioned
[21:26:52] <blueness> pipacs,  do we know the next lts after 3.2?
[21:27:06] <blueness> lts both kernel.org lts + grsec/pax lts
[21:27:18] <pipacs> not yet, we try to follow ubuntu lts, which at the moment looks like to be based on 3.13 or perhaps 3.14
[21:27:40] <blueness> yep
[21:28:00] <blueness> okay i'm finished if there's nothing more
[21:28:24] -*- blueness runs downstairs for a hot cup of coffee
[21:28:31] <Zorry> next
[21:28:49] <Zorry> 3.0 SeLinux
[21:29:09] <alsoSwifT> our live policies are well uptodate with upstream, and i pushed out rev 5 to the tree a few days ago
[21:29:11] <prometheanfire> steev: arm status?
[21:29:37] <alsoSwifT> also, we have the latest userspace in the tree as well
[21:29:38] <steev> arm status is that i need to test a few other machines, but it works afaict, which, i still haven't finished swift's book so i'm not 1000% sure
[21:30:03] <alsoSwifT> steev: well, once its finished give me a hurl and I'll tag all selinux packages for arm
[21:30:20] <steev> need to keyword it though, and i should ask the other arm team members about it, since i do believe it will require setting the policy version manually
[21:30:22] <alsoSwifT> i'm still hoping to have an arm system for me by the end of next week as well for teting
[21:30:26] <steev> since arm kernels tend to be... older
[21:30:26] <Hello71> *holler?
[21:30:47] <alsoSwifT> we can document that (the version thingie)
[21:30:50] <steev> alsoSwifT: i can give you access to one, if you don't have any (and please please, tell me you're getting a real arm system, and not an rpi and calling it an arm system)
[21:31:03] <prometheanfire> zfs also seems to work now, the patchset is in (as of about an hour ago)
[21:31:14] <alsoSwifT> it's a ubiquity or whatsitcalled
[21:31:22] <prometheanfire> I need to submit a patch to refpol, but it's simple
[21:31:28] <steev> ubiquity is a wifi dongle
[21:31:35] <alsoSwifT> ah something else then :p
[21:31:37] <steev> parallax thingie?
[21:31:51] <steev> http://www.parallella.org/ ?
[21:32:02] <alsoSwifT> i'll get back on you later what it is- don't have the papers here atm
[21:32:07] <alsoSwifT> not parallella, nox
[21:32:15] <steev> ok
[21:32:30] <alsoSwifT> anyway, userspace utils are in tree, upstream was quite happy to take a lot of our patches in
[21:32:36] <steev> good eal
[21:32:37] <steev> deal*
[21:32:53] <alsoSwifT> so the latest upstreamonly has a very few gentoo-specifics in in (mainly sandbox -> sesandbox stuff)
[21:33:15] <alsoSwifT> i do need to stabilize the r5 policies before userspace stabilization as there are changes in behavior that need to be allowed
[21:33:28] <alsoSwifT> but that shouldn't be a problem
[21:33:42] <steev> alsoSwifT: it should be noted that for arm, very few things are/have been tested/installed
[21:33:48] <steev> but the basics definitely seem to work
[21:33:58] <alsoSwifT> as a last point, the selinux eclass was also updated to allow for live ebuilds from the HTTP git interface (got a bug on that)
[21:34:09] <prometheanfire> nice
[21:34:25] <alsoSwifT> steev: that's ok, i'm notgoing to mark it arm-stable (i don't even think there is an arm-stable keyword)
[21:34:47] <steev> arm does stable, yes
[21:35:36] <blueness> back
[21:35:53] <alsoSwifT> that's it for selinux
[21:36:00] <alsoSwifT> (from my ppart)
[21:36:01] <prometheanfire> done here as well
[21:36:15] <steev> done too i guess
[21:36:27] <blueness> alsoSwifT, i didn't know you were moving for arm
[21:36:35] <blueness> i can help there, i've got some arm devices
[21:36:54] <alsoSwifT> i know, i just need to find more free time ,) devices isn't an issue
[21:37:02] <blueness> what i?
[21:37:04] <blueness> what is?
[21:37:08] <steev> TIME
[21:37:11] <steev> as always
[21:37:26] <alsoSwifT> yes
[21:37:37] <alsoSwifT> and preferably before noon :p
[21:37:41] <alsoSwifT> otherwise i'm too tired
[21:37:42] <blueness> what is the tehcnical issue?
[21:37:50] <blueness> do we need testing?
[21:38:10] <steev> blueness: after the meeting
[21:38:17] <blueness> steev, k
[21:38:21] <blueness> neeeext!
[21:38:57] <Zorry> 4.0 System Integrity
[21:39:05] <alsoSwifT> nothing major here; ima/evm still work well on the 3.11 kernel series, as does signed kernel module support
[21:39:23] <alsoSwifT> no upstream changes, so not that much work beyond maintenance ;)
[21:40:07] <blueness> alsoSwifT, what's required there
[21:40:13] <alsoSwifT> i'm going to work on a gentoo security benchmark (using SCAP) in the next few days, you'll see lots of blog posts pertaining to it
[21:40:42] <alsoSwifT> it's mostly regression testing with IMA/EVM, checking that TPM drivers still work, policies still load, etc.
[21:40:54] <blueness> i see
[21:40:59] <alsoSwifT> but ever since 3.8 i had no problems with it
[21:41:09] <alsoSwifT> almost boring
[21:41:11] <alsoSwifT> :)
[21:41:38] <alsoSwifT> that's it for integrity from me
[21:41:57] <Zorry> next?
[21:42:18] <Zorry> 5.0 Profiles
[21:42:26] <blueness> okay
[21:42:36] <blueness> i looked into the destkop profile issue
[21:43:05] <blueness> and i think the best thing, if we want is to maintain a second set of "target" profiles ourselves
[21:43:13] <blueness> so to remind you of the issue
[21:43:28] <blueness> Zero_Chaos, wants to reindroduce hardened/amd64/dekstop
[21:43:35] <blueness> also x86 and arm
[21:43:57] <Zero_Chaos> I would prefer to fix the bug in portage which breaks the profiles in an insane fashion
[21:44:02] <blueness> but the way inheritance works it either puts default/targets after hardned
[21:44:03] <Zero_Chaos> rather than have our own
[21:44:14] <blueness> Zero_Chaos, actually that would be best
[21:44:37] <blueness> so can you spearhead that and see
[21:45:18] <blueness> in the mean time, i'm going to remove the ancient /developer and /server since there is no request for htose and they are deprecated since jan 2013
[21:45:25] <Zero_Chaos> blueness: yeah, just as soon as we have a portage maintainer again :-(
[21:45:27] <blueness> i'll leave /desktop pening
[21:45:30] <blueness> pending
[21:45:45] <Zero_Chaos> blueness: you can remove all the deprecated profiles imho, they do noone any good at this time.
[21:45:56] <blueness> Zero_Chaos, i did think of adding something like a cut
[21:46:03] <blueness> Zero_Chaos, okay i'll remove /desktop too
[21:46:27] <blueness> "cut" so imagine a syntax like ... !../../target/desktop
[21:46:30] <blueness> with an ! in front
[21:46:46] <blueness> which says inherit ../../target/desktop but no deeper than one level
[21:46:56] <blueness> i can see how to implement that in portage
[21:47:39] <blueness> that would allow you to stack profiles one level deep without inheriting all the way back to base each time
[21:47:46] <blueness> what do you think?
[21:47:59] <blueness> (the idea was inspired by prolog)
[21:48:06] <blueness> Zero_Chaos, ^^??
[21:48:11] <alsoSwifT> what about implementing desktop stuff as a profiles/features one?
[21:48:36] <blueness> alsoSwifT, well as long as we control it yes, like we did with selinux
[21:48:42] <Zero_Chaos> blueness: honestly if you look at the profile stacking order in your tests, the error makes no sensense at all.
[21:49:21] <blueness> Zero_Chaos, it is reproduceable and it does make sense because last profile wins
[21:49:49] <blueness> alsoSwifT, the issue with selinux was that it was orthogonal to the hardened stuff
[21:50:04] <alsoSwifT> ok
[21:50:07] <blueness> so adding it as a feature was perfect
[21:50:35] <Zero_Chaos> blueness: that's the thing, from the point where you edit the profile , the two profiles are identical. so in this case, the last profile isn't winning, something odd is happening
[21:50:38] <blueness> but with desktop we have USE flags, package maskings and package.use that are in conflict with what harened requires
[21:51:19] <blueness> alsoSwifT, damn lost him
[21:51:24] <blueness> Zero_Chaos, did you reproduce it?
[21:51:58] <Zero_Chaos> blueness: I haven'te even slept in 3 months honestly.
[21:52:21] <blueness> alsoSwifT, back to the orthogonality issue
[21:52:42] <blueness> the way selinux was stacking before lead to the US=mutlilib clash
[21:52:50] <blueness> we are in the same situation with the desktop profile
[21:53:38] <blueness> there are only two ways out: 1) fix portage to stop the recursive stacking so we have better control, 2) create our own hardened/targets that we manually keep orthogonal
[21:54:16] <blueness> but having the current stacking mix means that changes to the middle stacks will change the final profiles we push out without our control
[21:54:50] <blueness> which can break hardened user's systems even with the best of intentioned changes to the middle stack layers
[21:54:59] <blueness> dman lots swift again!
[21:55:30] <blueness> my last message to you
[21:55:38] <blueness> SwifT, which can break hardened user's systems even with the best of intentioned changes to the middle stack layers
[21:56:01] <blueness> SwifT, anyhow that's what happened with selinux + multilib the old way
[21:56:16] <SwifTy> but what do users expect from a "desktop" profile other than a few use flags?
[21:56:26] <blueness> a change in the middle layers after that stack had been set up cause selinux amd64 no-mutlilib to break without our having done anything
[21:56:49] <blueness> SwifT, there are some force used flags, eg libxml2 needs python use forced
[21:56:57] <Zorry> SwifTy: most use flags stuff
[21:57:15] <blueness> yeah but even the use flags are a problem, eg USE=jit or orc
[21:57:26] <SwifTy> right
[21:57:50] <SwifTy> features/hardened_desktop then p
[21:57:52] <SwifTy> ;p
[21:57:59] <blueness> SwifT, i really like the idea of fixing portage, but i think Zero_Chaos and I think there are different things to be fixed
[21:58:08] <blueness> SwifTy, that's what i was thinking
[21:58:18] <blueness> or profiles/hardened/targets
[21:58:23] <blueness> where we can put our own targets
[21:58:44] <blueness> SwifTy, 1 sec, let me show you the bug
[21:59:03] <SwifTy> blueness: i'm on cli only
[21:59:04] <blueness> bug #492312
[21:59:05] <willikins> blueness: https://bugs.gentoo.org/492312 "Reintroduce hardened desktop profiles"; Gentoo Linux, Eclasses and Profiles; CONF; zerochaos:hardened
[21:59:20] <blueness> SwifTy, ^^^ well there it is
[21:59:25] <SwifTy> i'll read up on it tomorrow when i draft up the blog post summarizing this meeting :)
[21:59:47] <blueness> SwifTy, yeah i was actually thinking of blogging about the profile stacking problem
[22:00:23] <blueness> SwifTy, anyhow there's a step-by-step example of reproducing the same error we had with multilb + selinux but, in my example, with libxml2 and python
[22:00:43] <Zorry> the stacking should support depend,before,after
[22:01:15] <blueness> Zorry, i'm not 100% sure i know what you mean
[22:01:30] <blueness> if you guys give me a clear idea of what might work, i can suggest patches to portage
[22:02:51] <blueness> Zorry, my one level deep idea would mean we could explicitly state the stacking order without the depth re-introducing stacks we don't want
[22:03:13] <Zorry> blueness: in the parent file you can define what stuff need to be after or before the inhrite or if it depend of some subprofile
[22:04:09] <blueness> Zorry, you mean something like services in openrc?
[22:04:18] <Zorry> yee
[22:04:43] <blueness> Zorry, okay people understand that logic already
[22:05:23] <blueness> Zorry, do you want to suggest it on the bug and I can try to hack something up for portage?
[22:06:08] <Zorry> will think of something this weekend
[22:06:17] <blueness> i can write code to do "before", "after", "depend" in python, that logic is easy, but i forsee two problems:
[22:06:34] <blueness> 1) how do we go from the current parent file to the new syntax?
[22:06:53] <blueness> 2) i don't know how to integrate stuff with portage easily, i need zac for that
[22:07:00] <blueness> and zac is MIA
[22:07:11] <Zorry> 1 bump of the 13 to 14?
[22:07:25] <blueness> even my install.py -> install (compiled C) is easy but how do I integrate it
[22:07:50] <blueness> Zorry, yeah but i think we will need some kind of tags so portage knows whether its reading the old style parent or new style
[22:08:16] <Zorry> yee something
[22:08:17] <blueness> this sounds like a long term project anyhow, so i'm sure we'll work that out in time
[22:08:27] <blueness> so syntax like ...
[22:08:41] <blueness> before {
[22:08:48] <blueness>     hardened/linux/amd64
[22:08:50] <blueness> }
[22:08:56] <blueness> after {
[22:09:06] <blueness>     default/linux/amd64
[22:09:07] <blueness> }
[22:09:12] <blueness> depends {
[22:09:13] <Zorry> something like that
[22:09:19] <blueness>     targets/desktop/gnome
[22:09:20] <blueness> }
[22:09:23] <blueness> Zorry, i like it!
[22:09:45] -*- blueness feels all warm and fuzzy inside working in a team that inspires!
[22:09:52] <lejonet> Verbose, so that anyone could understand it :) I agree with blueness, I like it :)
[22:10:14] <blueness> okay guys, pursue that avenue for next time!
[22:10:27] <Zorry> next topic?
[22:10:30] <blueness> in the mean time, i'll clean up the broken/deprecate stuff to clear out cruft
[22:10:38] -*- lejonet hands blueness the broom
[22:10:50] -*- blueness make lejonet do the sweepign!
[22:11:00] <lejonet> blueness: haha, more than fair enough :P
[22:11:40] <SwifTy> ok, next :)
[22:11:43] <Zorry> 6.0 Doc's
[22:12:14] <SwifTy> aha, well i noticed blueness doing some wikiwork - go blueness !!
[22:12:37] <blueness> SwifTy, please!
[22:12:46] <blueness> stop damagin my reputation, i don't do docs!
[22:12:55] <lejonet> haha
[22:13:16] <SwifTy> i haven't touched hardened docs lately though, been too busy with general wiki and handbook stuff
[22:13:24] <SwifTy> harhar
[22:13:58] <Zorry> next?
[22:14:03] <SwifTy> yup
[22:14:15] <Zorry> 7.0 Bugs
[22:14:34] <blueness> none worth mentioning
[22:15:14] <SwifTy> here either
[22:15:17] <prometheanfire> non
[22:15:25] <Zorry> webkit-gtk 2.0.4 have textrel on x86 and it is even on defult profile
[22:15:41] <blueness> Zorry, yeah
[22:16:13] <Zorry> will wait on 2.2 something to see if is still there
[22:16:15] <blueness> webkit-gtk has done some crazy stuff with .rb templates that's causing issues in uclibc too
[22:16:27] <blueness> Zorry, where are the textrels from, does it have asm?
[22:16:34] <blueness> err ... is it from the asm?
[22:17:20] <Zorry> haven't look that close where in the code it is
[22:17:45] <Zorry> just what function have it
[22:17:54] <Zorry> thw textrel
[22:17:59] <Zorry> the*
[22:18:32] <blueness> Zorry, okay, i might look since i just solved the isnan issue there
[22:18:49] <Zorry> !bug 483610
[22:18:52] <willikins> Zorry: https://bugs.gentoo.org/483610 "net-libs/webkit-gtk-2.0.4 - .../work/webkitgtk-2.0.4/tmp-introspectR49_vm/.libs/WebKit2-3.0: error while loading shared libraries: .../work/webkitgtk-2.0.4/.libs/libjavascriptcoregtk-3.0.so.0: cannot make segment writable for relocation: Permission denied"; Gentoo Linux, Hardened; CONF; email:hardened
[22:19:13] <blueness> k
[22:19:38] <Zorry> next?
[22:19:44] <blueness> yeah next, nothing more to say there
[22:20:05] <Zorry> 8.0 Media
[22:20:27] <blueness> nothing
[22:20:30] <blueness> from
[22:20:30] <blueness> me
[22:21:04] <SwifTy> nope
[22:21:26] <Zorry> next
[22:21:37] <Zorry> 9.0 Open floor
[22:21:52] <blueness> nothing, must run
[22:22:04] <Zorry> ty for the meeting