[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-hardened
Subject:    [gentoo-hardened] Meeting log 2012-02-22 20:00UTC
From:       Magnus Granberg <zorry () gentoo ! org>
Date:       2012-02-28 0:11:08
Message-ID: 1719900.uiUd8STP9J () laptop1 ! gw ! ume ! nu
[Download RAW message or body]

Log from the meeting

/Magnus
["meeting-2012-02-22_20:00UTC.log" (meeting-2012-02-22_20:00UTC.log)]

[21:10:04] <Zorry> 1.0 new dev
[21:10:08] <lejonet> I am going to disappear a short moment, gotta put the TP cable \
differently :P [21:10:12] <Zorry> welcome to lejonet
[21:10:24] <-* prometheanfire has kicked lejonet from #gentoo-hardened (lejonet)
[21:10:32] <blueness> :)
[21:10:37] <prometheanfire> welcome in all the proper ways
[21:10:58] <ralos> you invite them back after a /kick
[21:11:06] <prometheanfire> ralos: you do
[21:11:14] <ralos> I did
[21:11:15] <lejonet> lol, thank you :)
[21:11:30] <Zorry> okay next?
[21:11:48] <blueness> yes
[21:11:56] <Zorry> 2.0 Toolchain
[21:12:15] <Zorry> we have 4.5.3-r2 stable on amd64 and x86 now :)
[21:12:31] <Zorry> and 4.7 is in the dev.overlay
[21:13:04] <lejonet> \o/
[21:13:17] <scarabeus> sucks i have use masked 4.6
[21:13:24] <scarabeus> i would love to use stable toolchain :)
[21:13:29] <Zorry> have disable randmmap on the cc1 and cc1-plus to fix the pch probs \
we have [21:13:45] <Bunta> o/
[21:13:47] <prometheanfire> Zorry: does 4.7 have the same issue as 4.6 with grub2?
[21:14:00] <Zorry> the bug on pch is upstream
[21:14:41] <Zorry> prometheanfire: it is grub 0.97 that have the gcc 4.6 prob
[21:14:58] <prometheanfire> oh
[21:15:22] <Zorry> prometheanfire: was allot of discuss on the -dev ml
[21:16:01] <Zorry> gcc 4.7 is till in stage4
[21:16:32] <Zorry> i still waiting to 4.8 hit stage1
[21:16:49] <Zorry> so i can try to get something upstream
[21:17:12] <Zorry> blueness: you did have something on uclibc
[21:17:17] <blueness> yeah
[21:17:37] <blueness> uclibc-0.9.32.2 has nptl/tls so that means we can now add ssp \
for full hardening [21:17:51] <blueness> it works very well
[21:17:59] <ryao> Zorry: Does GCC 4.7 solve the sys-boot/grub bug?
[21:18:05] <blueness> here's a summary of systems -> http://dpaste.com/706891/
[21:18:32] <blueness> here are stage4s -> \
http://opensource.dyc.edu/pub/stage4-uclibc/ [21:18:58] <ryao> blueness: Awesome and \
my Asus RT-N66U just shipped yesterday. [21:19:10] <blueness> it should now be \
possible to move forward with hardened on embedded systems [21:19:36] <blueness> i \
will target arm nexted [21:19:45] -*- lejonet hides his arms
[21:19:46] <blueness> and try to keep those stages up to date
[21:19:49] <Zorry> ralos: any plans to add .32 to the tree?
[21:20:18] <Zorry> ryao: haven't test grub and gcc 4.7
[21:20:34] <Zorry> blueness: :)
[21:20:57] <blueness> Zorry, i think by summer i'll add another hardened "subproject"
[21:21:16] <Zorry> k
[21:21:18] <blueness> i've been fighting many bugs and i should start to make some of \
them public [21:21:24] <blueness> ie bugzilla
[21:21:41] <klondike> Zorry: pong
[21:21:51] <Zorry> klondike: meeting
[21:21:57] <blueness> Zorry, unfortunately the way i've done uclibc .32 ebuild is to \
force a configuration, i'll have to rethink it before asking embedded to add it to \
the tree [21:22:02] -*- klondike fastly reads the backlog
[21:22:13] <Zorry> blueness: yee
[21:22:27] <blueness> Final point, the profiles/ebuilds are on hardened-dev overlay, \
uclibc branch] [21:22:40] <blueness> done with that report, any questions?
[21:23:09] <Zorry> okay next?
[21:23:22] <Zorry> 3.0 Kernel
[21:23:33] <Zorry> blueness: ^^
[21:23:51] <blueness> i'll talk about xtpax in section 5.0
[21:24:25] <blueness> there is nothing very new with the kernel itself, but there is \
one bug which Chainsaw privately told me about [21:24:43] <blueness> on 3.1.x and \
3.2.x which cause an early lockup [21:25:00] <blueness> he's sending me hardware to \
reproduce [21:25:34] <blueness> this was hit after a rapid stabilziation because of a \
/proc/<pid>/ leak [21:25:56] <blueness> other than that, the kernel is just moving \
along, [21:26:22] <blueness> prometheanfire, lejonet you two are going to be testing \
more for where we are with virtualization, correct? [21:26:58] <prometheanfire> yes, \
I thought you were gonna talk about that in 5.0 [21:27:03] <prometheanfire> more to \
do with that then kernel proper [21:27:12] <blueness> sure, we can
[21:27:19] <blueness> its mostly a pax issue
[21:27:47] <lejonet> blueness: correct
[21:27:50] <blueness> final point then, other than Chainsaw's issue and issues with \
virtualization, the hardened-sources kernel is in good shape [21:28:05] <blueness> \
rsbac-sources isn't getting much use, so very little feedback [21:28:16] <blueness> \
just one known (and happy) user [21:28:25] <lejonet> blueness: I am probably going to \
try it in a VM [21:29:07] <blueness> lejonet, that would be helpful, but as ralos \
said last time, there are not that many users, still it is being supported and easy \
for me to maintain [21:29:39] <blueness> i don't think it was a mistake to put it \
back on the tree, but i underestimated is popularity or lack of popularity [21:29:39] \
<prometheanfire> proxy maintainership? [21:29:52] <blueness> prometheanfire, no, i \
keep an eye upstream [21:29:56] <blueness> its just easy to do
[21:30:05] <Arach> spender and pipacs decided to support 3.2 kernel long term. \
Please, consider to keyword any other h-s beside 3.2 and 2.6.32 (for a while). \
[21:30:06] <blueness> its all git, so ... easy [21:30:17] <lejonet> blueness: I am \
both interested in RSBAC and want to try and help you test it to have atleast 2 users \
to get feedback from :) [21:30:24] <blueness> Arach, okay thanks
[21:30:32] <blueness> lejonet, thanks :0
[21:30:35] <blueness> err ... :)
[21:30:38] <prometheanfire> Arach: are you asking us to not stablize 3.3, etc when \
they come out? [21:30:39] <lejonet> xD
[21:31:07] <blueness> prometheanfire, mroe like keep 3.2 stabilized along with 2.6.32
[21:31:18] <blueness> so we may have 3 branches of stables
[21:31:21] <Arach> prometheanfire, yes.
[21:31:30] <blueness> 2.6.32,x 3.2.x and something else
[21:31:36] <prometheanfire> ok, just being clear
[21:32:07] <blueness> Arach, wait, there's no reason *not* to stabilize >=3.3 is \
there? [21:32:46] <blueness> as long as we stabilize 2.6.32.x, 3.2.x
[21:33:43] <Arach> blueness, there will be no stable grsec patches for >= 3.3, and \
very shortly it will lost support from both upstreams. [21:34:06] <blueness> okay, \
i'll just follow upstream [21:34:30] <blueness> any other questions, because i have \
more important stuff to talk about pax in 5.0 [21:35:00] <klondike> Yes
[21:35:20] <klondike> What does Arach means by not stable grsec patches for >=3.3 ?
[21:35:51] <blueness> klondike, upstream has their own way of labeling grsec patches \
as stable and testing [21:35:53] <summers> blueness: any notice from upstream re: the \
future of 2.6.32.x or an indication of what the next lts will be? [21:36:07] \
<prometheanfire> summers: 3.2 [21:36:11] <klondike> Ohh I see
[21:36:19] <summers> prometheanfire: for lts?
[21:36:24] <prometheanfire> yes
[21:36:30] <klondike> So we shouldn't expect stable patches for 3.3 ?
[21:36:42] <prometheanfire> if they are stable, only for a short time
[21:36:48] <blueness> summers, spender says he will continue support of 2.6.32.x past \
when upstream drops it [21:36:57] <klondike> understood
[21:36:57] <summers> really, wow
[21:37:03] <Arach> klondike, those will be test grsec patches, not stable ones. Only \
3.2 and 2.6.32 (for a while) will be treated as stable by spender and pipacs. \
[21:37:16] <summers> blueness: I know suse will continue using .32 for quite a while \
[21:37:18] <blueness> summers, he will back port security fixes [21:37:25] <summers> \
sweet [21:37:39] <blueness> mpagano and the gentoo kernel team have already dropped \
2.6.32 for gentoo [21:37:42] <summers> so he is ignoring the 3.0.x upstream lts
[21:37:59] <blueness> i've been filling in the gap by generating my own 2.6.32 \
patches [21:38:04] <blueness> for the bumps
[21:38:18] <blueness> summers, yes, spender *hates* 3.0.x
[21:38:23] <blueness> reasons unknown
[21:38:25] <summers> blueness: I still see 2.6.32-r41 in portage
[21:38:34] <summers> old I guess
[21:38:40] <blueness> yes, but -r41 is old
[21:38:50] <summers> huh, no big deal that 3.0 is ignored
[21:38:58] <blueness> look at the latest hardened-sources for 2.6.32 and you'll see \
that patch bumps i'm adding [21:39:07] <summers> so the choice is 3.2, fine by me. \
that kernel works nicely [21:39:31] <summers> I see it -r91 :)
[21:39:48] <blueness> summers, Chainsaw reports an issue with 3.2.2-r1 on HP DL 385 \
G2 [21:39:54] <blueness> early lockup
[21:40:04] <summers> ouch
[21:40:06] <blueness> other than that, i've heard nothing else bad
[21:40:09] <summers> wait, what cpu is that?
[21:40:13] <blueness> just the usual virtualization stuff
[21:40:13] <Zorry> move on?
[21:40:16] <blueness> summers, not sure
[21:40:19] <blueness> Zorry, yes
[21:40:21] <summers> xeon maybe
[21:40:27] <summers> sorry Zorry :)
[21:40:28] <blueness> guys, ask me questions in side channels
[21:40:42] <blueness> (or pm)
[21:40:43] <Zorry> 4.0 Selinux
[21:40:53] <Zorry> SwifT: prometheanfire ^^
[21:41:05] <SwifT> upstream released new base policy & new set of selinux tools
[21:41:13] <SwifT> I'm currently working on the ebuilds for the tools
[21:41:34] <SwifT> there are a couple of dependencies that I don't like (dbus & \
libcgroup) but I have been able to make them optional [21:42:05] <SwifT> once the \
tools are done and all tests succeed, I'll bring those to the overlay and then work \
my way through the new base policy [21:42:21] <SwifT> I *hope* there isn't too much \
trouble on the policy, seeing that almost 50% of the patches in it are ours ;) \
[21:42:37] <Zorry> :) [21:42:47] <prometheanfire> for current policy - I've been \
testing from the hardened-dev overlay, no issues for me [21:43:08] <SwifT> other than \
that, latest -r13 is in overlay and will be brought to portage tree soon; I'll also \
stabilize the -r11 release with that and clean up the older ones [21:43:29] <SwifT> \
that's it for me [21:43:38] <Zorry> any one else?
[21:44:01] <Zorry> 5.0 Gsec/PaX
[21:44:06] <Zorry> blueness: ^^ 
[21:44:43] <prometheanfire> blueness: you go first
[21:45:56] <prometheanfire> well, I'll go
[21:46:13] <blueness> k
[21:46:22] <prometheanfire> I've been testing hardened on intel hosts from about \
2.6.31 up til now [21:46:46] <prometheanfire> and recently on a proc with nested \
paging support [21:47:14] <prometheanfire> for hosts on intel procs without nested \
paging uderef makes the guest unbootable (same with kernexec) [21:47:16] <blueness> \
prometheanfire, you mean virtualization, correct? [21:47:56] <prometheanfire> for \
hosts on intel procs WITH nested paging uderef makes the guest bootable but very slow \
kernexec makes guests unbootable still [21:48:06] <prometheanfire> blueness: yes, I'm \
talking about kvm virt specifically [21:48:17] <prometheanfire> I will have to defer \
to lejonet about amd [21:48:20] <prometheanfire> EOL
[21:48:44] <blueness> prometheanfire, it would be nice to have a chart like this -> \
http://dpaste.com/706905/ [21:48:46] <lejonet> Yeah, I will be testing the AMD parts \
of that [21:49:03] <blueness> lots of variables though
[21:49:15] <prometheanfire> blueness: you mean like this?     \
http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=blob_plain;f=html/hardened-virtualization.html;hb=877d7d12b2d0d0431a6c137012181cee4742e1ba
 [21:49:28] <prometheanfire> I am going to be going over that in docs :D
[21:49:35] <blueness> good
[21:50:15] <Zorry> can test on amd to later on
[21:50:33] <blueness> prometheanfire, it would be nice where someone can just look up \
their CPU, their choice of virtualization, and whether they're using x64_64 or i686 \
and decide what needs to be turned on or foff [21:51:32] <blueness> its a lot of \
variables! [21:51:33] <Bunta> testing would include VMware and VBox?
[21:51:48] <blueness> Bunta, we're concentrating on kvm and vbox
[21:51:52] <lejonet> blueness: one part of redoing cronus is that I am going to give \
Xen another stab and see if I can get it running this time [21:52:27] <blueness> k
[21:52:37] <blueness> so we can add xen to the mix
[21:52:47] <Zorry> Vbox need to testing now the compile error is fixed
[21:53:06] <prometheanfire> I hope to be able to test xen at some point
[21:53:21] <blueness> Zorry, that's right, and you can remove my preinstall message \
about switching to hardened-nopie [21:53:31] <prometheanfire> I also am not able to \
test i686 atm [21:53:33] <lejonet> xen is just a... beast to setup, I did it 8/10 of \
the way last time but then just said bleeeh [21:53:41] <lejonet> prometheanfire: me \
neither :/ [21:53:48] <Zorry> blueness: is allready done in the bump
[21:53:55] <blueness> prometheanfire, lejonet fill in as much of the table as \
possible, but like i said, there are lots of variables [21:54:08] <lejonet> blueness: \
hai, senpai :) [21:54:30] <prometheanfire> ya, I might use another HDD to run i686 \
sometime, maybe [21:54:57] <blueness> i would prioritize amd64 for arch and intel for \
processor [21:55:12] <prometheanfire> easily done :D
[21:55:20] <blueness> k
[21:55:50] <blueness> next?
[21:56:02] <blueness> i need to talk about xattr_pax
[21:56:10] <Zorry> go on
[21:56:21] <blueness> pipacs has the code in the kernel, and it depends on "expert"
[21:56:30] <blueness> i've added a use flag to turn it on, "xtpax"
[21:56:45] <blueness> we'll be using that flag on both the kernel and userland \
utilities [21:57:12] <blueness> i've tested the kernel and it works, but pipacs' \
implementation in xattr was different than mine [21:57:32] <blueness> he uses the \
ascii letters PpMmRrEe [21:57:46] <blueness> whereas i did the binary values as they \
are in PT_PAX [21:58:12] <blueness> soooo ... my userland utility, paxctl-ng, in the \
elfix package needs to be updated [21:58:15] <blueness> but
[21:58:31] <blueness> for the brave, you can use getfattr and setfattr to set pax \
flags [21:58:39] <blueness> in extended attributes
[21:59:08] <blueness> once i get the userland utilities working with xtpax, i'll \
unmask the package and then we need to move forward: [21:59:19] <blueness> 1. \
deprecated EI_PAX with is horribly broken [21:59:47] <blueness> 2. set PT_PAX and \
(optinoally) XATTR_PAX on filesystems which can handle it [21:59:59] <prometheanfire> \
ralos:  still ueses ei_pax I thought [22:00:20] <blueness> 3. (not sure here) create \
a new system with no PT_PAX at all, not even in binutils [22:00:31] <blueness> and \
pure XATTR_PAX, [22:00:57] <blueness> but i'm not sure about the last point, it might \
not happen until there is very extensive xattr support everywhere [22:01:16] \
<blueness> hopefully by next month, i'll be on step 2 [22:01:16] <ralos> \
prometheanfire: EI_PAX for what? [22:01:31] <blueness> prometheanfire, EI_PAX is very \
borked [22:01:50] <ralos> limited. Main problem is it's not strip safe
[22:01:54] <blueness> if you chpax on libc.so.6 for example, you'll break your whole \
system [22:02:00] <ralos> thus PT_PAX was born
[22:02:11] <blueness> ralos, no its worse 1 sec
[22:02:29] <blueness> https://bugs.gentoo.org/show_bug.cgi?id=387459
[22:02:33] <prometheanfire> ralos: your gcc trick?
[22:02:34] <blueness> ralos, ^^^
[22:02:37] <prometheanfire> or glibc that is
[22:03:02] <ralos> really? EI_PAX really just takes advantage of an unused segment in \
an elf [22:03:24] <ralos> openwall used a method just like it. (thats where pipacs \
got the orig idea from) [22:03:27] <prometheanfire> anyway, if you don't know what \
I'm talking about ignore me [22:04:18] <blueness> ralos, its not unused anymore :)
[22:04:32] <blueness> blame .... ready for it ..... drepper!
[22:04:57] <blueness> glibc commit 04f2902d9fadb2b8221162247412fb2c4667d95e from Mar \
18 2010 [22:05:23] <blueness> any other questions?
[22:05:45] <ralos> figures..
[22:06:10] <Zorry> next then?
[22:06:11] <blueness> ralos, that was our out for self-checking binaries where you \
can't add PT_PAX [22:06:20] <blueness> now our out will be xattr_pax
[22:06:32] <blueness> yeah next
[22:06:42] <ralos> blueness: it only breaks on libc.so itself?
[22:06:57] <ralos> which in a normal world you would not chpax anyway
[22:07:12] <Bunta> normal :)
[22:07:39] <ralos> "next"
[22:08:03] <Zorry> 6.0 Profiles
[22:08:08] <blueness> ralos, no breaks everywhere, i just mention glibc
[22:08:56] <blueness> Zorry, no major changes i think, just unmask the opencl for the \
ati people [22:09:15] <Zorry> if you have seen in the -dev ml there was some \
disccusion on the profile and dupes linking in [22:09:26] <blueness> oh that yeah
[22:09:42] <blueness> that's the "bigger" profile question
[22:09:51] <Zorry> yeep
[22:10:19] <Zorry> and is outside or scope
[22:10:21] <blueness> if there is some major change to the overall profile structure, \
we'll have to revisit the hardened profiles [22:10:47] <blueness> it is, but we have \
to keep an eye out, otherwise we can be left broken! [22:10:56] <Zorry> yep
[22:12:10] <Zorry> next?
[22:12:18] <blueness> yeah
[22:12:24] <Zorry> 7.0 Docs
[22:12:43] <prometheanfire> I'm going to be updating \
http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=blob_plain;f=html/hardened-virtualization.html;hb=877d7d12b2d0d0431a6c137012181cee4742e1ba \
as I test stuff [22:12:59] <prometheanfire> klondike: you gonna help me publish later \
then? [22:13:10] <klondike> Yes, that I can do
[22:13:26] <SwifT> no feedback from me on docs
[22:13:39] <prometheanfire> EOL
[22:14:00] <Zorry> anyone else?
[22:14:18] <blueness> as much as i hate writing docs, i will have to probably write \
something once the xattr_pax work is done [22:14:24] <blueness> otherwise it'll never \
get used [22:14:27] <klondike> ^
[22:14:29] <klondike> Me
[22:14:39] <lejonet> I will try and summarize my experience with battling fglrx
[22:14:48] <klondike> revdep-pax doc is progressing
[22:15:00] <klondike> I will try to get it done as soon as I can
[22:15:00] -*- SwifT doesn't mind helping out with docs either
[22:15:06] <SwifT> working on (general) docs as we speak anyhow ;)
[22:15:22] <klondike> afterwards I'll kill blueness and do the xattr_pax doc if it is \
necessary [22:15:30] <blueness> lol
[22:15:41] <blueness> i think i have to write something, even if its just sketchy
[22:16:15] <blueness> its not a self-evident thing
[22:16:30] <klondike> Oki you write the sketch I felsh it out :P
[22:16:33] <blueness> k
[22:17:08] <Zorry> next?
[22:17:31] <blueness> yep
[22:17:34] <prometheanfire> yep
[22:17:35] <Zorry> 8.0 Bugs
[22:17:46] <Zorry> anything?
[22:18:04] <SwifT> the initramfs support and selinux is being a pita
[22:18:37] <SwifT> I am able to get the system in enforcing mode *after* switching \
root, but never before [22:18:42] <SwifT> not even when the policy is part of the \
initramfs [22:19:17] <SwifT> for some reason, the initramfs that dracut generates \
doesn't want to hold the security labels, even though tmpfs is built with xattr \
support :/ [22:19:39] <SwifT> I lowered the priority for that one so I can first \
focus on the new policies and tool,s but will work on that once the policies are \
updated [22:19:39] <ss23> Punch it in the face
[22:19:54] <blueness> SwifT, you need to enable xattr in tmpfs in the kernel too
[22:20:09] <SwifT> blueness: it is, otherwise my system wouldn't work (without \
initramfs too) [22:20:09] <blueness> and maybe in squashfs, or whatever dracut users
[22:20:21] <SwifT> it's just an archive extracted in a tmpfs
[22:20:29] <blueness> SwifT, tar?
[22:20:34] <SwifT> I'm going to add some debugging utilities to the initramfs to make \
sure all gets done well [22:20:49] <klondike> hum
[22:20:52] <blueness> SwifT, use tar-1.26-r1 which has xattr support
[22:20:56] <SwifT> blueness: not sure, but I can't restore the attributes either, it \
sais "operation not permitted" [22:21:00] <blueness> ah!
[22:21:02] <blueness> yes
[22:21:13] <blueness> try tar-1.26-r1
[22:21:18] <SwifT> i'll do that
[22:21:26] <SwifT> (after the policies are updated )
[22:21:30] <blueness> 1 sec, i'll give you the bug
[22:21:34] <klondike> blueness: SwifT you should take into account that the initramfs \
is placed by the bootloader [22:21:56] <blueness> SwifT -> \
https://bugs.gentoo.org/show_bug.cgi?id=382067 [22:22:08] <klondike> I think \
decompression is done later by the kernel but in that case the kernel need to we \
aware of xattrs on tar files [22:22:08] <blueness> klondike, hmm true
[22:23:18] <blueness> klondike, i'm not sure what the fate of the labels will be \
under those circumstances [22:23:27] <blueness> but
[22:23:40] <blueness> you can now put xattr labes in tarballs with that patch for \
tar-1.26 [22:23:52] <blueness> it has a small problem which Arfrever noted
[22:24:15] <klondike> yeah but, will the kernel understand them when generating the \
FS? I think no :( [22:24:27] <blueness> but its just that i used the header from \
glibc rather than xattr, but they are almost identical [22:24:37] <blueness> \
klondike, i think you're right [22:24:43] <blueness> SwifT, is there a bug number?
[22:25:39] <SwifT> blueness: I track through bug #397567
[22:25:42] <willikins> SwifT: https://bugs.gentoo.org/397567 "initramfs (dracut) \
fails to boot up a SELinux system in enforcing/strict mode"; Gentoo Linux, Hardened; \
CONF; swift:selinux [22:26:25] <blueness> k
[22:26:31] <SwifT> *sigh* need to rebuild 37 packages with -ggdb to track a segfault \
which I'm sure will be something stupid [22:27:52] -*- lejonet has -ggdb in his \
CFLAGS... [22:29:15] <Zorry> next?
[22:29:40] <blueness> yeah, i can't think of any big long standing bugs
[22:29:48] <blueness> that we haven't discussed before
[22:29:52] <Zorry> 9.0 Media
[22:29:57] <blueness> like the python rwx mmap is still out there
[22:30:00] -*- prometheanfire noticed the twitter
[22:30:02] <blueness> nothing to say about it
[22:30:10] <klondike> Yay
[22:30:30] <klondike> Well we keep summarising the meeting "live" on twitter and \
identi.ca [22:31:01] <klondike> I suppose you also know that any hardened dev should \
have access to both so if you need the password please ask for it [22:31:17] \
<klondike> Little more to say, popularity is increasing slowly :D [22:31:49] \
<klondike> Also [22:32:02] <klondike> now that the talk lejonet and me gave at fosdem \
is up [22:32:04] <lejonet> I will have a 45 mins for presentation where I will speak \
a lot about hardened the 5th of march :) [22:32:20] <klondike> We should link it on \
the project page along with slides [22:32:41] <klondike> I think it can be useful \
since it summarized most of the points behind the project [22:33:00] <klondike> \
lejonet: need material for that presentation? [22:33:10] <lejonet> for my classmates
[22:33:12] <prometheanfire> I may be using your slides, klondike, to present at a lug \
also [22:33:35] <lejonet> klondike: Nah, I got the slides from FOSDEM, but I am \
probably going to freeball it because the level of knowledge is a bit too low in \
general for even the rather informative slides [22:33:40] <klondike> prometheanfire: \
I strongly suggest you see the FOSDEM video before, it will give you some ideas \
[22:33:54] <blueness> holy shit klondike nice live feed on twitter! [22:33:55] \
<prometheanfire> klondike: I have [22:34:08] <klondike> lejonet: I can try to plan to \
be on Stockholm by that date [22:34:29] <lejonet> klondike: only if you assist me in \
swedish ;) [22:35:08] <klondike> That I shouldn't do :P
[22:35:33] <Arach> blueness, the python bug drives me crazy. My patch is working, \
but... when I disable the added option and expect python to crash, instead it \
completes all ctypes tests without a single PROT_WRITE|PROT_EXEC mapping! [22:35:42] \
<Arach> blueness, drives me crazy, literally. [22:35:53] <lejonet> Arach: would you \
be in here if you had sanity left? [22:36:30] <Zorry> klondike: any more on the \
media? [22:36:37] <klondike> Zorry: nope
[22:36:45] <Zorry> okay
[22:37:15] <Zorry> was nice to meet lejonet SwifT klondike Aleister on fosdem
[22:37:27] <lejonet> Zorry: agreed :)
[22:37:33] <Zorry> hope we can get blueness and prometheanfire there to
[22:37:40] <Zorry> next year
[22:37:42] <klondike> Yeah
[22:37:55] <blueness> prometheanfire, maybe we should talk about traveling together, \
not sure if that's easier or harder [22:38:12] <SwifT> ;)
[22:38:13] <prometheanfire> we'd both be going through nyc I'd imagine
[22:38:19] <blueness> maybe
[22:38:53] <Zorry> 10.0 Open floor



[prev in list] [next in list] [prev in thread] [next in thread]