[gentoo-hardened] Agenda for meeting 2014-04-24 20:00 and log from last meeting

[gentoo-hardened] Agenda for meeting 2014-04-24 20:00 and log from last meeting

[Magnus Granberg]

[-- Attachment #1: Type: text/plain, Size: 158 bytes --]

Agenda for the meeting
1.0 Toolchain
2.0 Kernel and Grsec/PaX
3.0 Selinux
4.0 System Integrity
5.0 Profiles
6.0 Docs
7.0 Bugs
8.0 Media
9.0 Open floor
/Magnus

[-- Attachment #2: meeting-2014-03-27_20:00UTC.log --]
[-- Type: text/x-log, Size: 23273 bytes --]

[22:24:27] <Zorry> 1.0 Toolchain
[22:24:32] <prometheanfire> ohai
[22:25:23] <Zorry> gcc 4.9 will most be relaec the end of next mounth about (90 bugs now)
[22:25:57] <Zorry> else not mutch news from me
[22:26:02] <pipacs> i have a question ;P
[22:26:03] <klondike> nice
[22:26:09] <Zorry> pipacs: yes
[22:26:12] <pipacs> how do i turn off this new ssp-enabled-by-default thing? ;)
[22:26:23] <prometheanfire> blueness is 15 min out
[22:26:31] <pipacs> USE=nossp or something else?
[22:26:36] <Zorry> pipacs:  the -fstack-cehck?
[22:26:44] <pipacs> no, -fstack-protector
[22:26:59] <pipacs> for some time now it appears to be enabled by default even on non-hardened
[22:27:06] <pipacs> (which is what i use for development)
[22:27:20] <klondike> add a no between the f and the s?
[22:27:46] <pipacs> yes except it's a bit cumbersome vs. not having to do it
[22:28:00] <pipacs> i need this especially for the kernel which itself has a feature to enable/disable SSP
[22:28:10] <pipacs> and this default interferes with that and my work
[22:28:21] <Zorry> pipacs:  it is disable for kernel -D__KERNEL__
[22:28:26] <pipacs> so i'm wondering if there's a fallback to the old ways
[22:28:36] <pipacs> it doesn't seem to be
[22:28:45] <pipacs> i detect its presence from a plugin at least
[22:28:52] <pipacs> that's how i noticed it at all
[22:28:57] <klondike> you could use the vanilla compiler?
[22:29:15] <SwifT> or write your own gcc spec file, although I personally have no idea how to do that
[22:29:22] <Zorry> pipacs:  just add -fno-stack-protector to the command line should work
[22:29:23] <pipacs> i can (and do, for development) but i also test with the gentoo gcc
[22:29:29] <klondike> ugh the pain
[22:30:01] <pipacs> what i'd like to avoid is patching every single project out there ;P
[22:30:32] <pipacs> in the worst case i'll fork the gentoo patchball if someone can point out which patch turns ssp on by default ;)
[22:30:48] <klondike> won't there be a vanilla profile?
[22:31:01] <pipacs> i am using the vanilla gcc profile, not hardened
[22:31:02] <klondike> you could use that I'd there will
[22:31:04] <pipacs> and that enables ssp
[22:31:14] <pipacs> that's what's new since i don't know what, a few months maybe?
[22:31:19] <klondike> ugh
[22:31:30] <SwifT> yea
[22:32:05] <pipacs> this changed some time between last november and january, based on my emerge logs of 4.8.x
[22:32:13] <Zorry> pipacs:  that version should not be keyworded
[22:32:27] <Zorry> for we miss the news item for it
[22:33:15] <pipacs> yes, it's 4.8.2-r1 here
[22:33:30] <pipacs> i can fall back to 4.8.2 but eventually i'll face this problem when it gets unmasked
[22:33:51] <pipacs> so i'd like to raise in time so that maybe it can be fixed for my use case where i don't want default ssp
[22:34:32] <SwifT> seems like USE=nossp will be supported
[22:34:52] <SwifT> see http://thread.gmane.org/gmane.linux.gentoo.devel/89491/focus=89552
[22:35:03] <blueness> i'm here
[22:35:05] <Zorry> pipacs:  do you have -D__KERNEL__ in your gcc comand line for plugins?
[22:35:18] <SwifT> or USE="-ssp"
[22:35:27] <pipacs> i have whatever the linux makefile puts in there
[22:35:49] <pipacs> so for most kernel files __KERNEL__ should be defined somewhere, though i'm not sure it's defined on the cmdline itself
[22:36:05] <Zorry> pipacs:  will add __KERNEL__ to de ssp specs to disable it
[22:36:13] <klondike> I think that doesn't apply to plugins
[22:36:19] <pipacs> swift, there's 'ssp' use flag i think, only 'nossp'
[22:37:02] <pipacs> the problem is not with how the plugins are compiled, but when i compile my kernel with a plugin of mine, i want ssp off w/o having to do anything extra, just like in the old days ;)
[22:37:08] <SwifT> many devs don't like the idea that we have no* USE flags around - don't know if Zorry's going to stick with USE=nossp or use USE=-ssp
[22:37:10] <blueness> pipacs, there was a request among the gentoo devs to have ssp on by default even for the vanilla profile
[22:37:15] <Zorry> SwifT:  i think the nossp will be gone when the ebuilds and eclass get updatet to newer eapi
[22:38:07] <Zorry> pipacs: debian/ubuntu should have the same prob with ssp?
[22:38:10] <pipacs> blueness, i figured as much and i won't discuss that here (i have my reservations about the usefulness of ssp) but i'd like to have a way to get the old default
[22:38:21] <blueness> pipacs, can't you add the -fno-stack-protector flag to the build for the plugins?
[22:38:44] <pipacs> Zorry, i don't know, do they also turn on ssp by default? i'm not testing under debian so  can't tell ;)
[22:39:03] <Zorry> pipacs: ubuntu have it on by default for a long time 
[22:39:04] <pipacs> blueness, it's not about building the plugins
[22:39:14] <pipacs> i can build them fine with or without ssp
[22:39:19] <Zorry> and i think debian is on the way to do it to
[22:39:24] <pipacs> but i have a plugin that interferes with ssp and i need ssp off for that
[22:39:45] <pipacs> except now it's turned on (well, will be soon) and it means extra work for me for no gain ;P
[22:39:53] <Zorry> pipacs: we use the same patch as ubunto for the default ssp
[22:40:03] <pipacs> ok
[22:40:55] <pipacs> so does it mean that there's no built-in facility to fall back save patching one side or anotehr?
[22:41:06] <pipacs> +for
[22:41:23] <SwifT> Zorry: so the SSP patch won't be conditionally (USE flag) applied?
[22:41:23] <Zorry> pipacs: can you ceck when you have time if -D__KERNEL__ get pass to the plugins?
[22:41:39] <Zorry> SwifT: nope
[22:41:42] <SwifT> ok
[22:41:52] <klondike> maybe you can apply the reverse patch?
[22:42:01] <pipacs> Zorry, once again, it's not about 'to the plugins', the plugins compile/work fine with ssp enabled
[22:42:05] <klondike> as a user patch I mean
[22:42:19] <pipacs> but when plugins are *used* with gcc, one may not always want ssp enabled as well
[22:42:42] <pipacs> klondike, yes, that's the 'patch one side or another' is about ;)
[22:43:04] <pipacs> i just thought there'd be a fallback as before
[22:43:43] <klondike> would be nice...
[22:43:47] <pipacs> i can also forcibly disable ssp from within the plugin, so i have ways to work it around
[22:43:58] <blueness> pipacs, if -D__KERNEL__ turns off ssp, and its passed to the plugins, that should work, no?
[22:44:07] <pipacs> but i find it a bit weird that there's no way to easily get rid of ssp
[22:44:10] --> GurliGebis_ (~GurliGebi@toucan.home.gurlinet.dk) has joined #gentoo-hardened
[22:44:32] <Zorry> blueness: did add that for the default ssp specs but we have that
[22:44:39] <Zorry> did't*
[22:44:54] <blueness> k
[22:44:56] <pipacs> blueness, sure it may work for the kernel (i didn't check if all kernel files are compiled with -D__KERNEL__ passed to gcc vs. defined somewhere else)
[22:45:04] <pipacs> but i'll eventually need this  for userland as well
[22:45:25] <blueness> pipacs, oh, you mean you will have a plugin for *all* userland?
[22:45:30] <pipacs> yup
[22:45:42] <pipacs> same plugin will work for the kernel (replace ssp basically) and userland
[22:45:46] <blueness> k, i had no idea you were planning something like that
[22:46:11] <blueness> so does that mean we will want ssp off for all userland?
[22:46:19] <blueness> when we use your plugin?
[22:46:27] <pipacs> that's why i was talking about 'using plugins', and not 'compile the kernel' ;)
[22:47:02] <pipacs> well, that's up to the user to choose (there're some tradeoffs) but yes
[22:48:03] <blueness> Zorry, we may want another spec profile for this ^^^ i'm not sure yet, but keep that in mind
[22:48:23] <blueness> pipacs, at some point I'd like to see what you're planning
[22:48:29] <pipacs> basically, i miss the old distinction between the vanilla/ssp gcc profiles
[22:48:35] <pipacs> since now even vanilla has ssp on
[22:49:05] <SwifT> cd
[22:49:08] <pipacs> blueness, well, that's a while away and i won't make promises that all this will be released as it is
[22:49:32] <pipacs> but anyway i think i got my answers, continue the meeting ;)
[22:50:07] <klondike> we have to rubberhose pipacs to know?
[22:51:11] <Zorry> any one else ?
[22:51:18] <Zorry> blueness: do you have anything?
[22:51:48] <klondike> I have nothing, formatting on my thesis is killing me
[22:51:51] <pipacs> oh maybe one thing: the pax plugins support gcc 4.9 already so feel free to test them
[22:53:20] <blueness> Zorry, just that i'm working on musl + gentoo right now
[22:53:33] <blueness> not much to say, i'm only building rough stage4s
[22:53:46] <blueness> i've got amd64, i686 and armv7a done, and i'm working on mipsel
[22:53:56] <blueness> they are vanilla right now but i plan a full hardening
[22:54:06] <pipacs> blueness, how much of a drop-in replacement is musl for glibc?
[22:54:09] <blueness> this should expand our hardened offerings to more embedded systems
[22:54:17] <blueness> pipacs, not at all, unlike uclibc
[22:54:31] <blueness> uclibc's issue is mostly c header stacking which is messed up in places
[22:54:41] <blueness> but musl adheres very strongly to posix standards
[22:54:54] <blueness> and so you can expect a lot of work to get compatibility
[22:54:57] <pipacs> so i can't have a desktop with musl yet?
[22:55:06] <blueness> pipacs, i'm very close but no
[22:55:10] <blueness> not yet
[22:55:13] <pipacs> i see, no problem
[22:55:37] <blueness> its very tedious work, and most of the problems are not with musl but with packages
[22:55:47] <blueness> eg using PATH_MAX but not including limits.h
[22:56:43] <blueness> okay that's all from me regarding toolchain
[22:56:53] <Zorry> next then?
[22:57:08] <blueness> yes
[22:57:24] <Zorry> 2.0 Kernel Grsec/PaX
[22:58:23] <Zorry> blueness: ^^
[22:58:40] <pipacs> 3.14 is almost out of the door, so we'll move as well, however 3.13 will be maintained for longer (unless ubuntu lts moves to 3.14)
[22:59:08] <blueness> i'm just following upstream there haven't been any serious bugs lately
[22:59:10] <pipacs> and i don't know how much longer we'll maintain 3.2, but probably for this year
[22:59:41] <blueness> what about 2.6.32?   i can't believe that is still arround
[22:59:53] <pipacs> we stopped that already
[23:00:32] <blueness> pipacs, should i be dropping them?
[23:00:34] <klondike> I need 3.2 until I manage to make the silicom drivers into a proper patch :-(
[23:00:57] <lejonet> sillycom :P
[23:01:24] <pipacs> drop 2.6.32 for sure
[23:01:28] <pipacs> 3.2 not yet
[23:01:33] <lejonet> i-s'
[23:01:40] <blueness> pipacs, k i'll do that
[23:01:41] <pipacs> unless you don't care about 3.2 either of course
[23:01:49] <blueness> pipacs, we do care about 3.2
[23:01:49] <lejonet> isn't just debian stale that still uses 2.6.32?
[23:01:58] <lejonet> maybe centos 5 too
[23:02:27] <pipacs> some enterprise distros are on something vaguely  resembling it yes ;P
[23:02:40] <pipacs> but we never supported those forks anyway
[23:02:46] <blueness> lejonet, doesn't matter, if its not supported, it goes
[23:02:47] <lejonet> :P
[23:03:03] <SwifT> "Pull the lever, corky!"
[23:03:04] <lejonet> blueness: more of a anectdot of how long someone can hold onto something old...
[23:03:49] <SwifT> oh it's Kronk
[23:04:18] <klondike> for as long as there is proprietary crap depending on it
[23:04:39] <lejonet> klondike: fair enough :/
[23:05:20] <blueness> okay one more item with pax
[23:05:39] <blueness> i have install-xattr in the tree, that's the C wrapper for install to preserve xattrs
[23:05:40] <blueness> but
[23:05:50] <blueness> the portage folks have not integrated it yet
[23:05:58] <blueness> i've tried pinging dol-sen but nothing
[23:06:07] <pipacs> will it become a dependency of portage eventually?
[23:06:10] <blueness> so we are just one tiny step away from fixing the last issue
[23:06:16] <blueness> pipacs, yes it should
[23:06:41] <blueness> vapier and i went over it carefully and there were some users that tested
[23:06:45] <blueness> so its ready for production
[23:07:50] <pipacs> it could be a bit more verbose with error messages ;)
[23:07:56] <pipacs> like when it's invoked without any arguments
[23:08:00] <blueness> pipacs, patches accepted ;)
[23:08:07] <pipacs> touche ;P
[23:08:20] <blueness> pipacs, i tried to fall back on install as much as possible
[23:09:58] <ryao> Hi pipacs. Hi blueness.
[23:10:00] <blueness> Zorry, before moving on any idea how to get portage people to act on this?  with zmedico gone, i fear that is stalling
[23:10:05] <blueness> hi ryao
[23:10:20] <ryao> Hi klondike. Hi lejonet. Hi SwifT.
[23:10:27] <klondike> in ping the herd?
[23:10:29] <ryao> Is this the hardened team meeting?
[23:10:32] <Zorry> blueness: did we make patch for portage?
[23:10:33] <SwifT> hiya ryao - and yes, it is
[23:10:34] <klondike> yes
[23:10:47] <ryao> I see plenty of discussion so I thought I would say hi.
[23:11:06] <blueness> Zorry, that's the problem, i'm not exactly sure how to integrate it into portage because i'm not familiar with their evn variables, they way they do things
[23:11:12] <lejonet> ryao: o/
[23:11:17] <blueness> last time zmedico wrote a shell script wrapper to the wrapper
[23:11:20] <Zorry> blueness: okay
[23:11:27] <blueness> that was very strange and i didn't understadn why he did that
[23:11:42] <pipacs> blueness, how did you test it yourself with portage?
[23:11:43] <blueness> so maybe that can be patched, to look first for install-xattr
[23:11:46] <blueness> then install.py
[23:11:48] <ryao> Also, while everyone is able to lynch me at once, I will share a horrible thing that I have done locally. sys-kernel/rhel-sources.
[23:11:55] <blueness> pipacs, i hacked in a horribly way :)
[23:12:06] <SwifT> ryao: oh goodie, more old kernels
[23:12:07] <pipacs> ryao, after the meeting or when the relevant topic comes up, please ;P
[23:12:08] <SwifT> ;p
[23:12:10] <blueness> i basically just replaced install.py (the python wrapper) with install-xattr
[23:12:22] <blueness> but that's not correct because we need a cascade of fallbacks
[23:12:34] <blueness> so first we should look to see if isntall-xattr is there
[23:12:43] <blueness> (since it is a separate package it might now be)
[23:13:00] <blueness> and if not, then fall back on install.py which is guaranteed to be there because it is part of portage
[23:13:17] <blueness> and we should skip both if USE=-xattr is set
[23:13:38] <blueness> so basically i just short-circuited that logic when testing
[23:13:44] <Zorry> okay
[23:14:02] <blueness> Zorry, okay i'm done with everyting in need to talk about
[23:14:06] <Zorry> haven't look at the code yet
[23:14:32] <blueness> Zorry, maybe i'm over worried about it and should just submit somethign reasonable
[23:14:49] <blueness> next?
[23:15:20] <Zorry> pipacs: have thout to make patch for the gold linker for the pax header thing?
[23:15:23] <blueness> (brb going for coffee)
[23:15:39] <klondike> go fort something reasonable blueness
[23:16:10] <pipacs> Zorry, uhm i never worked with gold, so there're no patches for it
[23:16:16] <klondike> you could make install.py check for the other wrapper?
[23:16:31] <pipacs> is anyone using gold these days at all? ;)
[23:16:38] <SwifT> I had one user report...
[23:16:42] <Zorry> pipacs: i see more use of it
[23:16:47] <SwifT> so I disabled gold in my ebuild :p
[23:17:01] <pipacs> interesting
[23:17:31] <pipacs> well, with the progress on the xattr support front, i don't know if vapier would appreciate yet another patch for binutils to produce even more PT_PAX_FLAGS ;P
[23:19:25] <blueness> pipacs, i was just thinking that myself
[23:19:44] <blueness> gold has plugins but other than that, i'm not sure what advantage there is
[23:19:51] <pipacs> but if you can float the idea past him and there's some more interest in gold support, i can take a look
[23:19:55] <pipacs> but it'll be low priority
[23:20:01] <blueness> when i asked mgorny he said "because its better of course" ... of course
[23:20:13] <Zorry> udev 210 use gold
[23:20:23] <blueness> Zorry, but not eudev ;)
[23:20:30] <Zorry> !bug 503982
[23:20:32] <willikins> Zorry: https://bugs.gentoo.org/503982 "sys-fs/udev-210 installs executables without PAX headers"; Gentoo Linux, Core system; RESO, WORK; klaus.kusche:udev-bugs
[23:20:47] <blueness> Zorry, why did the systemd folks switch?  does anyone know?
[23:21:06] <pipacs> that's not a 'bug', as long as none of the udev binaries need something disabled on them
[23:21:12] <Zorry> blueness: don't know way but i think more packages will move
[23:21:13] <pipacs> and probably none of them do (or should even)
[23:22:54] <blueness> Zorry, maybe we can add logic to pax-utils.eclass to suppress warnings or attempts to add PT_PAX header when no flags are needed
[23:23:40] <pipacs> and you can always salvage GNU_STACK :)
[23:23:47] <blueness> true
[23:24:10] <blueness> next?
[23:24:28] <SwifT> please
[23:24:34] <Zorry> next
[23:24:57] <Zorry> 3.0 Selinux
[23:25:17] <SwifT> the 20140311 policies (released upstream) are in the portage tree, ~arch'ed for now
[23:25:27] <SwifT> so y'all can test them out if you like
[23:25:42] <SwifT> if you're on -9999 nothing much changed of course, as we track upstream already quite closely
[23:26:07] <SwifT> I also had some fiddling with libselinux' ebuild magic to enable multilib and other stuff I barely understand
[23:26:21] <SwifT> but it looks like the current latest rev works in all cases
[23:26:51] <SwifT> that's about it for SELinux
[23:27:00] <prometheanfire> found a small selinux based cve :D but it's fixed in recent kernel
[23:27:09] <SwifT> yup, I saw that
[23:27:12] <prometheanfire> that's all I have for it
[23:27:25] <prometheanfire> think you may have helped me with that (along with ryao)
[23:27:44] <cnnx> how can I prevent a dir from being listed in /etc/grsec/policy ?
[23:28:06] <cnnx> lets say i dont want my users to be able to go into etc
[23:28:13] <lejonet> cnnx: After the meeting please :)
[23:28:14] <Zorry> cnnx: we have meeting so take it after
[23:28:20] <cnnx> ok sorry
[23:28:22] <Zorry> next?
[23:28:34] <SwifT> yup
[23:29:10] <Zorry> 4.0 System Integrity
[23:29:55] <SwifT> the only thing worth mentioning here is that I did a few updates on the gentoo hardening guide (at http://dev.gentoo.org/~swift/docs/security_benchmarks/)
[23:30:22] <SwifT> the sources are in the hardened-docs git repo
[23:30:38] <SwifT> i'll do a blog post on all that funky stuff later
[23:30:50] <SwifT> that's it
[23:30:53] <blueness> SwifT, what is oval?
[23:31:06] <prometheanfire> I may have a system that I can work on for kernel signing and tpm instructions
[23:31:09] <prometheanfire> soon
[23:31:13] <SwifT> open vulnerability assessment language, an xml format to describe tests on systems to be ran
[23:31:27] <SwifT> unlike scripting, it's more "guaranteed" to be read-only tests
[23:31:55] <SwifT> and there are many tests that are platform independent
[23:31:58] <klondike> we have tpm boxes at the hackerspace if need
[23:31:59] <blueness> its a suite that you run on a system to look for vuns?
[23:32:08] <blueness> vulns
[23:32:11] <SwifT> yes, for vulnerabilityes or misconfigurations
[23:32:27] <blueness> hmm ... like bastille
[23:32:38] <SwifT> you can also run it to detect certain files (either through names or hashes), which is often used to make inventory scans (which software is installed on  system)
[23:33:27] <blueness> SwifT, is it openly available ... we can talk later ...
[23:33:37] <blueness> to not take up meeting time
[23:33:38] <SwifT> OVAL files can be "played" by tools such as openscap, ovaldi or joval, or by commercial utilities
[23:33:42] <SwifT> sure
[23:34:07] <prometheanfire> klondike: too much on my plate now to accelerate that, but thanks :D
[23:34:53] <Zorry> next?
[23:34:57] <blueness> okay
[23:35:05] <Zorry> 5.0 Profiles
[23:35:47] <Zorry> not any news from me on that
[23:35:53] <blueness> nothing much, i did add some stuff to hardened/uclibc to bring it in line with hardened/glibc stuff
[23:36:12] <blueness> basically i added ABI values for amd64 and x86
[23:36:44] <blueness> this is because those profiles are shallow and do not inherit the same stack
[23:36:55] <blueness> they skip profiles/arch
[23:37:13] <blueness> its nothing big but as mgorny pushes more multilib stuff they are needed
[23:37:26] <blueness> that's it from me on profiles
[23:37:42] <Zorry> so next then?
[23:37:50] <blueness> sure
[23:38:06] <Zorry> 6.0 Docs
[23:38:14] <Zorry> any one?
[23:38:18] <SwifT> not me
[23:38:32] <prometheanfire> non
[23:38:40] <Zorry> so next?
[23:38:58] <blueness> sure
[23:39:04] <Zorry> 7.0 Bugs
[23:39:17] <blueness> i had not major bugs
[23:39:23] <blueness> all my bugs were little ones
[23:39:34] <blueness> what happened with the -fstack-check and ffmpeg?
[23:39:46] <blueness> it worked for me, so maybe soemthing changed?
[23:40:11] <Zorry> blueness: it compile for me to so i don't know what change
[23:40:20] <blueness> okay don't worry about it then
[23:40:20] <Zorry> with the newer wersion
[23:40:24] <blueness> yeah me too
[23:40:34] <Zorry> the same with libav
[23:40:41] <blueness> k
[23:40:56] <Zorry> but virtualbox did fail with it :(
[23:41:03] <satmd> a week ago, someone in chat noted that there was a stable hardened-sources version that required an ~arch gradm
[23:41:06] <Zorry> but have patch it out
[23:41:44] <Zorry> blueness: ^^
[23:41:47] <blueness> satmd, that's easily fixed, i can stabilize
[23:42:28] <satmd> too bad I don't remember anything about it in detail and I just remembered during your meetup
[23:42:54] <blueness> Zorry, what was the error with virtualbox and -fstack-check?
[23:42:58] <blueness> did it run out of registers?
[23:43:36] <Zorry> blueness: something like that but i disable pie on that part to
[23:43:45] <klondike> most likely
[23:44:06] <blueness> yeah anything asm heavy can hit that
[23:44:17] <Zorry> blueness: it is on the ipxe part
[23:44:26] <blueness> interesting
[23:44:52] <klondike> yeah and I get to fix it, I can live with that I'd I wasn't so short on time
[23:45:12] <blueness> i've got to run soon, any other bugs we should mention?
[23:45:12] <klondike> ipxe? strange
[23:45:24] <klondike> not from me
[23:45:55] <blueness> okay i'm going to skip media and open floor
[23:45:56] <Zorry> the webkit-gtk textrel bug looks like it fixed upstrem (tested)
[23:46:05] <blueness> Zorry, yes it was
[23:46:09] <blueness> i noticed that
[23:46:12] <blueness> on x86
[23:46:16] <Zorry> thanks to klondike for the code part
[23:46:18] <blueness> (okay running now, later)
[23:46:29] <klondike> :-P
[23:46:41] <klondike> you owe me a photo Zorry
[23:46:41] <Zorry> next then?
[23:47:05] <Zorry> 8.0 Media
[23:47:09] <klondike> I have nothing to say in media as of now
[23:47:24] <klondike> didn't have time to arrange talks
[23:47:32] <SwifT> I just made a small write)up of today's session at http://blog.siphos.be/2014/03/online-hardened-meeting-of-march/
[23:47:39] <klondike> couldn't tweet from my phone :-(
[23:47:48] <klondike> thanks swift
[23:48:06] <SwifT> it'll be aggregated by planet.g.o in about 20 mins I believe
[23:48:16] -*- satmd waits for gentoo hardened running on my jolla :p
[23:48:28] <Zorry> next ?
[23:48:48] <klondike> Will tweet a link when I get home
[23:48:48] <SwifT> yyup
[23:48:54] <Zorry> 9.0 Open floor
[23:49:12] <Zorry> ty all for the meeting