Hi
Meeting log
/Magnus
[22:03:05] <Zorry> 1.0 Toolchain
[22:03:25] <Zorry> not much new from my part
[22:03:46] <Zorry> still working on the upstream patches for gcc 4.8
[22:04:06] <Zorry> http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-gccpatchset.git;a=tree;f=upstream;hb=f75c7f873e548b69686fcff48519d8edb8ddeb32
[22:04:16] <SwifT> implementing the upstream patches in gcc 4.8, or upstreaming our patches to gcc?
[22:04:24] <Zorry> have some of the docs and the testsuite left to do
[22:04:41] <Zorry> SwifT: upstreaming
[22:05:06] <blueness> Zorry, did you decide what we were going to do with specs in gentoo? drop the old way?
[22:05:11] <blueness> go with the upstream way?
[22:05:51] <Zorry> haven't decided yet haven't mail to the ml list yet
[22:06:18] <blueness> okay we have time
[22:06:49] <Zorry> yep we do
[22:07:35] <blueness> i have something
[22:07:45] <blueness> for toolchain
[22:07:48] <Zorry> go
[22:08:20] <blueness> i got a stage4-armv7a-softfloat-uclibc-hardened on the mirrors
[22:08:34] <blueness> it worked so well i didn't see any need to put the -vanilla version up
[22:08:44] <prometheanfire> good
[22:08:46] <blueness> and i'm working on -hardfloat-
[22:09:14] <blueness> for fun, i turn the stage4-armv7a-softfloat-uclibc-hardened into a full xfce4 desktop works great
[22:09:34] <blueness> so arm + {glibc,uclibc} + hardened is perfect
[22:09:48] <blueness> the only bug is with abi=EABI and sandbox, but vapier is working on it
[22:09:56] <Zorry> :)
[22:10:02] <blueness> sandbox tries to trace utime which is dropped from EABI
[22:10:20] <blueness> steev is playing with the stage4 on his quad core arm now
[22:10:28] <Zorry> nice
[22:11:10] <blueness> Zorry, arm is trivial compared to ppc/ppc64 and mips which are not well maintained in general
[22:11:14] <blueness> but also more improtant
[22:11:15] <blueness> okay done
[22:11:25] <Zorry> any one else?
[22:11:49] <Zorry> 2.0 Kernel
[22:12:15] <blueness> okay a few things
[22:12:46] <blueness> 1) there is a new structure to the grsec/pax menu, and the old WORKSTATION/SERVER/VIRTUALIZATION are now gone
[22:12:59] <blueness> those choices are still there, but its different
[22:13:07] <blueness> i did email the list
[22:13:31] <blueness> actually that's it for just kernel, i'll talk about xattr pax later under pax
[22:13:43] <blueness> no serious bugs right now
[22:14:02] <blueness> questions? else move on
[22:14:18] <prometheanfire> I have something
[22:14:39] <blueness> go
[22:15:23] <prometheanfire> I believe that kernexec is now impacting kvm performance again (1.0.1 tested) it will need more testing to verify though, so people that have nested page tables available on their processor, if they could test kernexec enabled kvm performance that'd be good
[22:15:56] <Zorry> host and guest?
[22:16:00] <prometheanfire> host
[22:16:02] <Zorry> k
[22:16:10] <prometheanfire> guest has never really been a problem in my testing
[22:16:23] <blueness> Zorry it is almost always host
[22:16:29] <SwifT> do you expect performance degradation with nested page tables, or without?
[22:16:41] <Zorry> blueness: figur that
[22:17:07] <schmitt953> one thing for pax is that we may want to add to our doc the options that degrade performance on VMs
[22:17:14] -*- blueness is making lots of commits that effect a circular dep, so if i get unresponsive just ping
[22:17:33] <SwifT> prometheanfire: do you expect performance degradation with nested page tables, or without?
[22:17:53] <prometheanfire> nested page tables should allow for kvm (host) with kernexec to have good performance
[22:18:04] <prometheanfire> I am looking for confirmation that that is no longer the case
[22:18:14] <blueness> prometheanfire, intel?
[22:18:17] <SwifT> k, without nested page tables, its always slow? ;)
[22:18:20] <prometheanfire> that's all I have
[22:18:34] <prometheanfire> other processors are welcome to test app-emulation/qemu-kvm-1.0.1
[22:18:42] <prometheanfire> SwifT: yes
[22:19:34] <Zorry> okay next?
[22:19:40] <prometheanfire> done
[22:19:47] <Zorry> 3.0 SeLinux
[22:20:00] <SwifT> okay, quite a few topics to discuss
[22:20:06] <SwifT> let's start with selinux stages
[22:20:28] <SwifT> i've been trying to get selinux stages (stage3) for amd64 going in an automated manner. It somewhat works with our ~arch policies
[22:20:43] <SwifT> I still have to relabel files manually (or have the user do that), but that's a minor nuisance
[22:20:58] <SwifT> I use vapiers' build-stages script to do stuff (https://dev.gentoo.org/~vapier/build-stages)
[22:21:04] <blueness> SwifT, have you tried the xattr capable tar?
[22:21:21] <SwifT> yes I did, problem is more with the chroot not finding the proper policy files
[22:21:39] <SwifT> however, my opinion is that I should be able to generate selinux stages built on a non-selinux system
[22:21:50] <SwifT> after all, all I need is to have the tools built/linked with libselinux et al
[22:22:07] <SwifT> labelling can be done once afterwards anyhow, and it makes it easier to potentially include selinux stages in our current "autobuild"
[22:22:32] <blueness> is the labelling still done on the the build box?
[22:22:34] <SwifT> so my next attempts will be to build selinux stages on a regular hardened vm (using the same build-stages script)
[22:22:46] <schmitt953> SwifT: I know this is a horrible inefficient way but would it be possible to have the system run through the normal selinux configuration and then delete all the non stage3 things
[22:22:47] <SwifT> if your system is selinux-enabled, it'll always label (part of selinux behavior)
[22:23:06] <SwifT> schmitt953: only for the initial stage
[22:23:11] <Zorry> SwifT: i can try with calyst later on with jasmin
[22:23:23] <SwifT> schmitt953: the catalyst build process needs a "seed stage" to work from. That's in my case a regular selinux system, tar'd up
[22:23:52] <SwifT> Zorry: I'm interested in how you autobuild, is that also with the build-stages stuff?
[22:24:05] <SwifT> Zorry: but perhaps we can get that later (not during meeting ;)
[22:24:16] <Zorry> SwifT: i use catalyst way to do it
[22:24:26] <Zorry> SwifT: yep later
[22:24:48] <SwifT> so far for selinux stages
[22:24:54] <SwifT> next is the selinuxnode
[22:25:15] <SwifT> that's a virtual machine image available on our gentoo mirrors with gentoo hardened (pax/grsec enabled) and selinux active
[22:25:38] <SwifT> it's a base system deployment, nothing more, with three accounts: root (of course), user (confined) and oper (operational user, can transition to sysadmin)
[22:25:42] <blueness> if possible use catalyst since it gives the most consistent stages
[22:25:53] <SwifT> build-stages uses catalyst
[22:26:04] <SwifT> just a wrapper around it to handle the fancy options in all the spec files
[22:26:33] <SwifT> so I'm sure I can work things out with Zorry to get it going, but first need to confirm that it works on a regular hardened vm here
[22:26:40] <SwifT> anyway, back to the selinuxnode (qemu vm image)
[22:27:06] <SwifT> the image is a qcow2 qemu image to make the download small (130Mbyte download iirc, 1.6Gbyte extracted, 50Gbyte in-VM)
[22:27:20] <SwifT> what I'm aimiing to do with this image is the following:
[22:27:38] <SwifT> - be able to provide users with a running selinux system they can play with (hell, it's even hardened, they can play with that too ;-)
[22:28:10] <SwifT> - become a "proof of concept" for various measures we implement (gentoo hardened, that is) concurrently (so TPE, PaX, grsec, selinux and whatever comes next)
[22:28:38] <SwifT> - be a "base" for future educations I want to make for gentoo (and selinux in particular), so that people can follow some sort of "web-course" with a known state of their working system
[22:29:13] <SwifT> (and perhaps) support staging of hardened services in a "appliance-like" manner - but that's quite far in the future ;)
[22:29:57] <SwifT> so, any specific questions on the selinux vm?
[22:30:11] <blueness> nope just that its a good idea
[22:30:21] <SwifT> if people want to play with it: http://distfiles.gentoo.org/experimental/amd64/qemu-selinux/
[22:31:03] <SwifT> ok, next on selinux then
[22:31:04] <prometheanfire> thanks :D
[22:31:39] <SwifT> I'm working actively on the policies, currently focusing on /run support (thank you wide linux world for changing stuff) and userspace (browsers for one)
[22:32:05] <SwifT> I started with the chromium policy (part of an open bug) and trying to get it working in a very confined yet very workable manner on my system
[22:32:26] <SwifT> as you're all aware, browsers are a popular attack platform/vector nowadays, so it's just normal that I put a lot of focus on confining it properly
[22:33:00] <SwifT> we're a bit a forerunner on this, as most other distributions run browsers in unconfined. We also support unconfined (targeted policy) but I want to make sure users in strict policies can also use it
[22:33:35] <SwifT> but I must admit browsers act by default a lot more "awkward" than services (chromium reads /sys/kernel; /sys/bus, /sys/devices, /proc/sys/, etc.)
[22:33:46] <SwifT> you don't wanna know what its plugins all do :p
[22:34:08] <prometheanfire> I'm sure
[22:34:11] <SwifT> the next revision i'll release shortly is rev16
[22:34:18] <prometheanfire> and they change quickly as well
[22:34:41] <SwifT> it'll also have all accepted upstream patches bundled in one patch to make deployments in gentoo faster (easier to patch one huge patch than to iterate over 45 patches)
[22:34:57] <SwifT> speaking of which, our current state-of-affairs with respect to policy upstreaming:
[22:35:31] <SwifT> gentoo has 116 changesets since refpolicy 2.20120215, of which 45 have been upstreamed, 12 pending, 4 not going to send (because they are not conform their policy) and 55 not sent yet
[22:35:59] <SwifT> we're also fully in sync with refpolicy (all the patches there are applied on ours as well), so we don't have a difficulty when they release a new version
[22:36:25] <SwifT> but as you can see frmo the mails I send, policy changes a lot, and gentoo changes a lot (for a dying distribution ;)
[22:36:40] <SwifT> and because of that, my next point is about policy stabilization
[22:36:57] <SwifT> for now, I use the "standard" 30 days stabilization, and skip releases if they have major bugs fixed in later revisions
[22:37:10] <SwifT> problem is, I get major bugs every 30 days, so I can't stabilize easily
[22:37:29] <SwifT> udev changes location, /run is introduced, initramfs becomes mandatory for /usr partitions, etc.
[22:37:52] <SwifT> i'm considering asking to have a 14-day window on stabilization of selinux policy stuff
[22:38:16] <SwifT> that'll allow users of a stable system to get the necessary selinux updates soon and still have enough time to catch potential regressions
[22:38:17] -*- prometheanfire just runs ~ and runs well (for selinux)
[22:38:27] <SwifT> however, most regressions we get aren't about policy changes, but system changes
[22:39:22] <SwifT> i'd prefer to have faster stabilization, and only wait stabilization for the standard 30 days if major rewrites are in the policy (not enhancements/addenda)
[22:40:11] <SwifT> is that something you guys could support and, if so, is that something I should ask council?
[22:40:34] <Zorry> is okay with me
[22:40:37] <blueness> yeah why not
[22:41:06] <Zorry> prometheanfire: ^^
[22:41:24] <prometheanfire> fine with me
[22:41:26] <SwifT> prometheanfire wants to remove stable from all profiles and just have everyone run ~arch ;)
[22:41:40] <SwifT> ok, two minor points remaining for selinux then
[22:41:43] <prometheanfire> well, for selinux that almost makes sense with how stable it's been for me :D
[22:41:57] <blueness> SwifT, these are not like compiled packages
[22:42:01] <SwifT> first, bugzilla now has a "SELinux" component for reporting bugs, and people already noticed it ;)
[22:42:06] <SwifT> indeed
[22:42:10] <schmitt953> SwifT: :)
[22:42:43] <SwifT> second (and last) selinux item: one longer-running bug was that our booleans weren't properly documented. If you now run "semanage boolean -l" you get the proper description (from policy revision 14 onwards)
[22:42:58] <SwifT> previous versions just had the boolean name as description
[22:43:12] <SwifT> that's it from me for SELinux
[22:43:19] <schmitt953> can I say something
[22:43:20] <prometheanfire> nice
[22:43:25] <SwifT> schmitt953: sure
[22:43:47] <schmitt953> SwifT: I know we discussed this earlier, but can we see if we can get sVirt working
[22:44:15] <SwifT> schmitt953: sure, but I don't see what wouldn't work on it. the policy for virt's are already in, and we support MCS
[22:44:17] <schmitt953> that may be long term but with the rise in virtualization it might be nice to work on
[22:44:21] <SwifT> just need a few guys to test it out ;)
[22:44:26] <schmitt953> I didn't know we had MCS
[22:44:29] <schmitt953> I guess I'm a little slow
[22:44:38] -*- schmitt953 signing up for the mailing list tonight
[22:44:41] <SwifT> yes, i'm even testing some stuff with MLS, very fun
[22:44:54] <schmitt953> SwifT: If you want me to join you on anything please ask
[22:45:11] <SwifT> sure, will do
[22:45:39] <Zorry> next?
[22:45:47] <blueness> sure
[22:45:49] <SwifT> yup
[22:46:00] <Zorry> 4.0 Grsec/pax
[22:46:20] <prometheanfire> my kernel stuff should have gone here...
[22:46:25] <blueness> okay so i finally got back to xattr pax
[22:46:34] <pipacs> high time ;P
[22:46:37] <blueness> https://bugs.gentoo.org/show_bug.cgi?id=427888
[22:46:51] <blueness> pipacs, yeah i got too busy with hardening uclibc stuff
[22:47:11] <SwifT> blueness: I think he meant I typed too much :p
[22:47:36] <blueness> so the thing is to push out chpax and bring in the userland utilites for xattr pax
[22:48:01] <blueness> we have two sets: 1) paxctl + setfattr or 2) paxctl-ng
[22:48:23] <blueness> and i've updated revdep-pax to do the reverse mappings for things like gallium
[22:48:49] <blueness> that depended on a python module i wrote pypax.so which does what paxctl + setfattr does
[22:48:58] <blueness> its now python2 and python 3 compat
[22:49:10] <blueness> really the only thing that needs to be done is ... documentation
[22:49:23] <SwifT> klondike: ^^
[22:49:24] <blueness> and i have to face the music, i'll do the documentation by next meeting
[22:49:31] <blueness> nah SwifT its okay
[22:49:36] <SwifT> =)
[22:49:39] <blueness> he can clean up but I'd better do this
[22:50:07] <blueness> i'll put it directly on the web site, but not link it until it has been reviewed
[22:50:09] <SwifT> blueness: you can work with wiki.gentoo.org if you want (or whatever format you prefer), we can easily convert to guidexml later (or you can stick with wiki.gentoo.org if you want)
[22:50:31] <blueness> i'll do the xml first because its what i'm most comfortable with
[22:50:35] <SwifT> k
[22:51:27] <blueness> last thing, why two sets of tools ... no reason really except that pipacs and i worked on them independantly and siince mine was lamost done i finished it off
[22:51:46] <blueness> last thing is the pax-utils.eclass which i'll do in about 1 month after stabilization
[22:51:49] <blueness> of the utilities
[22:52:14] <blueness> and if there are no objections, i'll start the masking/treecleaning of chpax later today
[22:52:19] <blueness> questions?
[22:52:29] <Zorry> go go
[22:52:36] <SwifT> no questions your honor
[22:52:49] <schmitt953> call the next witness
[22:52:59] <schmitt953> (sorry couldn't help myself)
[22:53:16] <Dwokfur> sound great, good to hear about the proceedings
[22:53:25] <Zorry> okay next?
[22:53:41] <blueness> yes, no more for grsec/pax, i mentioned the changed menu above
[22:53:51] <Zorry> 5.0 Profiles
[22:54:00] <blueness> heh me again!
[22:54:19] <blueness> okay i have some stub profiles for hardened/linux/uclibc
[22:54:43] <blueness> the are there for amd64, x86, arm and soon mips, mipsel
[22:54:50] <blueness> or and ppc
[22:55:00] <blueness> they are intentionally very shallow and experimental
[22:55:29] <blueness> because we're working so far outside of the usual gentoo supported systems, i figured i'd try something shallow to start and stack in other stuff if needed
[22:55:40] <Zorry> k
[22:55:52] <blueness> i choose to put them there rather than profiles/uclibc because ... well its a mess down there!
[22:56:30] <blueness> its like the junk drawer in your kitchen, you just put everyting in there that doesn't belong elsewhere and then pretend that your house is nice and tidy :)
[22:56:43] <Zorry> :)
[22:56:46] <blueness> just kidding
[22:57:03] <blueness> maybe i should talk to embedded folk and see what's going on with that
[22:57:25] <blueness> there's linux 2.4 stuff there for example that maybe cna be pruned
[22:57:27] <Zorry> yep you should
[22:57:37] <Zorry> solar: ^^
[22:57:55] <blueness> Zorry, i joined the embedded team
[22:58:16] <Zorry> iknow
[22:58:28] <blueness> but mostly i'm just working on those stages and fixing/posting bugs that are uclibc related
[22:59:18] <blueness> okay that's aboutit
[22:59:26] <blueness> for profiles anyone else?
[22:59:43] <Zorry> nope
[22:59:59] <Zorry> 6.0 System interity
[23:00:02] <Zorry> SwifT: ^^
[23:00:18] <SwifT> ok... lately i've been reading a lot and playing with integrity-related technologies
[23:00:32] <SwifT> it started with the usual (aide and such) but I quickly learned about Linux' IMA/EVM
[23:00:57] <SwifT> the idea behind IMA is that the system can detect if files were modified while the system itself was offline (for instance, when using VM images)
[23:01:08] <SwifT> EVM does something similar, but on the extended attribute level
[23:01:22] <SwifT> the combinatino of the two makes for a nice integrity validation mechanism
[23:01:38] <SwifT> IMA works best with a TPM chip, although that's not mandatory - just makes it a little less secure, but still very workable
[23:02:17] <SwifT> IMA/EVM is supported already in vanilla kernels, just lacking one patch set (ima-appraisal) which is about enforcing "no changes" on life systems (real-time modifications)
[23:02:32] <prometheanfire> that looks like fun, been wanting to play with tpm
[23:02:47] <blueness> nice!
[23:02:51] <SwifT> since we're a hardening project, and virtualization is becoming quite an important part as well as integrity, I would like to start an integrity related subproject on hardende
[23:02:54] <blueness> its like tripwire
[23:03:18] <SwifT> it would, next to the kernel level, also contain packages that are needed for it, documentation, etc.
[23:03:26] <prometheanfire> gentoo is fairly dynamic, tripwire is hard to do with that
[23:04:03] <SwifT> I currently use aide in portage' post-install hooks to update the hashes but it's not optimal. IMA can do it "automatically", but there's still work to be done to get it working properly
[23:04:28] <SwifT> as I mentioned before about selinuxnode, I would like to have fairly regular updates on the progress with the vm too, so people can see how it works
[23:04:44] <SwifT> so... ok if I launch this subproject for hardened?
[23:05:02] <Zorry> +1
[23:05:12] <prometheanfire> +1
[23:05:23] <Dwokfur> interesting to have a possibility to make good use of the TPM hardware
[23:06:17] <SwifT> yes... I don't have TPM systems here, but I'm playing a bit with the TPM emulator so might be able to provide enough documentation for it to get people on track
[23:06:51] <schmitt953> SwifT: want to try something on my thinkpad tablet
[23:06:54] <schmitt953> I have a TPM
[23:06:58] <blueness> SwifT, do it
[23:07:04] <SwifT> ok, thanks
[23:07:09] <prometheanfire> SwifT: I have tpm as well
[23:07:18] -*- SwifT notices where all the big bucks are
[23:07:19] <SwifT> :m
[23:07:34] <schmitt953> SwifT: one of my TPM laptops is an old x60 tablet
[23:07:39] <schmitt953> it's not big bucks :P
[23:07:46] <blueness> SwifT, publish some hardware guidelines too about what popular systems have tpm's, i'm asked that often
[23:07:51] <SwifT> schmitt953: "one of your laptopS"
[23:07:58] <schmitt953> I keep my old laptops
[23:07:59] <schmitt953> and
[23:07:59] <SwifT> blueness: k
[23:08:03] <schmitt953> school requires me to have one
[23:08:09] <schmitt953> and I have my tablet because I like tablets
[23:08:18] <SwifT> i have one of work, but I can't take ownership of that TPM chip
[23:08:35] <schmitt953> SwifT: do they let you put gentoo on your work laptops?
[23:08:48] <SwifT> schmitt953: no, but it boots from USB juts fine ;)
[23:09:01] <schmitt953> SwifT: nice work
[23:09:12] <schmitt953> if I ever have to work for a big company that's what I'll do :)
[23:09:35] <prometheanfire> schmitt953: I put gentoo on my work laptop :D
[23:10:19] <schmitt953> prometheanfire: that's great, my uncle told me "Usually you can't change anything from your work computer"
[23:10:30] <schmitt953> when he was trying to get me to stop hating win7
[23:10:37] <schmitt953> or winxp which he had
[23:10:41] <SwifT> ok, next topic?
[23:10:43] <prometheanfire> getting off topic
[23:10:44] <schmitt953> so I was right to keep on trolling
[23:10:46] <schmitt953> alright
[23:10:46] <Zorry> SwifT: done?
[23:10:50] <SwifT> Zorry: yup
[23:10:54] <Zorry> next
[23:11:06] <Zorry> 7.0 Docs
[23:11:21] <SwifT> can I can I can I?
[23:11:26] <prometheanfire> 7.1?
[23:11:28] <blueness> go for it
[23:11:35] <Zorry> go
[23:11:40] <SwifT> ok, i've been playing and writing hardening guides lately
[23:11:59] <SwifT> the purpose of the guides is to securely setup something (be it a gentoo OS, a linux kernel, openssh, etc.)
[23:12:14] <SwifT> the advantage is that I'm using a "standard" language, namely SCAP
[23:12:31] <SwifT> https://wiki.gentoo.org/wiki/SCAP has a quick introduction to it
[23:12:49] <SwifT> with SCAP (and app-forensics/openscap) you can not only generate the guides, you can also test them on your system
[23:13:02] <SwifT> it prints out a nice report on what settings are different then what is in the guide, etc;
[23:13:12] <SwifT> you could even generate fixes, but I'm not going that far yet
[23:13:22] <ss23> Is that like uh, bastilististic?
[23:13:34] <SwifT> ebbeh?
[23:13:36] <ss23> I can't remember the name for it, but wasn't there already some application to do that kind of stuff
[23:13:41] <pipacs> bastille
[23:13:42] <schmitt953> that's so cool
[23:13:58] <ss23> Yeah, that
[23:14:06] <SwifT> dunno... the advantage of SCAP is that there's a growing community for it, but also quite some enterprise-level support on it
[23:14:26] <SwifT> RHEL is very active in it, but others like Intel, BMC, HP, ... are on it as well
[23:14:45] <SwifT> so i've been meaning (as a docs-guy) bring my guides under the gentoo.org umbrella
[23:14:54] <ss23> SwifT: If you haven't seen bastille yet, could use it to steal some ideas, looks like it has some support
[23:15:03] <SwifT> and since they're about hardening, I was wondering if I could do so under the hardened subproject
[23:15:30] <SwifT> ss23: i'm actively working with the openscap folks for now, but I'll look at bastille
[23:15:39] <prometheanfire> it makes sense to me, but it may also just be considered 'best practices'
[23:15:45] <SwifT> I thought we had bastille support a long time ago, but that the project itself is very low on progress lately
[23:16:10] <SwifT> prometheanfire: yes, it's like a best practice, but with some support on validation too
[23:16:20] <SwifT> it's mainly a documentation effort though
[23:16:48] <SwifT> everybody loves documentation, although someone on [email protected] things nobody reads it ;)
[23:16:52] <blueness> NO!
[23:16:54] <prometheanfire> :P
[23:17:24] <blueness> oh they'll read it
[23:17:32] <blueness> its producing it that is painful
[23:17:35] <SwifT> so, would you agree to have such guides under hardened? or rather keep it outside our scope?
[23:17:56] <SwifT> i'm sure there are lots of professionals here that can help in fine-tuning the docs and suggesting stuff
[23:18:13] <prometheanfire> both? since it includes validation and possibly enforcement, hardened makes sense
[23:18:22] <blueness> SwifT, like all goal keep it a soft ideal
[23:18:45] <prometheanfire> hardened++
[23:18:58] <SwifT> yes, it's not the purpose of enforcing settings or so, but to make people aware that services by default aren't always secure :p
[23:19:19] <blueness> sure
[23:19:33] <prometheanfire> SwifT: might look into dispatch-conf for enforcing stuff
[23:20:10] <SwifT> prometheanfire: dispatch-conf? I was more thinking about puppet or so... but that's outside this scope ;)
[23:20:57] <SwifT> that's it frmo me for docs
[23:21:55] <Zorry> any one else?
[23:22:16] <Zorry> 8.0 Bugs
[23:22:32] <Zorry> any one?
[23:22:41] <blueness> not really, nothing major
[23:22:45] <SwifT> nothing specific; I start labeling (whiteboard) the selinux-related ones to make it easier to manipulate and report on them
[23:22:57] <prometheanfire> noting major as well
[23:22:58] <blueness> all the bugs i've hit were uclibc related and i'm not sure people are that interested
[23:23:16] <blueness> got some stuff upstream for them, eg mesa now compiles on uclibc systems
[23:23:27] <prometheanfire> I'm gonna work on zfs selinux support sometime in the future, but that's it
[23:24:02] <SwifT> been on my TODO list as well, just never got to it :(
[23:24:39] <Zorry> okay next then?
[23:24:54] <Zorry> 9.0 Media
[23:25:19] <Zorry> any one?
[23:25:19] <prometheanfire> SwifT: now that I have an zfs system it should be 'easy'
[23:25:27] <prometheanfire> Zorry: small thing
[23:25:36] <Zorry> k
[23:26:05] <blueness> nothing, that's klondike's baby
[23:26:16] <prometheanfire> I started bloging, very small thing, but more to keep me working on stuff
[23:26:27] <SwifT> oo... tell us where, tell us where ;-)
[23:26:27] <blueness> oh i did get a blog and i'm on planet and universe, but i haven't done any blogging
[23:26:38] <prometheanfire> mthode.org
[23:26:46] <SwifT> i'm working on a blog post for hardened as we speak :p
[23:26:47] <prometheanfire> might eventually host it in cloud files, using pelican
[23:27:03] <prometheanfire> not on planet yet
[23:27:03] <SwifT> so you're a SAW fanatic ;)
[23:27:13] <prometheanfire> SAW?
[23:27:16] <SwifT> "Let's Play a Game"
[23:27:31] <prometheanfire> ah, no, not saw, just like the phrase
[23:28:01] <schmitt953> I have to cut out early
[23:29:28] <Zorry> next
[23:29:38] <prometheanfire> next
[23:29:44] <Zorry> 10.0 Open floor
[23:29:53] <Zorry> any one?
[23:30:06] <Zorry> else the meeting is done and ty for it
