On Saturday 26 February 2011 18.09.26 you wrote: > Hi > > Sending the log fomr the meeting. > > /Magnus (zorry) sorry did forget the log
/zorry
[21:08:15] <Zorry> okay lest start then [21:08:21] <blueness> k [21:08:25] <Zorry> 1.0 toolchain [21:09:07] <klondike> pchrist: np [21:09:08] <Zorry> glibc 2.13 was added in ~ and we hit some bugs with that and i hope it will be fixed in next patch bump [21:09:44] <Zorry> and i will se if i can get the sigaction fix in there to [21:09:56] <Zorry> and gcc 4.6 is still in the overlay [21:10:20] <Zorry> else i dont have any more [21:10:28] <Zorry> some one else? [21:10:56] <blueness> it looks like we're waiting for toolchain people to clean up before moving on glibc 2.13 [21:11:10] <klondike> Zorry: do we have a tracker bug for glibc 2.13? [21:11:27] <Zorry> klondike: toolchain have one [21:12:20] <blueness> next? [21:12:29] <Zorry> 2.0 kernel [21:12:49] <Zorry> blueness: speek [21:12:53] <blueness> okay i've been working on restructuring the predefined gentoo security levels [21:13:29] <blueness> i've already got the latest ebuilds for .32 and .37 have the new structure and i emailed the list to test. so far no one complained [21:13:35] <blueness> the new structure has 3 levels [21:13:50] <blueness> server - almost everything on, rbac on by default but can be turned off [21:14:14] <blueness> workstation - diable i/o is off (needed for X and others), KERNEXEC and UDEREF on by default but can be turned off [21:14:31] <blueness> virtualization - same as workstation, but KERNEXEC and UDEREF are off and cannot be turned on [21:15:12] <blueness> i looked at kvm and virtualbox and they both have great performance hits with KERNEXEC and UDEREF [21:15:30] <blueness> so i'm compromising some security, and i note it in the <HELP> [21:15:35] <klondike> That's because of the PER_CPU_PGD [21:15:53] <blueness> yes they both enable a hidden variable PER_CPU_PGD which is the main problem [21:16:17] <blueness> also [21:16:50] <blueness> i have given lots of love to amd64, x86 and ppc64, ppc is still problematic. i'm going to try to get a stable ppc kernel in there [21:17:03] <blueness> so that's what i'll be working on next [21:17:13] <blueness> and on more announcement about the kernel [21:17:47] <blueness> pageexec added an interesting feature, a backwards compatible setting for mmap behavior [21:18:17] <blueness> its a little late, but that reverts the behavior of mmapping to the old style *before* it broke python! [21:18:39] <blueness> anyhow we fixed the python bug, but if another one pops up, it is possible to revert to the old behavior [21:18:54] <blueness> okay that's it for kernel (not selinux) [21:19:05] <blueness> questions? comments? criticisms? [21:19:12] <Zero_Chaos> blueness: love you [21:19:37] <Zorry> next then? [21:19:41] <blueness> sure [21:19:47] <klondike> wait [21:19:49] <klondike> one thing [21:20:09] <klondike> blueness: are you sure bug 356191 is not caused by the new levels? [21:20:11] <willikins> klondike: https://bugs.gentoo.org/356191 "hardened-sources 2.6.37 unable to load modules"; Gentoo Linux, Hardened; RESO, WORK; sa...@satmd.dyndns.org:hardened@g.o [21:20:30] <klondike> The reporter commented that it may be the case :/ [21:21:03] <blueness> klondike, i'm not able to reproduce and the reporter closed it as worksforme [21:21:06] <blueness> have you tried? [21:21:31] <klondike> Nope but the reported noted that [21:21:39] <blueness> also modprobe and insmod return "Invalid module format", dmesg shows errors about [21:21:40] <blueness> "overflow in relocation type 11": [21:21:40] <blueness> seems like he has other issues [21:22:26] <blueness> klondike, yes? [21:22:53] <klondike> Read comment 3 and you'll see what I mean [21:23:38] <blueness> this? -> "I am starting to think grsec is missing to select some options." [21:23:45] <klondike> yes [21:23:53] <klondike> Well anyway I'll try to take care of the bug and report you on it [21:24:07] <blueness> i can't make sense of that, like i said, i couldn't reproduce that. [21:24:26] <blueness> klondike, thanks yeah, if you can give me step by step how to hit it then it would help [21:24:48] -*- klondike now has a hardened MV :D [21:25:10] <klondike> Well that was all [21:25:11] <blueness> his original "Invalid module format" suggests there is some mismatch of kernel modules and running kernel versions [21:25:26] <blueness> which is why i think something else is going on there [21:25:37] <Zorry> +1 [21:26:06] <blueness> next? [21:26:10] <Zorry> 3.0 selinux [21:26:23] <Zorry> gizmobile: SwifT blueness [21:26:39] <SwifT> who's first? ;) [21:26:41] <blueness> Okay very brief, just to keep everyone up to date. i committed all of SwifT and gizmo's work to the tree [21:26:50] <klondike> :D [21:26:52] <klondike> Cool [21:27:15] <gizmobile> SwifT: you wanna go? you've done most of the work [21:27:46] <SwifT> blueness: yup, thanks for that. there is already a few updates in the hardened-dev git again :) [21:28:05] <blueness> SwifT, okay, i'll put them in. [21:28:09] <blueness> oh i almost forgot!!!! [21:28:17] <blueness> one more important announcement [21:28:40] <blueness> since hardened is diversifying, i thought to keep bugs better tracked, we'd create a selinux herd [21:28:54] <blueness> so all selinux related packages have bugs reported to seli...@gentoo.org [21:29:10] <Zorry> k [21:29:19] <blueness> got PeBenito blessing for that [21:29:45] <blueness> if anyone wants to be on the selinux mailing list, ask away [21:29:53] <SwifT> great, if I create new packages for anything I'll make sure the metadata.xml contains <herd>selinux</hard> instead of hardened then [21:30:07] <blueness> SwifT, yes please [21:30:22] <gizmobile> blueness, also closed a bunch of Linux bugs, tnx for that [21:30:23] <blueness> SwifT, do you want to say something about your package naming idea. i think its good and the group should know [21:30:41] <SwifT> sure [21:30:58] <SwifT> but perhaps thats more for the docs part... I'd rather first talk a bit about the policy packages [21:31:16] <blueness> SwifT, k [21:31:32] <SwifT> the selinux policies that we offer (sec-policy/selinux-*) are pretty usable (at least on my systems and virtual environments) [21:32:03] <SwifT> they have not gotten much server coverage as of yet though. I'm going to scan through various online tutorials and build up test sets to test serverrelated aspects too in virtual environemnts [21:32:10] <SwifT> like apache, mysql, postgresql, openldap, ... [21:32:26] <SwifT> 'cause I think most people are interested in SELinux for server environments =) [21:32:51] <SwifT> i know that tutorials and test sets aren't the same as real usage, but it's as far as I can take it for the time being as I have no servers here [21:33:02] <blueness> (SwifT, true server and ideal strict rather than just target) [21:33:11] <SwifT> I only test strict :) [21:33:51] <SwifT> second, the patches that we're introducing (against tresys' refpolicy) are being integrated upstream... most gentoo patches have already been accepted (gentoo_dontaudit_* notwithstanding) [21:34:18] <SwifT> so hopefully the next release of tresys refpolicy will allow us less patching and keep our policy clean wrt the reference policy [21:34:33] <slyfox> oh, btw. i've noticed sec-policy/selinux-slocate package in gx86. is it needed? slocate is gone [21:35:03] <SwifT> now, on the patching, most patches for selinux-base-policy are put in the files/ folder in a .tbz2 file which can grow (which isn't nice for the portage tree), so we might need to look to place those elsewhere [21:35:19] <SwifT> slyfox: slocate is the selinux module, it should match the locate/mlocate tools as well afaik [21:35:28] <slyfox> ah, ok [21:35:33] <SwifT> slyfox: but I'll note it down and check to be sure [21:35:59] <SwifT> and finally, regarding the policy packages, we might want to clean the old ones up? [21:36:00] <Aleister> mlocate is now being advocated in the handbook. [21:36:40] <SwifT> I'm going to suggest the cleanup on gentoo-hardened@g.o but for the patchset (.tbz2 file) I'm afraid I'll need some guidance on that [21:36:56] <blueness> SwifT, k [21:37:22] <SwifT> that's all I have to say on the selinux packages/policy stuff (I'll talk about the docs and naming stuff in the docs section, k?) [21:37:39] <blueness> SwifT, k [21:37:44] <Zorry> SwifT: will it be alot of bumps on the tbz2 file ? [21:38:03] <SwifT> Zorry: sadly, most bump in policies will require a bump in selinux-base-policy [21:38:24] <Zorry> k [21:38:26] <SwifT> reason is that selinux-base-policy contains all interfaces for a system, so the moment a new interface is added or an interface is updated, selinux-base-policy needs to be bumped [21:38:51] <SwifT> (interface == policy not local to a single tool, f.i. allow sysadm to read something --> interface). [21:39:55] <Zero_Chaos> mlocate is not secure as it allows you to search for other people's files. [21:39:59] <Zero_Chaos> kind of a concern imho [21:40:56] <Zorry> next ? [21:41:00] <gizmobile> all i've got is the patch to openrc that I submitted and was finally accepted [21:41:14] <Zorry> good [21:41:18] <SwifT> gizmobile: about the rc and wrapper stuff? great [21:41:26] <gizmobile> yes [21:42:37] <blueness> anything more? [21:42:48] <gizmobile> not here [21:42:50] <SwifT> nope [21:42:54] <klondike> the main page [21:42:59] <klondike> but better for docs too [21:43:04] <blueness> yep [21:43:14] <Zorry> 4.0 profiles [21:43:32] <Zorry> gengor: blueness [21:43:44] <blueness> Okay here's the situation there ... [21:44:05] <blueness> we weren't planning on revisiting the profiles but Arfrever did a cleanup which exposed some issues [21:44:06] <gengor> :O [21:44:22] <gengor> Zorry: pong [21:44:53] <Zorry> gengor: welcom to the meeting [21:45:18] <blueness> i made an old change which wasn't satisfactor. it lead to bugs #356149 and bug #355915 [21:45:19] <willikins> blueness: https://bugs.gentoo.org/355915 "Hardened profiles inadvertently enable the unicode USE flag"; Gentoo Linux, Hardened; RESO, FIXE; franxisco1988+gen...@gmail.com:hardened-kernel@g.o [21:45:30] <blueness> bug #356149 [21:45:32] <willikins> blueness: https://bugs.gentoo.org/356149 "USE x264 suddenly masked on hardened/linux/amd64/no-multilib"; Gentoo Linux, Hardened; REOP; cht...@longitekk.com:hardened@g.o [21:45:55] <Zorry> blueness: added some more stuff to clean in #355915 [21:46:12] <gengor> blueness: fwiw spender added MPROTECT_COMPAT, paxteam was against it [21:46:14] <blueness> gengor, and i have been looking at some new profile stacking which hopefully will make hardneed profiles easier to manage [21:47:05] <blueness> current we're happy with x86, amd64 and ia64 new profiles, i'll commit those changes soon and then start with the cleanups Zorry mentions above [21:47:14] <blueness> i'm still testing/working on ppc32 and ppc64 [21:47:31] <blueness> (gengor, i wasn't aware of that about MPROTECT_COMPAT) [21:48:24] <blueness> nothing more really, hopefully this will be the end of the profile issue for a while :) [21:48:48] <Zorry> blueness: i will start to mess with the pic use flag on the amd64 profile when your stuff is done [21:49:22] <blueness> Zorry, i'll do it after the meeting then. i'll first commit the updated stacking to amd64, x86 and ia64 and then do the cleanup [21:49:23] <Zorry> bug 348050 [21:49:26] <willikins> Zorry: https://bugs.gentoo.org/348050 "[Tracker] remove pic use flag as default on amd64 hardened profile"; Gentoo Linux, Hardened; NEW; zorry@g.o:hardened@g.o [21:49:28] <-- NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has quit (Disconnected by services) [21:49:34] <blueness> one step at a time, checking each step of the way for breakage [21:50:03] <Zorry> okay will start with it in the weekend then [21:50:05] <blueness> gengor, i assume your okay with the latest stackings (your patch) for amd64, x86 and ia64 and I can commit after the meeting? [21:50:21] <blueness> i'll defer ppc32/64 for a bit [21:50:27] <gengor> my 2c: all tweaking should be on hold until the structure problem is resolved. once that is done blueness/me/whoever does that initial round of cleanups (where things are crufty or the new structure allows de-duplication) and then an "all clear" is given to further mess with flags [21:50:46] <gengor> blueness: yessir, x86/amd64/ia64 the sooner the better imo [21:51:27] <Zorry> k [21:51:28] <blueness> gengor, i'll commit [21:52:24] <gengor> what is this about removing pic USE flag btw? [21:52:50] <blueness> after the stacking commit i think [21:52:51] <Zorry> gengor: most stuff on amd64 don't need to disable asm code [21:53:26] <gengor> gotcha [21:53:27] <gengor> hmm [21:55:39] <blueness> done with profiles? [21:56:18] <Zorry> gengor: ^^ [21:56:31] <gengor> yeah, fwiw I'm on board with the amd64-pic thing. [21:56:58] <gengor> would need to experiment a bit, but looks like it should be ok/right thing to do [21:57:27] <Zorry> runing php gzip mesa without the pic flag now [21:57:33] <gengor> yeah [21:57:49] <blueness> :) [21:58:05] <gengor> those are the 3 major [21:58:07] <gengor> maybe xvid [21:58:40] <gengor> cool [22:00:32] <blueness> next? [22:00:35] <Zorry> was thinking to turn it off as default per package for a start and leter on the profile [22:01:25] <Zorry> so we take it step by step [22:02:21] <Zorry> done [22:02:34] <Zorry> 5.0 Docs? [22:02:36] <gengor> we can also cross that road when we get there [22:03:46] <SwifT> on "selinux-policy.xml", that's a document that provides the guidelines (perhaps policy is a bit harsh?) on how selinux development for gentoo hardened should be done. It explains the principles used, why things are done in a certain way and more [22:04:00] <SwifT> for instance, the naming convention for the sec-policy/selinux-* packages is one of the aspects [22:04:23] <SwifT> such policy/guideline allows multiple developers to use the same principles for the project, offering a more robust and integrated development pattern [22:04:47] <SwifT> of course, it's a living document which should adapt to whatever is necessary, but I believe it is a nice to have [22:04:58] <klondike> SwifT: we are engineers not salesmen :P [22:05:01] <SwifT> especially in case when new developers join (or olders leave) [22:05:29] <SwifT> klondike: I know, it's perhaps a bad habit of mine as I need to slap engineers at work all the time with policies :) [22:05:49] <SwifT> but honestly, without such conventions you'll have a plethora on development patterns and users might get confused [22:05:59] -*- klondike agrees [22:06:15] <SwifT> even developers can get confused if there's no real guideline on how to deal with things... think about (code) developers, they also need a coding style to agree upon [22:06:40] <SwifT> and if you're talking about security policies, which are *very* susceptible to personal feelings... [22:06:44] <blueness> SwifT, perhaps explain why the naming convention is needed [22:07:38] <SwifT> well, the naming convention allows (1.) developers to know if a policy module/package exists for a certain case already or not, (2.) ensures that there are no collisions now or in the future and (3.) sticks to the upstream modules so it is easier for users and developers to understand what is in the package [22:08:03] <SwifT> the collision aspect is important... we don't want a naming convention that allows packages with the same name for different things [22:08:55] <SwifT> the suggestion now is to use the upstream module names as we know they will never collide, unlike gentoo's package name where we would otherwise need to have category + package name in the package name [22:09:31] <SwifT> also, if we would use gentoo's package names for the syntax, we would need to duplicate selinux policy packages, creating file collisions, etc. [22:10:10] <SwifT> there are a few sec-policy/* packages that do not adhere to the suggested naming convention; I've offered a possible "fade-out" scenario on gentoo-hardened@g.o for those [22:10:34] <SwifT> as most developers suggested, renaming isn't something we like to do; a fade-out scenario looks to be a better alternative here [22:11:36] <SwifT> well, so far for that document... any questions on the selinux-policy.xml document (goo.gl/2U0Zr) [22:11:42] <SwifT> ? [22:11:47] <blueness> SwifT, i agree with the fade-out. we can rename when the a new version of an policy is introduced too. and then when we remove the old, remove that cat/package [22:12:57] <SwifT> yup... the most important to understand is that, at the end, no sec-policy/* package should be installed by the end user but should be pulled in as a dependency of the gentoo package(s) themselves [22:13:06] <blueness> right [22:13:20] <SwifT> for the time being though, most dependency support within gentoo is lacking but that's a temporary thing until we've stabilized the packages [22:14:29] <SwifT> ok, if no further questions there, perhaps on the SELinux handbook? [22:14:50] <SwifT> the document is current with the portage tree ( ~arch ) and is imo ready for a broader public use/read [22:15:29] <SwifT> there are still a few manual aspects in the document (for instance a manual fix to the lvm support) because that would otherwise require an update to the lvm packages which might be too soon for the time being [22:15:53] <SwifT> but those manual things are easily documented and pretty straightforward [22:16:14] <SwifT> also, if a newer glibc is stabilized, the upgrade process from hardened -> hardened+selinux will take considerably less time :) [22:16:52] -*- SwifT wouldn't mind if the selinux-handbook is committed to the official location, but that's more up to you all [22:17:37] -*- klondike has no feelings as he didn't manage to read it still U_U [22:18:26] <SwifT> of course, even if (not) committed, I'll continue to update it as the selinux state in gentoo hardened updates [22:19:20] <klondike> SwifT: thanks for your hard work, I at least I'm pointing SELinux newbies to your guide and no one complained so far [22:20:18] <klondike> Swift are you done on SELinux docs? [22:20:30] <SwifT> yeah, the guide is not meant to be a complete SELinux guide... it's an introduction to SELinux for Gentoo hardened + installation/usage information, but the security admin of a system definitely wants to read up on the other resources avaialbel on the internet [22:20:40] <SwifT> klondike: yes, that's all I have to say for now :) [22:20:45] <klondike> Well [22:21:08] <klondike> Following with SELinux I have updated the project page as requested by blueness [22:21:32] <klondike> I also added a collaborators section for those non devs helping out in there [22:21:53] -*- klondike thinks something like that on the hardened page too would be pretty cool [22:22:18] <klondike> So if PeBenito gizmo blueness and SwifT agree we can push it [22:23:04] <blueness> last i saw of it, it was fine [22:23:16] <klondike> We also some improvements to the FAQ and TPE as pointed by some open bugs, I'd like to see the new FAQ commited when posible even if we remove the TPE section again [22:23:40] <Zorry> k [22:23:45] <klondike> On the other side I pushed some fixes to the TPE doc too so if blueness gives green light we can publish that too [22:24:21] <blueness> klondike, remind me a bit later and i'll look [22:24:21] <klondike> Zorry: note that updating TPE means pushing FAQ and frontpage with the link aside from the TPE doc itself [22:24:53] <gengor> where is the TPE doc? [22:24:56] <klondike> Before we continue, is anybody against the current version of the FAQ? [22:25:26] <-- pothos_ (~pot...@111-240-171-188.dynamic.hinet.net) has quit (Ping timeout: 240 seconds) [22:25:28] <klondike> gengor: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=blob_plain;f=html/grsec-tpe.html;hb=HEAD [22:26:53] <klondike> nobody is against the FAQ then? [22:27:10] <klondike> Ok if somebody has a complaint please address Zorry or me before we publish :P [22:27:36] <klondike> I also published some notes I took when zorry explained how the patches worked [22:27:49] <klondike> they are on the TXT doc [22:27:53] <gengor> klondike: I would be happy to submit a few changes/clarifications to that TPE doc. [22:28:05] <klondike> gengor: you are more than welcome :P [22:28:06] <gengor> very nice doc tho, whoever did it [22:28:10] <klondike> me [22:28:14] <blueness> klondike, did it [22:28:57] <blueness> gengor, that was partially in reaction to bug #216908 [22:28:57] <gengor> nice [22:29:00] <willikins> blueness: https://bugs.gentoo.org/216908 "TPE Invert GID misbehavior"; Gentoo Linux, Hardened; NEW; deco...@own-hero.net:hardened-kernel@g.o [22:29:32] <klondike> I also have updated the roadmap page, so if nobody has complaints on it we can push that too [22:29:42] <klondike> I hope next update is not in 6 years xD [22:29:50] <Zorry> :) [22:30:10] <klondike> And finally the cooler thing of all [22:30:49] <klondike> I have clearance to give a talk on Gentoo Hardened and the project I'm doing with lejonet at the Campus Party [22:31:00] <gengor> blueness: sure beats resending my explanation email or linking a pastie over and over ;) [22:31:28] <blueness> yep [22:31:46] <klondike> This means I am going to prepare some slides on the hardened project and present them in front af what I expect to be a lot of people [22:32:04] <SwifT> cool... PR is always good :) [22:32:19] <klondike> And also will mean that once the slides are out we'll all get some slides to use to talk of the hardened coolness to non hardened guys [22:33:02] <klondike> Which I think has been a TODO for sometime [22:33:14] <lejonet> klondike: Awesome :) [22:33:18] <klondike> the talk will probably be in Spanish though :P [22:33:38] <klondike> except lejonet's parts if hee comes xD [22:34:02] <lejonet> lol, I ain't got the money, but if you can get me a ticket down I'll gladly come lol [22:34:18] <Zorry> roadmap looks okay [22:34:23] <klondike> lejonet: we'll talk of that later :P [22:34:29] <lejonet> and I can start the whole thing with" Thumbs up to whatever he said, it was all spanish to me" :P [22:34:40] <lejonet> :) [22:34:42] <klondike> Well I think this closes Docs unless someone has things to add xD [22:35:25] <Zorry> wait for gengor fix and then commit index faq tpe roadmap ? [22:35:53] <gengor> i don't want to hold up things, just some updates to that one doc [22:35:55] <gengor> minor stuff [22:36:35] <klondike> Zorry: I agree [22:37:00] <klondike> gengor: just write them down and I'll apply them this weekend if all goes well [22:37:21] <klondike> I'd also like to know which doc am I going to give love now so, any suggestions? [22:37:22] <gengor> klondike: yep, will e-mail you. I think I have your email. [22:38:03] <SwifT> klondike: a doc explaining the paxtest output and, for each potential failure, explains why and how to resolve it [22:38:27] <klondike> ok SwifT this is going to be next one then [22:38:27] <SwifT> klondike: I know we have a nice pax guide, but most users use the paxtest command, see a failure but fail to know frmo the pax documents how to resolve it [22:38:29] <gengor> paxtest is too much a moving target [22:38:40] <gengor> its needs to be unified and fixed up afaik [22:39:03] <gengor> like on x86 one version gives invalid results, the same version is fine on amd64. and then vise-versa for another version of paxtest. [22:39:07] <blueness> gengor, it was okay last i looked at it [22:39:09] <klondike> Maybe we should add the paxtest doc into the pax quickstart then? [22:39:48] <blueness> i worked to make it give correct answers on those two arches. i'm not 100% sure i succeeded [22:40:11] <gengor> doesn't mean it can't be doc'd, but I've literally had one version of paxtest tell me I had all these failures/vulns on amd64, then used a newer version and it said everything was as expected. [22:40:31] <gengor> I just mean I haven't encountered 1 single version that gives proper results on both arches [22:41:00] <gengor> maybe its not that way anymore [22:41:57] <blueness> gengor, please test the latest. i think i cleared the collisions with the tool chain hardeneing [22:42:08] <blueness> which is what was giving false positives [22:43:13] <gengor> these ones we're related to that [22:43:18] <gengor> the ret2libc vs. fortify thing? [22:43:58] <gengor> anyway, lets move on, I probably should not bring up behavior observed 2 years ago. [22:44:10] <gengor> (and for its entire history really ;) [22:44:17] <klondike> xD [22:45:40] <klondike> Well next point then? [22:45:43] <Zorry> so pax-guide doc is next wit added paxtest ? [22:46:07] <klondike> yes unless you have a better suggestion Zorry [22:46:14] <Zorry> nope [22:46:28] <klondike> though not on doc format all the anotations on what you explained me on gcc are shared [22:46:44] <klondike> so if something bad happens to you we are covered :P [22:47:36] <Zorry> klondike: blueness did help me with the gcc code to [22:47:52] <Zorry> next? [22:47:59] <Aleister> question:status on the virt doc? [22:48:06] <klondike> I'm not travelling to use to talk with blueness :P [22:48:09] <klondike> not still [22:48:16] <klondike> ohh yeah that one [22:48:19] <klondike> prometheanfire: ping [22:48:34] <blueness> huh what what what? [22:48:50] <klondike> prometheanfire: bitched on he needing some git crash course before starting [22:48:59] <klondike> so I should talk with him on that [22:49:07] <Zorry> k [22:49:30] <klondike> Aleister: so as of now it is in the limbo :P [22:49:43] <Aleister> klondike: funny was thinking that "limbo". [22:49:50] <blueness> (off topic, i have an assignment which i gave my class on git, i can share) [22:49:55] <blueness> pm me later [22:49:55] <prometheanfire> yes [22:50:02] <prometheanfire> blueness: why later? [22:50:05] <klondike> ok blueness [22:50:06] <Aleister> but ok ill poke him and see if he needs my help :) [22:50:12] -*- prometheanfire is watching nasa launch [22:50:15] <klondike> prometheanfire: statues of virt doc? [22:50:17] <blueness> is the meeting over? [22:50:29] <klondike> I think not [22:50:49] <Zorry> next 6.0 bugs [22:51:04] <Zorry> any bugs to adress? [22:51:28] <klondike> Not on docs I think [22:52:10] <Zorry> klondike: was thinking of hardened bugs [22:52:38] <Zorry> so no bugs ? [22:53:02] <Zorry> okay open for users then
