Meeting log 2013-10-24 20:00UTC

[22:04:58] <Zorry> 1. New Devloper
[22:05:13] <Zero_Chaos> oh hai
[22:05:15] <Zorry> Want to welcome or new dev Zero_Chaos
[22:05:59] <Zorry> Zero_Chaos:  can tell about your self
[22:06:23] <Zero_Chaos> Hi, I'm a married white male who likes long walks on the beach and whips
[22:06:25] <Zero_Chaos> I mean
[22:06:42] <Zero_Chaos> I love hardened and I'm here to help and learn more about it.
[22:07:21] <specing>  /hardened/
[22:07:27] <Zero_Chaos> yeah that's about it. I hate ranting about myself
[22:07:38] <Zorry> next then?
[22:07:40] <SwifT> welcome on board
[22:07:47] <shadowdaemon> choo choo
[22:08:19] <Zorry> 2.0 Toolchain
[22:08:35] <Zorry> gcc 4.8.X have been unmasked
[22:09:23] <Zorry> the asan thing is not solwed and upstream seems a deedend
[22:10:34] <Zorry> so to use asan you need to disable UDEREF in the kernel
[22:10:55] <blueness> Zorry, can we just disable asan for USE=pax_kernel?
[22:11:12] <blueness> i cringe at the suggestion but it seems to be the only way forward
[22:11:19] <prometheanfire> klondike: do you have comments on llvm progress?
[22:11:25] <Zorry> blueness: you only enable it if you compile with -fsantizes
[22:11:36] <blueness> Zorry, that's the point i guess
[22:12:05] <blueness> don't allow it to be enabled for pax_kernel
[22:12:22] <blueness> will toolchain be adding a use flag for it?
[22:13:17] <Zorry> blueness:  the prob is that gcc need to have a check for the kernel for you may change the kernel and still use the same gcc
[22:13:38] <blueness> i know that's why i *cringe*
[22:13:50] <blueness> because its always the same problem, if you change the kernel
[22:13:59] <blueness> so should we force asan off all the time?
[22:14:16] <blueness> on all profiles?
[22:14:37] <Zorry> i won't disable it
[22:14:43] <Hello71> that sounds like a bad idea
[22:15:01] <Zero_Chaos> could just add a warning to pkg_postinst for USE=hardened or USE=pax_kernel
[22:15:08] <Zorry> if you need to use it for debugning stuff disable UDEREF
[22:15:34] <prometheanfire> what is the general impact of this not being solved?
[22:15:35] <SwifT> can't we have the hardened eclass die when it detects asan settings in the CFLAGS and uderef set?
[22:15:37] <blueness> Zorry, okay then a working
[22:15:40] <blueness> warning
[22:15:47] <Zero_Chaos> Zorry: can easily do a kernel check for UDEREF and warn on it
[22:16:13] <blueness> SwifT, no we can't really go that way because people boot into different kernels
[22:16:27] <blueness> Zero_Chaos, same thing, at what point do you test for UDEREF?
[22:16:33] <prometheanfire> that, and I could build and ship stuff around
[22:16:47] <blueness> if its at gcc build time then we turn off asan but users might reboot into a vanilla kernel just to use it
[22:16:51] <Zero_Chaos> blueness: same as anything else kernel dependant, when you build. it's the best we can do
[22:16:53] <blueness> or into a hardened kernel with no UDEREF
[22:17:08] <Zero_Chaos> blueness: I said warn when UDEREF is detected.
[22:17:39] <Zero_Chaos> blueness: I don't see a "better" solution. I mean, we can warn all the time but that will bother the majority of users (since I think hardened still isn't the lionshare)
[22:18:45] <blueness> Zorry, can we let asan fail if UDEREF and trap the failure in gcc and issue a warning?
[22:19:54] <Zorry> blueness: we can make a check but are we 100% sure we can get the uderef info all time?
[22:20:44] <Zorry> llvm need that check to
[22:21:07] <blueness> Zorry, no but if the virt mem size is too small, it *will* fail so we can catch that failure and run our warning routine
[22:21:13] <SwifT> how critical is this issue? If a user builds with ASAN on a non-UDEREF kernel and then boots a UDEREF kernel, I guess his system will not work (but he can always reboot back into his old kernel)
[22:21:42] <prometheanfire> SwifT: that's what I was wondering as well
[22:21:58] <Zorry> SwifT prometheanfire it will fail hard
[22:22:02] <blueness> SwifT, it will
[22:22:19] <blueness> you if you rebuild world with asan you won't get past init
[22:22:23] <blueness> or even your initramfs
[22:22:24] <prometheanfire> ah
[22:22:40] <Zorry> and the system will crall
[22:22:43] <SwifT> blueness: unless you boot back with non-UDEREF kernel
[22:22:45] <blueness> all you elfs will set up an virt address space which will hit against pax's high mem limit hard
[22:23:13] <blueness> Zorry, will it even boot?  i haven't tried
[22:23:19] <Zorry> i would only use to debug nothing else
[22:23:52] <blueness> pipacs, ping ^^^
[22:23:53] <Zorry> blueness: if you compile openrc/systemd/.... it will most likly get killed
[22:23:59] <blueness> right
[22:24:23] <blueness> Zorry, i think at the very least we need to document asan + hardened in the wiki so people know what's going on there
[22:24:35] <blueness> and reference bug #458706
[22:24:35] <Zorry> i se no point to do a emege world on asan
[22:24:36] <willikins> blueness: https://bugs.gentoo.org/458706 "PaX: Max. per-task virtual memory too small for llvm asan and gcc-4.8 asan"; Gentoo Linux, Hardened; IN_P; klaus.kusche:hardened
[22:24:58] <Zorry> the speed will be in half
[22:25:00] <blueness> Zorry, i don't either but someone might!
[22:25:12] <pipacs> blueness, uhm, what can i do?
[22:25:24] <prometheanfire> hider
[22:25:25] <pipacs> asan is fundamentally hardwired to use a particular address space layout
[22:25:42] <pipacs> so unless someone fixes up all the constants related to that , it won't ever work under uderef
[22:26:35] <blueness> pipacs, but no possibility of soft failures ehre either on the asan side or kernel to just warn users what's going on?
[22:28:28] <pipacs> i dount, asan generated code will access memory that can't be mapped under uderef -> segfaults galore
[22:28:38] <pipacs> doubt even
[22:29:01] <pipacs> i guess you have the same problem under segmexec/i386 as well btw
[22:29:08] <pipacs> even if nobody uses that these days ;)
[22:29:39] <blueness> right
[22:30:22] <blueness> Zorry, okay let's just document the problem and move on for now ...
[22:30:31] <Zorry> okay
[22:31:07] <blueness> are you done, or do you want the uclibc report?
[22:31:11] <Zorry> we still have to fix libav and ffmpeg for the -fstack-check stuff
[22:31:35] <Zorry> klondike: ^^
[22:32:06] <Zorry> gcc 4.9 will hit the end of stage1 nov 21
[22:32:09] <blueness> klondike's solution works, but upstream may have problems with it if slows down the codec
[22:32:31] <blueness> so i'm not sure that patch will ever go upstream, i wonder if we can get just our folks to apply it
[22:32:31] <Zorry> working to get upstream patches to it
[22:32:35] <blueness> k
[22:33:16] <Zorry> most time of it is to test all the testsuite stuff
[22:33:58] <Zorry> will start with full pie enable and move to ssp and fortify later on
[22:34:27] <Zorry> any one else
[22:34:33] <Zorry> blueness:  uclibc?
[22:34:33] <blueness> yes ... uclibc report
[22:35:02] <blueness> okay so now the amd64, x86 and arm uclibc stages are being built with gcc-4.7.3-r1
[22:35:19] <blueness> which is the latest stable on those arches ... no problems
[22:35:51] <blueness> and the mips32r2 mipsel3 stages are being built with gcc-4.8.1-r1 which was recenlty unmasked
[22:36:31] <blueness> so pretty much those stages are all in tree stuff and no hackiness anymore, especially the mips stages which needed the driver spec stuff
[22:37:03] <blueness> i'm not building as often but there are fewer bugs between each built, so no need to build more often than once every 2 months
[22:37:18] <blueness> okay that's all ...
[22:37:58] <Zorry> any one?
[22:38:03] <Zorry> next else?
[22:38:30] <Zorry> 3.0 Kernel Grsec/PaX
[22:38:53] <Zorry> blueness: 
[22:39:09] <blueness> nothing new really, just keeping up with upstream :)
[22:39:25] <blueness> i didn't get around to fixing the install.py problem
[22:39:31] <blueness> i just haven't had the time
[22:39:41] <Zero_Chaos> blueness: that problem is KILLING people btw
[22:39:48] <blueness> understood
[22:39:53] <Zero_Chaos> I need pain killers just thinking about it
[22:39:57] <blueness> i know
[22:40:14] <blueness> this is seriously the busiest time
[22:40:31] <pfire> We know what the next lts is going to be?
[22:40:35] <blueness> the first stab will be to write the wrapper in C and see if its faster
[22:40:50] <blueness> there are two levels of wrappers actually
[22:41:11] <blueness> a bash script which redirects the path and the other which does the install.py wrapping
[22:41:21] <blueness> both are adding heavily to the time
[22:41:36] <blueness> so even a C wrapper in the place of install.py may not be enough
[22:42:03] <blueness> i'm not sure why zmedico added the bash wrapper but i'm sure he has a reason for worrying about what portage paths are in the env at that point
[22:42:21] <blueness> so there's work to be done
[22:42:46] <blueness> eta: i finish my teaching in dec. so i can definitely get it done then
[22:43:09] <blueness> Zero_Chaos, how much is this increasing for the releng builds?
[22:43:22] <Zorry> blueness: alot
[22:43:38] <blueness> double the time?  triple?  10x
[22:43:39] <blueness> ??
[22:43:55] <blueness> i didn't do a bench really, just noticed it with python
[22:44:07] <Zero_Chaos> blueness: on the hardened stuff looks to be pretty hardware dependant. for me it seems between 2x and 3x
[22:44:14] <Zero_Chaos> blueness: it is CRUSHING my IO
[22:44:39] <pfire> 2x and 3x on what?
[22:44:42] <Zero_Chaos> blueness: on some things it's >10x though
[22:44:45] <blueness> okay why don't i hack something up tonight ... just a poc and see if a wrapper written in C is faster than python
[22:44:46] <Zero_Chaos> pfire: more files, more time.
[22:44:58] <prometheanfire> ah
[22:45:00] <blueness> Zero_Chaos, pick a package i should bench and i'll do it
[22:45:27] <Zero_Chaos> blueness: something with lots of files is all that matters. kernel, python, more files = more better
[22:45:33] <blueness> basically i'll just write a C wrapper that sloppily calls install and setfattr just to see
[22:45:36] -*- yerodin remembers the 'old man
[22:45:44] <yerodin> needs to rest.
[22:45:50] <blueness> yerodin, yes yes ...
[22:46:29] <blueness> lets move on if there are no more questions here, we know this problem
[22:46:33] <Zero_Chaos> blueness: I'd be happy to discuss fixes with you (again) after this meeting so we don't drag on. It's important, it needs work, everyone knows.
[22:46:42] <Zorry> next
[22:47:03] <Zorry> 3.0 use of pax_kernel
[22:47:09] <Zorry> 3.1 use of pax_kernel
[22:47:16] <Zero_Chaos> if I may
[22:47:36] <Zorry> go
[22:47:42] <Zero_Chaos> it seems that pax_kernel describes multiple things, such as "can't build under pax kernel" and "can't run under pax kernel"
[22:47:57] <Zero_Chaos> I use a hardened system to build default images, this causes major headache
[22:48:15] <Zero_Chaos> I have to set pax_kernel on some packages and not others to be able to build
[22:49:22] <Zero_Chaos> I wanted to abuse the kconfig option CONFIG_PAX_CONSTIFY_PLUGIN to detect some things, but I don't actually see it in >3.8 kernels
[22:49:51] <Zero_Chaos> and before I go randomly changing things, I wanted to see the team's opinion on building a default build in a chroot on a hardened host
[22:50:14] <prometheanfire> yes
[22:50:52] <Zero_Chaos> examples include ati-driver, nvidia-drivers, and mono (just so it's known)
[22:50:53] -*- prometheanfire thinks that pax_kernel should be only for modifying the build for use on a pax system (patches, paxmark)
[22:51:21] <Zero_Chaos> prometheanfire: paxmark should ALWAYS be performed imho. what if a user switches from vanilla to hardened?
[22:51:29] <Zero_Chaos> that's part of my idea of fixing this
[22:51:39] <blueness> pax_kernel means "these elf exes may be run under a kernel with pax memory protections enabled"
[22:51:47] <blueness> it should not be used for building
[22:51:58] <Zero_Chaos> blueness: it is though
[22:52:00] <prometheanfire> not for patch applying?
[22:52:21] <blueness> okay this is complex, so hold on
[22:52:27] <Zero_Chaos> this is complex
[22:52:38] <blueness> 1) if you are talking userland .... you must not build against a kernel source tree
[22:52:38] <prometheanfire> if we get this down to a single use, we should make it global (I tried to make it global before, but because of it's multiuse...)
[22:52:56] <blueness> that's wrong because there are struct in there that should not be available to userland
[22:53:04] <blueness> and can change even during minor bumps
[22:53:10] <blueness> so use /usr/include/linux
[22:53:23] <blueness> 2) if its a kernel module, then of course you can build against a kernel source tree
[22:53:25] <Zero_Chaos> right so the kernel module examples are obvious
[22:53:30] <blueness> ... okay get that out of the way ... next
[22:53:34] <Zero_Chaos> detect if we are using constify, patch if we are
[22:53:38] <Zero_Chaos> imho
[22:53:59] <blueness> USE=pax_kernel in the case of userland should apply patches etc, that fix the code so that it won't trip pax protection eg mprotect
[22:54:06] <blueness> eg remove rwx mmappings etc
[22:54:20] <blueness> in the case of kernel modules, it can't mean that obviously!
[22:54:30] <blueness> so i don't know what USE=pax_kernel might mean for nvidia-drivers
[22:54:32] <prometheanfire> I think we should come at it from a 'we have all these diferent scenarios, what flags should we use to trigger an altered behavior' way
[22:54:48] <Zero_Chaos> blueness: the issue there is, take mono. it can't build without being pax-marked, but in a default chroot on a hardened system it won't be USE=pax_kernel
[22:55:00] <blueness> that's fine, then use USE=pax_kernel
[22:55:08] <Zero_Chaos> blueness: then all the kernel modules break
[22:55:09] <blueness> it should matter
[22:55:18] <Zero_Chaos> see the issue?
[22:55:26] <blueness> Zero_Chaos, yes then those flags need to change
[22:55:26] <prometheanfire> afaik, pax kernel is used with nvidia to pax mark stuff so it can still be used for compute
[22:55:51] <Zero_Chaos> prometheanfire: negative, it's used for a conditional patch needed to build at all
[22:55:58] <Zero_Chaos> prometheanfire: said patch breaks build on non-hardened
[22:56:10] <Zero_Chaos> prometheanfire: same with ati-drivers, and compat-drivers, and everything else afaik
[22:56:18] <prometheanfire> ah
[22:56:29] <blueness> prometheanfire, you can always safely unconditionally pax mark, either PT_PAX or XT_PAX (but not EI_PAX!!!)
[22:56:36] <prometheanfire> then it falls under the userland use case, but the package is a kernel package
[22:57:01] <prometheanfire> but I still think the pax_kernel flag use is valid for nvidia
[22:57:09] <blueness> Zero_Chaos, collect all the offending kernel modules and let's come up with a different flag ... i can't believe i just said that!
[22:57:14] <Zero_Chaos> honestly, if I could as a matter of policy unconditionally pax-mark things on all profiles this problem would likely disappear
[22:57:21] <Zero_Chaos> blueness: *
[22:57:34] <Zero_Chaos> blueness: easier the other way, fix the userland stuff to just always pax-mark
[22:57:38] <Zero_Chaos> imho
[22:57:40] <blueness> Zero_Chaos, pax marking is always safe the way we do it
[22:57:49] <Zero_Chaos> blueness: maybe so, but it isn't always done
[22:58:08] <Zero_Chaos> blueness: dev-lang/mono paxmarks conditional on use=pax_kernel
[22:58:08] <blueness> then you can go that route
[22:58:23] <prometheanfire> I have skype conditionally do it as well
[22:58:30] <blueness> Zero_Chaos, all elf binaries on gentoo are build with a PAX_FLAGS program header
[22:58:39] <Zero_Chaos> blueness: even on default profile?
[22:58:43] <blueness> prometheanfire, oh wait ...
[22:58:50] <Zero_Chaos> blueness: and what of binaries like skype? :-(
[22:58:51] <blueness> yeah well i take the *safe* back
[22:58:55] <Zero_Chaos> lol
[22:59:01] <blueness> paxctl -C or -c could be dangerous
[22:59:01] <yerodin> haha
[22:59:08] <blueness> but we want to move away from those
[22:59:19] <prometheanfire> ya, xtpax, yes please
[22:59:39] <blueness> converting a GNU_STACK program header should be safe (not sure) but adding a program header can fail eg skype
[22:59:44] <Zero_Chaos> how about this. new policy to unconditionally pax mark every time it is SAFE to do so? (ie not binaries unless specifically known safe to do so)
[22:59:56] <blueness> Zero_Chaos, works
[23:00:11] <Zero_Chaos> anyone against?
[23:00:17] <blueness> i don't know about the word "policy" just identify where the problem is, open bugs and cc hardened and i'll give my 2 cents
[23:00:20] <SwifT> I wouldn't dare :p
[23:00:30] <SwifT> (being against it, that is)
[23:00:39] <prometheanfire> I think I pax mark spotify too
[23:00:56] <shadowdaemon> PaX mark all the things.
[23:00:57] <prometheanfire> but ya, I'm fine with unconditional paxmark if safe
[23:01:07] <Zero_Chaos> okay, I'm going to take charge, grep the tree, identify badness, and open proper bugs to get this resolved then.
[23:01:09] <blueness> prometheanfire, grep the tree for pax-mark -C or pax-mark -c and those are your problems
[23:01:23] <Zero_Chaos> thanks, I'm comfortable moving forward and working with the maintainers of the packages
[23:01:44] <blueness> Zero_Chaos, okay so then mabye we can keep the following meaning for pax_kernel
[23:02:04] <blueness> 1) userland ... do what needs to be done so that it runs under pax mem protections
[23:02:14] <blueness> 2) kernel ... apply patches to fix constify etc
[23:02:27] <blueness> with the understanding that you unconditionally pax mark when safe
[23:02:37] <blueness> works?
[23:02:39] <Zero_Chaos> blueness: it would be best if there was a kernel config option we could detect constify based on...
[23:02:47] <Zero_Chaos> blueness: there was in 3.8 but I don't see it in 3.9
[23:02:49] <blueness> you can use the kernel eclass for that
[23:02:54] <prometheanfire> so, what packages do we need to remove the use flag from with those definitions?
[23:03:09] <Zero_Chaos> prometheanfire: anything that isn't a kernel module most likely
[23:03:27] <blueness> prometheanfire, i wouldn't ever do  ... use pax_kernel && pax-mark -m ${S}/src/my_elf
[23:03:33] <blueness> i would just do pax-mark -m ${S}/src/my_elf
[23:03:46] <prometheanfire> ok
[23:03:52] <pipacs> Zero_Chaos, when constify is active CONSTIFY_PLUGIN will be a defined symbol
[23:03:57] <prometheanfire> my question is
[23:04:01] <pipacs> so you can #ifdef on that in the patches
[23:04:03] <blueness> remember users (including me) reboot vanilla/hardened all the time
[23:04:20] <blueness> pipacs, good point actually
[23:04:28] <prometheanfire> what is pax_kernel used for that is not the afore mentioned userland and kernel definitions
[23:04:50] <blueness> prometheanfire, nothing, let's limit it to that
[23:05:01] <Zero_Chaos> blueness: honestly I'd like to remove the use flag entirely and detect constify properly
[23:05:13] <blueness> but pipacs makes the best point, just add ifdefs to the patches for constification
[23:05:23] <blueness> Zero_Chaos, as pipacs said
[23:05:28] <prometheanfire> I mean the packages
[23:05:44] <prometheanfire> what existing packages fall outside of that
[23:05:51] <Zero_Chaos> honestly if that is all that has to be done I can fix all the patches myself.
[23:06:11] <Zero_Chaos> how about I attempt this all and we revist progress next month to assess insanity?
[23:06:16] <blueness> Zero_Chaos, yes
[23:06:29] <Zorry> +1
[23:06:51] <Zero_Chaos> great, thanks for humoring me all.  this has been bothering me a while :-)
[23:06:57] <Zero_Chaos> next
[23:07:14] <Zorry> 4.0 Selinux
[23:07:44] <Zorry> SwifT: ^^
[23:07:48] <SwifT> nothing really; small policy change here and there, mostly waiting for upstream (who seems to be brewing on larger updates on userspace)
[23:08:15] <SwifT> also no major chnges pending for us
[23:08:20] <SwifT> that's it
[23:08:40] <Zorry> next
[23:08:41] <blueness> (brb in 5 mins, my dog is going crazy here!)
[23:08:52] <Zorry> 5.0 System Integrity
[23:09:19] <SwifT> nada to say there
[23:09:29] <prometheanfire> book?
[23:09:42] <SwifT> hoped to have the benchmarks ready by now, but personal time isn't allowing me :(
[23:10:00] <SwifT> no book on system integrity (planned yet) ;)
[23:10:03] <prometheanfire> :D
[23:10:35] <Zorry> next then?
[23:10:38] <cilly> didn't you miss point 3?
[23:11:05] <Zorry> cilly: do some backreading
[23:11:08] <SwifT> next is good
[23:11:19] <yerodin> yep
[23:11:27] <Zorry> 6.0 Profile
[23:12:00] <Zorry> don't have any news ther from me
[23:12:17] <Zorry> next?
[23:12:21] <blueness> back
[23:12:45] <Zorry> blueness: any thing that on profile that don't on next point
[23:13:05] <blueness> well i thought Zero_Chaos had an issue
[23:13:10] <Zero_Chaos> blueness: mine is 6.1
[23:13:19] <blueness> k go ahead
[23:13:29] <Zero_Chaos> 6.1 reintroduce desktop profile
[23:13:47] <Zero_Chaos> I've heard a lot of devs stating that supporting users has been a pain in the butt since we removed the desktop profile
[23:14:30] <Zero_Chaos> I'd like to recreate a desktop profile as simply a profile that points to targets/desktop and then ..in each of the hardened profiles.  This means the desktop settings would be pulled in BUT hardened profile overrides
[23:14:58] <Zero_Chaos> it's essentially zero danger aside from any minor use flag issues which may pop up in the switch, and I'll take a look at those before introducing it
[23:15:14] <Zorry> i think the hardened/desktop wasen't shown in the eselect profiles
[23:15:19] <Zero_Chaos> it was
[23:15:26] <Zero_Chaos> and people used it
[23:15:30] <blueness> Zero_Chaos, open a bug report where we can discuss this because re-introducing the old way of doing it was problematic
[23:15:42] <blueness> people using it doesn't remove the QA problem
[23:15:59] <Zorry> Zero_Chaos: the main prob is the stacking order of the profiles
[23:16:00] <Zero_Chaos> blueness: I have no intention of doing it the old way, but I don't mind a bug to discuss the details if you feel it is needed
[23:16:02] <blueness> we have to find another way here
[23:16:13] <Zero_Chaos> Zorry: yes, it's trivial to make hardened override targets/desktop
[23:16:56] <blueness> Zero_Chaos, okay so let's discuss it in a bug report where we can test this out
[23:17:04] <Zero_Chaos> but blueness requested a bug, and unless someone cares to override that I can respect it. it's trivial to make this change but what happens after may be very non-trivial. so I'll open a bug for this and we can look at it
[23:17:05] <Zorry> Zero_Chaos: the only way i think is to add hardened to /amd64/desktop/hardened
[23:17:26] <blueness> Zorry, i was just about to say that, its very ugly too :(
[23:17:27] <Zero_Chaos> Zorry: I'm thinking the other way actually, but I'll get you a bug and we can discuss there
[23:18:00] <blueness> Zero_Chaos, we have had a lot of problems with the profiles, 3 years worth
[23:18:24] <blueness> we finally got something which not only works for the current profiles, but is shallow enough to allow other low level stuff to be added
[23:18:27] <blueness> eg uclibc musl
[23:18:29] <Zero_Chaos> blueness: we can move discussion to a bug, but I currently maintain 16 profiles and I think I can do better.
[23:18:30] <blueness> eg selinux
[23:18:39] <Zorry> Zero_Chaos: the prob is we can't have desktop before base or after hardened in the profile stack
[23:19:16] <Zero_Chaos> Zorry: let's move this to a bug, that was the expected result of my introduction of this topic.  I'll open it today
[23:19:16] <blueness> so what we've done over the past 3 years is tracked changes to the profiles on bug reports with testing from the  overlay using mount --bind
[23:19:44] <blueness> what i would do, is see what you propose (from the bug report) add it to the hardened-dev::profile git repo
[23:19:53] <Zorry> +1
[23:20:00] <blueness> then do a mount --bind  to put that proposal over the current profiles
[23:20:02] <blueness> then test
[23:20:05] <blueness> its slow
[23:20:08] <blueness> but it avoids mistakes
[23:20:13] <Zorry> yep
[23:20:40] <blueness> Zero_Chaos, don't get me wrong, i don't like saying "no" but the profiles design is incredibly bad
[23:20:50] <Zorry> so open a bug about the desktop profile
[23:20:54] <Zero_Chaos> blueness: I've been building with a hardened desktop profile for the last 2 years, 2x a day. I'm happy to open a bug, but let me just say that I already know what I want to do works and is safe ;-)
[23:20:54] <blueness> and what may have to happen in the long run is a new way of doing profile smay have to emerge
[23:20:57] <Zorry> next then
[23:21:06] <prometheanfire> next
[23:21:06] <Zero_Chaos> next
[23:21:26] <Zorry> 7.0 Docs
[23:21:43] <SwifT> nothing from me
[23:22:04] <Zorry> nothing from me
[23:22:11] <Zorry> so next?
[23:22:28] <Zorry> 8.0 Bugs
[23:22:54] <blueness> we tend to cover bugs with the reports themselves ... so nothing new
[23:23:27] <Zorry> 9.0 Media
[23:24:06] <blueness> klondike, ???
[23:24:26] <blueness> SwifT, i love the blog reports of the meeting ...
[23:24:39] <blueness> nice summaries
[23:24:41] <Zorry> next
[23:24:45] <blueness> sure
[23:24:51] <Zorry> 10.0 Open floor
[23:24:55] <Zorry> anu thing?
[23:24:59] <Zorry> any*
[23:25:11] <Zorry> else the meeting is done