Here is the meeting log form the meeting. /Magnus
[22:06:13] <Zorry> 1.0 Toolchain [22:06:20] <lejonet> siiigh, my shell server is down... still... [22:06:45] <Zorry> h-s 3.4.3 works now with gcc 4.7 [22:07:05] <Zorry> else it looking good [22:07:26] <Zorry> 1.1 Gcc upstrem [22:08:12] <Zorry> have i ide hove to adde the needed specs to gcc and that is with driver_self_specs [22:08:44] <Zorry> blueness: and me have testing it and it works fine so far [22:08:48] <Zorry> but but [22:09:30] <Zorry> the prob is that all the hardenedno* and vannila don't work [22:10:08] <Zorry> so we can go two ways [22:10:40] <Zorry> 1. don't use hardenedno and vannila any more [22:11:45] <Zorry> 2. fix the needed specs rules so it still works as it do now don't use driver_self_specs as upstrem [22:12:33] <Zorry> on 2 we need to fix the no-shared spec for mips and mayby some more arch [22:13:23] <Zorry> blueness: some thouts? [22:13:55] <blueness> Zorry, i can live with 1. we can always turn off on a per package basis with -nopie or -fno-stack-protector [22:14:23] <blueness> but i don't know who else it might hurt, i should speak with Sabayon that uses both full hardened and -vanilla specs [22:14:42] <Zorry> blueness: was thinking to post to the ml later on [22:14:54] <blueness> yes, let's open the discussion to the community [22:15:08] <Zorry> for we can still do the way we do now [22:15:36] <Zorry> and do upstream diffrent way [22:15:37] <blueness> but it will be easier to follow upstream driver_self_specs [22:16:23] <Zorry> yep [22:16:50] <blueness> so i'm for 1, but we must see what the consequences are [22:17:23] <Zorry> that way we discuss it here and then on the ml [22:17:25] <Dwokfur> try to be as close to upstream as possible IMHO [22:19:04] <schmitt953> it would be sad to reduce functionality though it is difficult afaik to maintain vanilla when we can't control it [22:19:42] <schmitt953> blueness: with standard hardened would -nopie then be required on some packages or only with hardenedno and vanilla? [22:19:58] <Zorry> driver_self_specs is calld in gcc.c line ~6260 [22:20:00] <blueness> schmitt953, we try to get the right flags into the build systems [22:20:14] <Zorry> and defined gcc/config/arch [22:20:33] <schmitt953> alright, because when people run hardened they usually expect pie, at least I think they do [22:21:25] <Zorry> schmitt953: if we have the code in gcc upstream we can poke manitener of the package upstream that it don't work [22:21:48] <blueness> Zorry, let's see where the discussion goes on the ml, i recommend [email protected] to get more people involved [22:21:55] -*- klondike is a bit lost here [22:22:12] <Zorry> blueness: we can cross post [22:22:12] <blueness> klondike, Zorry has two ways of doing hardened specs [22:22:18] <klondike> Zorry: what's driver_self_specs? [22:22:36] <blueness> a function call in gcc that allows you to set specs [22:22:52] <klondike> Hum [22:23:02] -*- Dwokfur is also lost a bit [22:23:06] <klondike> So zorry what's the problem with driver_self_specs? [22:23:21] <Dwokfur> pie is an expectation when it comes to hardened [22:23:46] <klondike> I mean yeah we get no hardenedno* and vanilla profiles but, why? [22:23:52] <Zorry> klondike: we can't use the hardenedno* spec to disable [22:24:10] <klondike> But why can't we Zorry? [22:24:21] <Zorry> klondike: is is to erly in the gcc code [22:24:41] <klondike> So? [22:24:45] <Zorry> and it don't show up on dumspecs [22:25:12] <klondike> You mean the profiles added with driver_self_specs? [22:25:21] <klondike> Ehum, the specs [22:25:35] <Zorry> will be added with that [22:25:45] <Zorry> and it is the rigth way to do it [22:26:02] <klondike> Aha [22:26:34] <Zorry> it process the specs and adding any new options to the end of the command line [22:26:46] <klondike> But I still can't see it, what has to see the fact that the spec is loaded to early in the code with the fact that we lose the gcc profiles? [22:26:53] <Zorry> as we do now but alot later in the code [22:27:27] <Zorry> and that make mips no-shared spec fail [22:27:37] <blueness> yep [22:27:41] <klondike> Hum [22:27:51] <Zorry> or any thing that use the driver_self_specs [22:28:12] <klondike> So our current method breaks driver_self_specs? [22:28:17] <Zorry> yes [22:28:42] <Zorry> but only mips brake [22:28:46] <klondike> Aha [22:28:57] <Zorry> is the only one that have some pie/pic stuff in the specs [22:29:03] <Zorry> so far [22:29:09] <blueness> 32-bit mips breaks because it forces pie in places where long jumps are no possible [22:29:19] <blueness> so you get jumps longer than 32k [22:29:26] <klondike> So Zorry why the new method misses the hardenedno and vanilla profiles? [22:29:31] <blueness> yes [22:29:38] <blueness> it cannot do those right [22:30:12] <Zorry> klondike: the changes specs is not loaded so it use what is in [22:30:32] <klondike> Aha now I see [22:30:34] <Zorry> that is in hardenedno* and vannila [22:30:34] <blueness> yeah that's the criticla point ^^^ [22:30:55] <klondike> Can't we try to use driver_self_specs ourselves? [22:31:29] <Zorry> we are doing it on the 0.5.4 piepatchset blueness use for mips [22:32:42] <blueness> Zorry, this will be a long discussion, should we move on to other agenda items and continue the talk on the ml [22:32:44] <klondike> Ohh so the problem is driver_self_specs loaded specs can't conflict? [22:33:19] <Zorry> klondike: cantä be change on runtime [22:33:26] <Zorry> can't* [22:33:34] <Zorry> blueness: yes [22:34:03] <Zorry> 1.2 arm/mips/uclibc [22:34:07] <Zorry> blueness: ^^ [22:34:09] <klondike> Hum but Zorry but if we load a file why can't we just use symbolic links? [22:34:34] <blueness> guys, i have lots so i wrote out a summary which I will email alter -> http://dpaste.com/764530/ [22:34:42] <blueness> let me just summarize very quickly [22:34:54] <klondike> okey, maybe I'll ask later on private and in swedish to understand [22:35:18] <blueness> with Zorry's help i've been working on porting hardened to minor arches and uclibc [22:35:24] <blueness> this is for systems like these -> [22:35:25] <Zorry> klondike: all specs is hardcoded [22:35:34] <blueness> http://www.genesi-tech.com/products/smartbook -> armv7a-hardfloat [22:35:40] <blueness> http://routerboard.com/RB450G -> 32-bit big endian mips, abi = o32 [22:35:45] <blueness> http://routerboard.com/RB1100AHx2 -> 32-bit ppc, abi = classic [22:36:27] <blueness> i've been building stage4s which are currently at http://opensource.dyc.edu/pub/ but which i will move to the repository in experimental [22:36:58] <blueness> but first i must start using all the tree ebuilds and currently i have some stuff on hardened-dev::uclibc ovleray [22:37:10] <blueness> quick summary on the systems done: [22:37:27] <blueness> armv7a-hardfloat + glibc hardened - no problem [22:37:49] <blueness> mips64el + glibc hardened - no problems this is for the lemote.com netbooks [22:38:08] <blueness> amd64/i686 + uclibc hardened - no problems [22:38:38] <blueness> big endian mips + uclibc hardened - the above mentioned driver_self_specs issue [22:38:54] <blueness> armv7a + uclibc hardening - work in progress [22:39:22] <blueness> ppc + uclibc - even the vanilla is a problem! with out-of-line use of registers by gcc [22:39:33] <blueness> and finally [22:39:53] <blueness> not exactly the same topic but amd64 abi=x32 hardened no problems [22:40:09] <blueness> although there are some glibc issues with x32 and sse4.1 cpu flag that is not hardened related [22:40:33] <blueness> here's a quick chart -> http://dpaste.com/764536/ [22:40:48] <blueness> okay done with my repor there, comments? questions? [22:41:27] <Zorry> fine here:) [22:41:57] <Zorry> any one else? [22:41:59] <blueness> Zorry, next meeting we'll just have to talk about where to put these on gentoo's site [22:42:11] <blueness> but not ready for that yet [22:42:16] <Zorry> k [22:42:25] <Zorry> so next then? [22:42:28] <blueness> yes [22:42:36] <Zorry> 2.0 Kernel [22:43:00] <blueness> okay quick report there [22:43:17] <blueness> Upstream (spender) has come up with a new set of predefined GRSEC configs [22:43:17] <blueness> including Virtualizaiton. This will be out in the next 3.4.x kernel. [22:43:31] <blueness> It conflicts with our current 4455_grsec-kconfig-gentoo.patch and so [22:43:32] <blueness> we will need to discuss this at the next meeting if we like the new "merged" configs from Gentoo's predefined and upstreams. [22:43:53] <blueness> prometheanfire, ^^^ if you can look at this too since you've been lookint at virtualization [22:44:11] <prometheanfire> Spenders new predefined configs set kernel options. After these options are set they can be optionally deselected, so it is a bit more flexible [22:44:30] <blueness> too flexible? [22:44:38] <prometheanfire> These new configs will need a bit of testing with the different virtualization platforms and processor combinations. [22:44:45] <prometheanfire> If you run into issues with a kernel option for a particular virtualization predefined config and that virtualization’s performance or use open a bug and/or poke me (prometheanfire) or bluness. [22:44:50] <prometheanfire> ok, done pasting [22:45:14] <prometheanfire> I don't think too flexible, I think it is how it should have been to start [22:45:35] <blueness> prometheanfire, okay i will push out 3.4.4 with spender's patch and our 4455 dropped and see what people think. [22:45:46] <prometheanfire> ya, that's my rec [22:46:06] <prometheanfire> just when we fixed it too lol [22:46:07] <blueness> k, this looks like it may need work [22:46:36] <prometheanfire> ya, the new configs need testing to verify that the options for various virt products work correctly [22:46:49] <blueness> i know but i can't do a lot of that [22:46:55] <blueness> with limited cpus [22:46:57] <Aleister> prometheanfire: i am you noted down what ever it was i have told you :) [22:47:01] <prometheanfire> blueness: same [22:47:03] <blueness> so i htink we push it out and see what bugs come back [22:47:11] <Aleister> prometheanfire: *i hope [22:47:13] <blueness> it is always this way with kernel [22:47:14] <prometheanfire> Aleister: yep :D [22:47:21] <blueness> no one can test every hardware item [22:47:25] <prometheanfire> blueness: agreed, next? [22:47:37] <blueness> unless there are questions from the floor [22:48:01] <Zorry> 3.0 Selinux [22:48:11] <Zorry> SwifT: ^^ [22:48:11] <blueness> Zorry, 1 sec -> kensington put apparmor on the hardened-dev overlay [22:48:14] <blueness> done [22:48:16] <blueness> :) [22:48:22] <SwifT> I just committed rev 13 to the main tree, ~arch'ed. This is a candidate for stabilization (otherwise I wouldn't have pushed it). It mainly contains many, many policy updates, a few that reduce the size of the policy in memory (also in upstream now) and a few backports. [22:48:44] <SwifT> I decided to try and keep up with upstream in our own repository (hardened-refpolicy) and backport the changes quickly so that, if a new release is made, it is much more transparent for the users. [22:49:07] <SwifT> While I'm on it, I'm also trying to get most of our patches accepted upstream (or if they want to see changes, make them both for upstream and ours) which gives some notable differences in development policies across distributions ;-) For instance, we strive to support a fully-confined system without unconfined domains, whereas apparently RHEL and Fedora have given up on that approach. [22:49:35] <blueness> foo on fedora! [22:49:41] <Zorry> and RH [22:49:46] <SwifT> you'll also noticed that a new eclass has been committed to the tree (a while ago, but now I can report on it) [22:50:09] <SwifT> this eclass should make mass updates more flexible (as we first try to load the policy module and, if that fails, try to load all policies at once) [22:50:25] <SwifT> (all policies = all installed policies of course, not the whole slew - also a difference between us and other distributions ,-) [22:51:01] <SwifT> another supporting feature of this eclass is that we can now have packages just "provide" the additional sources inside the files/ directory, without the packager needing to create patches for it of any kind [22:51:15] <SwifT> once installed, the eclass both loads the module and registers it, including the interfaces [22:51:28] <SwifT> I like to call that the "third-party policy support" feature ;-) [22:52:01] <SwifT> another change made is that we now *should* have full python3 support in our selinux userland utilities (~arch for the moment) [22:52:22] <schmitt953> SwifT: Could we possibly add an selinux section to bugzilla? [22:52:23] <SwifT> that was quite some experience, and I hate the pytho folks for doing such incompatibilities... [22:52:29] <schmitt953> or it might already be on there [22:52:34] <SwifT> schmitt953: just a sec [22:52:39] <schmitt953> alright [22:52:46] <SwifT> the next cumbersome change is ruby19 :-( [22:53:02] <SwifT> given the feedback received from Flameeyes, I am a bit afraid of working on that :-S [22:53:13] <SwifT> seems like another major incompatibility quest [22:53:31] <SwifT> another change made was to remove obsoleted ebuilds (tree cleanup) [22:54:02] <SwifT> okay, that's about it for SELinux (I have some left for profiles & doc, but that'll be within those parts of the meeting) [22:54:04] <prometheanfire> Started working more on this then just testing/verifying Swift’s stuff. Gonna do more to make sure that I stay more on task (more on that in 8.0). [22:54:25] <Flameeyes> SwifT: hm? [22:54:25] <prometheanfire> done for me as well, gonna be bothering swift more I think :P [22:54:32] <SwifT> schmitt953: to reply to your suggestion, yes, that would be a good idea. It's currently just under hardened, and I try to reassign to selinux the moment I see them, but it might not hurt to have it available directly for users [22:55:02] <Zorry> SwifT: that would be good [22:55:04] <schmitt953> SwifT: I just think that would clear up some clutter, also perhaps adding something to the wiki pages may be nice [22:55:04] <SwifT> Flameeyes: you have some experience with ruby upgrades ;) [22:55:28] <SwifT> schmitt953: the wiki is open for your contributions ;) [22:55:28] <blueness> SwifT, call on me when entertaining questions [22:55:40] -*- blueness puts his hand up [22:55:47] <prometheanfire> schmitt953: the docs should be easy to port to the wiki I think [22:55:55] -*- SwifT points to blueness "yes?" [22:56:29] <blueness> SwifT, regarding policy loading, what do pacakges that have policies associatated with them need in their ebuilds [22:56:32] <schmitt953> SwifT: In a couple days I'm going to be setting up a kvm hypervisor with selinux support, would that be a useful stage4? [22:56:43] <schmitt953> the other thing is would it be a good idea to assign a role to VMs [22:56:48] <schmitt953> to help harden the barrier [22:56:50] <blueness> eg tor has selinux? ( sec-policy/selinux-tor ) [22:56:53] <SwifT> blueness: they need to DEPEND and RDEPEND on the selinux-<module> package [22:56:54] <blueness> i assume that hasn't changed [22:57:02] <blueness> both? [22:57:08] <blueness> or at least one [22:57:37] <SwifT> blueness: yes, without DEPEND, the EAPI suggests that the dependency *might* be installed afterwards, which isn't alloed [22:57:45] <SwifT> we need to have it installed prior, since portage labels the files during the merge phase [22:57:58] <SwifT> but DEPEND alone isn't good either, since for binary packages, DEPEND is ignored (only RDEPEND is checked) [22:58:27] <SwifT> in practice, having it on RDEPEND is sufficient for portage currently, as portage intsalls RDEPENDS before the package itself [22:58:42] <SwifT> but the PMS says you can't rely on that [22:58:48] <SwifT> (it's PMS, not EAPI) [22:59:09] <blueness> SwifT, sounds to me like we should just document "do both DEPEND and RDEPEND for good measure" [22:59:37] <blueness> but that's exactly what i was getting at because the labeling has to be done *after* the files on are on the filesystem [22:59:46] <SwifT> when I update ebuilds, I do it for both. Not sure where to document it exactly, there's no guide for "How to be a nice package maintainer" ;-) [23:00:15] <klondike> SwifT: the developer's guide? [23:00:21] <blueness> SwifT, okay fair enough, but at least you can point to something when you oepn bugs against packages [23:00:25] <SwifT> blueness: the labeling has to be done after putting on file system, but before postinst phase, as that might run activities that already require the proper label to be assigned on the files [23:00:30] <blueness> yeah maybe the dev guide [23:01:03] <blueness> SwifT, this is subtle enough that i think klondike is right [23:01:20] <blueness> let's see if we can get it into the dev guide with best practice and your above rational [23:01:28] <SwifT> ok, i'll look into it that the dev guide has some paragraph(s) on it [23:01:58] <Zorry> next ? [23:02:14] <SwifT> ok [23:02:16] <blueness> i'm done yeah next [23:02:24] <Zorry> 4.0 Grsec/PaX [23:02:43] <blueness> okay look at line 103 of http://dpaste.com/764530/ [23:02:48] <blueness> for the written report [23:02:53] <blueness> i'll summarize quickly here [23:03:05] <blueness> we have had xattr pax flags for about 3 months [23:03:15] <blueness> but i've been caught up and put this on the back burner [23:03:31] <blueness> it works, but we really need a good front end and changes in pax-utils.eclass [23:03:48] <blueness> the reason i slowed down was because pipacs change the implementation [23:03:56] <blueness> my original one was binary in user.pax.flags [23:04:06] <blueness> pipacs switched to ascii in user.pax.flags [23:04:18] <blueness> so users can use set/getfattr [23:04:37] <blueness> but in writing our front end, we should look at how those ascii flags get interpreted [23:04:46] <blueness> and maybe do some sanitizing [23:05:05] <blueness> eg. what does the pax kernel do with illegal/meaningless flags? [23:05:12] <prometheanfire> I talked to pipacs and he said that there is sanitation code in the kernel (same code as the current actually) [23:05:30] <prometheanfire> for illegal flags it defaults to enabling them (secure) [23:05:34] <blueness> prometheanfire, i know but for a nice front end, we should alert the user [23:05:51] <prometheanfire> alert the user if there has already been an illegal flag set? [23:06:01] <blueness> prometheanfire, did you try running mismatching pt_pax and xattr pax? [23:06:12] <prometheanfire> I haven't had a chance to touch that [23:06:15] <blueness> k [23:06:21] <prometheanfire> was gonna do it this week and next (vacation time) [23:06:41] <blueness> k by that time i hope i'll be able to write the front end, i'm going to use python [23:06:48] <blueness> any questions? [23:06:55] <prometheanfire> I think I may be using python for the fuzzing [23:07:01] <prometheanfire> or just bash [23:07:15] <blueness> the little bashy thing i showed you should be fine [23:08:09] <blueness> okay next ... revdep-pax [23:08:31] <blueness> its pretty much done, but klondike pointed out a few issues that would make it more user friendly [23:08:34] <blueness> i'll try to add those [23:08:40] <klondike> :D [23:08:55] <blueness> once the pax frontend to set/getfattr and paxctl and revdep-pax are done [23:09:07] <blueness> i'll unmaks the elfix package that houses them [23:09:12] <blueness> its masked right now [23:09:29] <blueness> we may even want to change its name, or split it up, but we can talk about that in the next meeting [23:09:47] <blueness> okay i'm done with pax/grsec [23:10:19] <Zorry> what options do we use in the pax-utils.eclass for the xattr? [23:10:59] <Zorry> new tool only or setfattr to [23:11:06] <blueness> Zorry, what i will do there is test if the filesystem takes xattrs, and i can test if there is a pt_pax elf program header [23:11:18] <blueness> and set either or both in a consistent way [23:11:35] <blueness> this way, even for elfs without pt_pax we can get pax flags if xattr allows [23:12:17] <blueness> Zorry, does this answer your question? [23:12:25] <Zorry> yep [23:12:36] <Zorry> next then [23:12:47] <Zorry> 5.0 Profiles [23:12:54] <blueness> heh, me again [23:13:00] <blueness> here are the chagnes to the profiles [23:13:24] <blueness> 1. I added hardened/linux/mips - this is for glibc and it is not yet visible via eselect profile [23:13:34] <blueness> 2. I added hardened/linux/arm - this is for glibc and it is not yet visible via eselect profile [23:13:58] <blueness> 3. I have not yet added any hardened/linux/uclibc stuff, I need to talk to embedded people and figure out what to do [23:14:07] <blueness> they're profiles are ancient and possibly a mess [23:14:24] <blueness> i may just add those profiles under hardened [23:14:29] <blueness> finally [23:14:29] <blueness> 4. [23:14:37] <blueness> I removed USE="-ipv6" [23:15:01] <blueness> that's because Flameeyes made a convincing argument that in an ipv6 only env, you can't bootstrap out of a hardened stage3 [23:15:20] <blueness> the fallout of the decision is all over the gentoo-hardened email list :) [23:15:23] <blueness> okay done with profiles [23:15:31] -*- SwifT has some [23:15:38] <SwifT> about selinux profiles [23:15:47] <SwifT> (unless there are questions about blueness' ?) [23:16:22] <blueness> go ahead SwifT i need to run to the bathroom [23:16:23] -*- klondike also has a bit [23:16:33] <SwifT> One recent change to the SELinux environment was to switch from /selinux to /sys/fs/selinux. Many changes have been made to support this, like init mounting /sys first and so on. One of them was to change the portage sandbox configuration. This is now done (was already done) through the SELinux profile. [23:16:47] <SwifT> Apparently, the profile has a profile.bashrc file in which we can set the SANDBOX_WRITE variable. So no need to update portage for changes like these ;-) Thanks to PeBenito for pointing this out to me. I really had no idea on that. [23:17:09] <SwifT> another one is about the older selinux profiles [23:17:12] <SwifT> We currently still have the old selinux profiles in the tree. They are all marked as deprecated as far as I remember, so it might be a good time to actually remove them from the tree in the very near future. I was thinking about mailing the list for this, giving people ample time to react, and then pun it. [23:18:01] <SwifT> if that's ok for the gang, I'll mail it to gentoo-hardened this week and see if there's also a fall-out on the mailinglist about it (like ipv6) or if people just generally don't-give-a-fuck-about-old-profiles ;) [23:18:42] <klondike> Yay even more work for me then if fallout happens :P [23:19:31] <Zorry> i have added -orc to the profile for it is a jit type use [23:20:00] <Zorry> it add dep on dev-lang/orc that use jit allover [23:20:37] <Zorry> any one else? [23:20:45] <blueness> Zorry, why didn't they just call it jit? [23:21:01] <blueness> i would never had known what that flag was [23:21:04] <Zorry> blueness: the devs did't want to change it [23:21:27] <blueness> you mean our devs, not upstream, right? [23:21:34] <Zorry> our devs [23:21:53] <schmitt953> SwifT with the change from /selinux should we update the doc? [23:21:55] <blueness> okay we can live with it, but JIT has a very well understood meaning [23:22:03] <Zorry> blueness: yep [23:22:03] <klondike> I have a little to say too [23:22:19] <SwifT> schmitt953: currently, for stable users, /selinux still needs to be used. ~arch users will find some information in the docs already, but aren't really affected (we're backwards compatible) [23:22:32] <SwifT> schmitt953: I'll update the docs once all necessary changes are ready for stabilization [23:22:42] <schmitt953> SwifT: we then need to add mkdir /selinux to the doc [23:22:46] <Zorry> okay next ? [23:22:49] <klondike> wait [23:22:50] <schmitt953> it is not in there, or wasn't last time I checked [23:22:58] <prometheanfire> klondike: we are skipping you :P [23:23:09] <SwifT> schmitt953: it is a few weeks now [23:23:10] <klondike> I'd like to turn you attention towards this thread on gentoo-user [gentoo-user] USE="jpeg" not part of hardened/linux/x86 profile [23:23:12] <Zorry> schmitt953: SwifT that that in next point [23:23:38] <prometheanfire> klondike: link to thread? not on that list [23:23:41] <klondike> I already explained that we do support hardened desktops and stuff yet there is a quite good point there [23:24:02] <blueness> klondike, servers don't need jpeg [23:24:07] <blueness> and we support servers too [23:24:11] <Zorry> klondike: we trying to not to cluber the profiles [23:24:14] <klondike> Yep [23:24:18] <klondike> I know [23:24:19] <schmitt953> klondike: can't they put in jpeg in their make.conf [23:24:33] <klondike> Give me a second to explain [23:24:47] <klondike> The point is not about the jpeg USE or servers [23:24:48] <blueness> USE="every-damn-flag-under-the-sun-become-debian" [23:25:28] <schmitt953> blueness: the problem with that statement is if it is become debian it needs to have -flags-you-need [23:25:33] <schmitt953> xD [23:25:40] <klondike> The point is more about wether it would be feasible to create a feature like selinux or no-multilib and using it with hardened profiles [23:26:10] <prometheanfire> klondike: is the point that they want +jpeg on hardened desktop profiles? [23:26:15] <blueness> klondike, it is and i've thought about it [23:26:27] <blueness> but i will share a secret with you ... ssshhhh! [23:26:32] <klondike> Even as a simple publicity stunt it would help the users see that we do indeed support Hardened desktops [23:26:44] <blueness> the hardened profiles are not insanely stacked [23:26:57] <blueness> and so they are easier to understand and work with if you need to make changes [23:27:03] -*- klondike knows [23:27:15] <blueness> some of default/linux etc profiles are stacked 20 levels deep [23:27:23] <blueness> i've tried to short circuit that as much as possible [23:27:32] <blueness> so the hardened profiles serve two purposes [23:27:33] <Zorry> blueness: yep but adding may brake stuff [23:28:02] <schmitt953> klondike: perhaps a compromise may be a hardened desktop profile [23:28:14] <Zorry> but we could try to make a dessktop profile [23:28:15] <Dwokfur> blueness: thanks for unrolling profile loops [23:28:20] <blueness> Zorry, the nomultlilib selinux issue was because it was turned on then off then on then off, i don't remember how many times [23:28:37] <klondike> That may also be an option [23:28:51] <schmitt953> klondike: that would end the argument [23:28:54] <Zorry> blueness: yep but we need to test [23:29:25] <klondike> schmitt953: there hasn't be any argument just propossals and questions so far [23:29:25] <blueness> anyhow, right now i'm not prepared to try a features/hardened [23:29:39] <blueness> but adding a desktop to amd64 or x86 is more doable [23:30:11] <schmitt953> blueness: but what about my power7 desktop xD [23:30:17] <schmitt953> sorry couldn't help myself [23:30:38] <Zorry> schmitt953: the profiles is pain in the *** [23:30:44] <blueness> yes [23:31:12] <blueness> the problem is they are not transparent and when you make a change, no matter how "reasonable" you must test [23:31:36] <klondike> xD [23:31:46] <klondike> And enjoy the pain when things unexplainably break [23:32:02] <Zorry> we do have a desktop profile but not in eselect profiles [23:32:25] <Zorry> klondike: ^^ [23:32:33] <Zorry> but it need testing [23:32:36] <klondike> Zorry: how old is it? [23:32:36] <blueness> speaking of which the x32 profiles are subtle because you must restack feature/multilib to clobber the already inherited multilib/lib32 [23:33:00] <blueness> oh yeah Zorry that's right! [23:33:03] <blueness> i forgot about those [23:33:27] <Zorry> klondike: it inherit ../../../../targets/desktop [23:33:39] <Zorry> so it should be upto date [23:33:43] <klondike> I see [23:34:02] <Zorry> but we don't know if it brake soemthing [23:35:02] <klondike> Aha, so that's the reason to not have it listed? [23:35:05] <blueness> klondike, to be honest, i put them there when i removed ../10.0/.. and did nothing else [23:35:37] <blueness> klondike, that is sufficient reason yes, but anyone can aim make.profile anywhere they like and live with the consequences [23:35:54] <klondike> I suppose so [23:36:25] <klondike> Well the propossal anyway is more as a thing to take into account when we can than a requirement per se anyway [23:37:59] <prometheanfire> next? [23:38:13] <Zorry> yep [23:38:27] <Zorry> 6.0 Docs [23:38:47] <Zorry> SwifT: schmitt953 klondike [23:38:58] <klondike> Okey I begin [23:39:30] <klondike> Little more here, so as I said if anybody wants to take over any doc I have on the works on the git repo feel free to do so [23:41:09] <Zorry> k [23:41:37] <Zorry> SwifT: anything? [23:41:50] <SwifT> yup [23:41:56] <SwifT> A recent change to the environment is the introduction of /run, which of course has its ramifications to the SELinux environment. Most of the necessary changes to the policies have been made, but it also meant a small update on what the user had to do on his system (namely mount /run correctly). This is now part of the instructions. [23:42:14] <SwifT> Speaking of instructions, I've added a "changelog" of the documentation at the end of the SELinux handbook so that users, who are already running SELinux, can regularly check up and see if anything has changed that they might need to be aware off. In the future, I'll be using news posts more actively, but for instance for ~arch users this is not the best way (as news items should only be used if enough *stable* users are affected afaik). [23:42:39] <SwifT> Now that the SELinux policy repository is in gogo (git.overlays.gentoo.org) the SELinux development guide has also been updated to reflect this. This makes development a whole lot easier (no more need to setup a special environment to generate patches in for instance), thus makes the document easier as well ;-) [23:42:52] <SwifT> that's it [23:43:15] <Zorry> schmitt953: did you have anything? [23:43:19] <schmitt953> I have nothing [23:43:37] <Zorry> any one else? [23:43:44] <prometheanfire> non [23:43:54] <Zorry> next [23:44:06] <Zorry> 7.0 Bugs [23:44:19] <Zorry> any thing we should talk bout [23:44:32] <blueness> 1 kernal bug [23:44:35] <blueness> Both xake and Chainsaw have hit a serious bug on hardened-sources-3.2.11 which was not [23:44:35] <blueness> reported but I've seen the oops. This is resolved in 3.2.20 which I will stabilize as soon [23:44:35] <blueness> as I get Chainsaw's config file working on my test HP Proliant. Under high load tcp/ip oops [23:44:35] <blueness> with grsec BLACHOLE=y, the machine slows down, and oopses until it finally dies. Hopefully [23:44:35] <blueness> this will be done in a couple of days. [23:45:47] <Zorry> blueness: any thing else? [23:45:54] <blueness> done [23:46:01] <SwifT> nope, all done [23:46:11] <Zorry> okay [23:46:22] <schmitt953> there may be some new bug with the new stage [23:46:42] <Zorry> 8.0 Media [23:46:49] <schmitt953> I noticed a few days ago doing an install some package had trouble building, I'm going to test that all today [23:47:12] <Zorry> klondike: ^^ [23:47:39] <klondike> Okey, I have been giving a little love to our users through the mailing lists [23:48:34] <klondike> As always I try to monitor gentoo-user from time to time for hardened issues though I couldn't do that as actively as I wish [23:48:56] <Zorry> blueness: you have blog on planet.gentoo.org ? [23:49:28] <klondike> And well on twitter we have already reached 101 followers which is a good number given our activity there [23:49:30] <blueness> yes [23:49:36] <klondike> That's it from me [23:49:37] <prometheanfire> I think I’m finally going to be starting a blog just to make sure I actually work on all the projects I have on my list. I may eventually add it to planet. [23:49:43] <prometheanfire> I also think that klondike should probably broadcast all the new hotness that we’ve been adding (profiles and stuff) once it’s properly selectable (eselect). [23:49:45] <blueness> (sorry phone call) [23:50:27] <klondike> Of course prometheanfire just tell me what you need broadcasted and I will do so as I did with ipv6 [23:50:41] <blueness> Zorry, because a lot of the stuff we're doing is starting to spill over into [email protected] and [email protected] i joined botht those teams and i think i need to start telling the dev community [23:50:54] <prometheanfire> klondike: it's more of the mips/arm sexyness [23:51:24] <blueness> its amazing how cool mips and arm systems are [23:52:09] <Zorry> any one else? [23:52:28] <Zorry> 9.0 Open floor [23:52:56] <klondike> It's cool to see we are expanding arches, thanks Zorry and blueness for that [23:53:07] <Zorry> ty for all for the progress and the meeting
