NOTA BENE - WORK IN PROGRESS - Your Inputs & Thoughts
To Brain Study - To Brain Study - Overview Projects - To Technology Laboratory Fix Bug 665 - Software Improvement / Patch - To comma Workbench Fix Bug 665 - Community & Public Communication
Fix Bug 665 - Intermediate level-3 certificate is MD5-signed - Project Management
Overview Project Wiki Pages
Project Management - This Page
Status & Expected Impacts
Actual Technical Situation - Background
See Bug Report 665
CAcert.org Wiki Md5 Based Hash and Security Notes - December 2008: MD5 checksum algorithm usage in issued certificates
CAcert.org Board E-Mail List 20091114 "2.4 new roots / draft backgrounder for sunday meeting"
No Appropriate Action - Expected Market Impact
- Bad reputation in public
- Loss of credibility within cryptographic community
- Loss of credibility in the area of educational organizations, e.g. universities, technical colleges
CAcert.org Community - Manpower to be Found
Who else, beside of Philipp Gühring for patch writing would have to be involved? How has know-how and time?
If no New Roots are needed to fix bug 665, what resources are requested?
IF New Roots are really NEED to fix bug 665, but ONLY IF, what would resources are requested?:
Policy Steering Committee / Group cacert-policy@lists.cacert.org for review, improvement and motion / vote of Security Policy
Put in place a "New Roots Task-Force 2009", similar to Former "New Roots Taskforce"
CAcert.org Policies & Manual with Impact on New Roots Creation Process
CAcert.org SP - Security Policy - COD 08
CAcert.org SecurityManual
Financial Budget
Direct costs will be approx. 4'000 Euros for: storage of the USB keys & papers in separate bank vaults, (public?) notary costs, expenses as travel and accommodation. - Start fund rising by blog article, mass e-mail?
Decisions to Take
- Do we want to issue a new Class3 root beyond our current Class1 root, or whether we want to issue a whole new Root certificate-structure as well?
- For various security /cryptography reasons,it is recommended to issues a whole new Root certificate Structure.
Decision to be confirmed or not by Community, if so, is Policy Group: cacert-policy@lists.cacert.org recommended
Who will be part or has knowledge & time to join and participate actively in this "New Roots Task-Force 2009"?
As some CAcert Inc.board members with security / technical and cryptographic know-how explicitly stated, they don't have time at all for active support. Knowledge / Support is offered by Guillaume_ROMAGNY and PhilippDunkel. For administrative / organizational and communication tasks, hugi will help or lead, if no technical expert is available. More detailed, see Minutes - Committee Meeting 2009-11-15, Point 2.4 or Meeting transcript, Point 2.4 on this Wiki page -> Inputs & Thoughts -> 20091116.
Existing Material / Documentation from former Roots Replacement
Blog Article "Happy New Attack!" - 2009-1 - by Sourcerer ( Philipp Gühring )
Can found by CAcert.org Wiki Title Search: Keyword Roots - just click!
- Or some direct Links are:
Inputs & Thoughts
YYYYMMDD-YourName
Text / Your Statements, thoughts and e-mail snippets, Please
20091130-RobertoMazzoni
I completely agree with Dieter's decision. It is an evident way allowing a smooth and quick transition
20091130-DieterHennig
My decision is as follows: a.) Let´s put a new intermediate certificate with a lifetime of 5 to 7 years into production. Comment: Anyone wishing to produce more intermediate certificates is welcome to do so, but it will confuse the end user in some way. b.) Remove the old certificate (Class-3) from the cacert.org-server, but do not revoke it. Comment: Applications will continue to run for duration of life cycle. The actual Class-3 certificate can then be revoked in 2 years. c.) Please remove the root-certificate from the cacert.org server and store it (its private key) in a safe place. Comment: Today´s practice is quite dangerous. If reasons for creating a new root certificate exist, we must separate this issue from the above. In my opinion the question how to overcome the MD5--MD5--SHA1 situation should be solved separately.
20091124-Guillaume_ROMAGNY /e-mail
> As a matter of record, it cost around euros 1000 to 4000 for the 2008 roots. I support your figures because as you need to bring a couple of board members to the meeting + 2 - 3 critical systems engineers, the travel costs start to become expensive. You need old hardware you can destroy (or dismantle piece by piece) including an old "noisy" sound card for the random (this is cheap!) but you need manpower to re-build the "final" system from scratch before the real ceremony is done (to limit trojans risks, etc...) including a couple of test ceremonies. Then after the ceremony you need to pay fees to store the USB keys & papers in separate bank vaults / notaries ($$$) => as you mentioned, we need to secure/define the proper process to store the keys safely And probably the 2008 process needs to be updated/improved/replaced if needed, which adds extra software dev costs. For example, does the linux distro we have used still usable today ?
20091114-Iang /e-mail
Part from E-Mail. Complete E-Mail: https://lists.cacert.org/wws/arc/cacert-board/2009-11/msg00077.html * The doco we have is still good, saved from 2008. * We need a new root protection strategy. * We need a meeting of several key people to re-roll. * we need a complete rollout programme (not even started but see the bug 665 above) * we need a relationship to audit, strategy wise.
20091115-PhilippGuehring /e-mail
> Referring to bug 665 > http://bugs.cacert.org/view.php?id=665 > and to your technical and cryptographic expertise, I kindly as you, what does it need to fix? > What are the needs in terms of: > * Knowledge & Skills, are they available? > * Manpower, who has time to help? > * Organization, who can do what and when? > * Consequences, what could go wrong? > * Costs, are there financial consequences? The first thing is that we need a small improvement to our software to support expiring CA certificates, to avoid breaking the CRLs. (I implemented half of this already, only the second half is missing). I am able to do that within a week I guess. The next thing we need is a decision, whether we want to issue a new Class3 root beyond our current Class1 root, or whether we want to issue a whole new Root certificate-structure as well. Then we have to generate and deploy the new CA certificate. Then we have to enable the usage of the new CA certificate in our software. In the mean time, we should inform our users about the new certificate, which they have to do correctly for Certificate-Chains. > Would it be possible to establish some concrete step-by-step plan, in order to fix the bug as fast as possible? I will care about the software changes this week. Can you organize the decision for Class3 vs. WholeNewRoot? Best regards, Philipp Gühring
20091115-DanielBlacke
Please involve Wytze. He's the one needed to maintain it and follow some procedures to make the change. Software side Philipp can handle. Majority of the work is a good PR transition strategy. preliminary notification Linux distros and other people that bundle our roots would be good - wiki page somewhere. A delay (2 weeks to 3 months or longer?) between notification and issuing on the new root or roots to allow propagation . > > * Consequences, what could go wrong? audit hits snag and we need to do it again or revoke certificates not properly assured on the new root. > > * Costs, are there financial consequences? should be none.
20091116-hugi
Transcript Committee Meeting 2009-11-15 / Agenda Point 2.4 Original Place: http://wiki.cacert.org/Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/20091115 (23:36:08) markl: ok, great... 2.4. Critical Bugs & Improvements - added by hugi (23:36:34) andreasbuerki: yep... I very dongerous situation for our reputation (23:36:42) markl: unless I'm misunderstanding those, Andreas, they seem like wider community discussions, perhaps in the policy group? (23:37:00) markl: I'm not sure what we can do at this level about those bugs (23:37:04) andreasbuerki: it came in by the support channel (23:37:31) andreasbuerki: that borad is aware about a quite dangerous security situation (23:37:50) andreasbuerki: and supports the efforts to fix this bug (23:38:07) andreasbuerki: as just postponing is not an option (23:38:13) markl: from the wiki page... "There are even TWO DIFFERENT X.509 CERTIFICATES WITH THE SAME MD5 HASH, but as explained in the document referenced, this cannot be exploited in a meaningful attack." (23:38:19) iang: for the transcript, my observations are here: https://lists.cacert.org/wws/arc/cacert-board/2009-11/msg00077.html (23:38:27) andreasbuerki: Some figures: University Zurich: UZH 25'000 Sudents and 5'000 Stuff - (23:38:27) andreasbuerki: Swiss Federal Institute of Technology Zurich: ETHZ 15'000 Students and (23:38:27) andreasbuerki: 9'000 Staff. - Total of 54'000 People and most of them have e-mail and (23:38:27) andreasbuerki: .... do I need more to say? (23:38:28) markl: this is still a theoretical attack, from what I understand? (23:39:01) andreasbuerki: Theory or not, we are seen as not taking care about security (23:39:10) iang: markl: yes, i think it is. i would have to go back and look at the details, but it relies on being able to predict the entirety of the certificate BEFORE it is issued. (23:39:36) andreasbuerki: the risk ist, that we are seen as not reliable (23:39:56) iang: the demo that was done could only be done on that one CA, and took around 6 weeks of trying .... the thing is, if the CA inserts a "nonce" into the cert, it is unpredictable and the attack requires a complete collapse of the hash (23:40:29) iang: andreasbuerki: the real annoyance IMO is when the browsers start blocking the use of MD5 (23:40:29) andreasbuerki: the key statement of both universites is: At the moment, we are hesitating moving our certificates to CACert.org. (23:40:43) markl: I'm not sure that's the case... what has been published is something we are not vulnerable to, as far as I can tell (23:40:56) PhilippDunkel: People you are missing the point! (23:41:01) andreasbuerki: we are vulnerable... (23:41:08) markl: but still, I don't think this is board work (23:41:09) andreasbuerki: tell us PD (23:41:10) GolfRomeo: ok, so we would need to put a random serial number or any other field with random data (23:41:14) PhilippDunkel: It does nopt matter 1 iota whether there is any real danger! (23:41:30) PhilippDunkel: The question is whether there is a perceived danger and a perceived reaction (23:41:38) markl: it matters that we recognize the issue, consider it, and address it, I understand that (23:41:41) andreasbuerki: if borad doesn't support... who will then? (23:41:45) markl: but again, this isn't the right forum of first choice (23:41:54) iang: well, more or less ... there is real risk and then there is perceived risk (23:42:05) markl: the right forum is the policy group, and that fails, then come to the board with it to "escalate" it (23:42:19) GolfRomeo: if we have a quick fix, we have to push the fix (23:42:21) iang: the problem is that the press can be wrong ... the perceived risk can be wrong (23:42:24) PhilippDunkel: If 2 major universities are "hesitant to use CAcert" for this reason and they are also potential sponsors, we should at least adress teh issue rahter than having a couple of "crypto amateurs" (us) decide whether it is important (23:42:39) markl: PD: I thought they are hesitant bcoz we won't put subjectAltNames in for them? (23:42:40) iang: markl: no, I think it is fairly clear that we SHOULD re-issue the roots. (23:42:43) andreasbuerki: you fully understood the point PD (23:42:53) iang: in that also, audit failed the roots, and new ones were already issued (23:43:05) iang: the current ones are essentially unacceptable for all sorts of reasons (23:43:23) andreasbuerki: means we are with shot trousers (23:43:26) markl: iang: right, but as part of a wider decision, which MD5 collision risk is but a tiny part (23:43:27) GolfRomeo: @iang : yes (23:43:30) markl: iang: right? (23:43:32) iang: however, opposing that, we have a resource problem: I don't believe we can issue roots at this point in time (23:43:51) andreasbuerki: what makes you beliving that? (23:44:02) andreasbuerki: both universities offered their help, Ian (23:44:09) iang: markl: yes, I as auditor made the decision based on the lack of history from the Sydney period, and the weak conditions in Vienna. (23:44:27) andreasbuerki: we have to involve them insted find 10000 excuses for not doing!!! (23:44:38) iang: GolfRomeo: perhaps you can tell AndreasBuerki how much work it was to issue the roots? (23:44:40) markl: I'd like to point out that the paper in question on colliding MD5 hashs is from March 1st, 2005 (23:44:58) GolfRomeo: iang : I can tell we spent a lot of time (23:45:16) markl: issuing roots is as much, if not more, an administrative exercise, than a technical one, and we need to make mighty sure that we do it "right" this time (23:45:18) andreasbuerki: of course we need to know the workload for planning, so say it in terms of manpower and time (23:45:33) iang: markl: right (23:45:36) andreasbuerki: how much is a lot and how did what? (23:45:39) markl: and the right place to plan that is not here (23:45:49) Unox hat den Raum verlassen (quit: Quit: Unox). (23:45:50) PhilippDunkel: Again you are missing the point! (23:45:59) iang: andreasbuerki: it is in the wiki ... i think Teus documented the planning line, not sure (23:46:13) andreasbuerki: at least one guy, PD understands the danger (23:46:14) GolfRomeo: andreas : you need to make the ceremony and bring people to one place (23:46:30) andreasbuerki: point me the wiki page, please ian (23:46:39) markl: andreas: to say this is not the right place, isn't to say there's no danger (23:46:42) iang: markl: true, we can't plan it here. But we can decide here. Although frankly, I'm not sure what we can do other than send someone else off to prepare a proposal (23:46:49) PhilippDunkel: The point is, we don't need to have the new roots issued by tomorrow. All we need to do is make the decision to do so and then create a group of people to come up with a solid plan. These should include the "New Roots Taskforce" as well as some outside experts. (23:46:52) GolfRomeo: Do we have a quick fix for the pb ? (23:46:59) PhilippDunkel: Then we put this on the blog, and we are done (23:47:10) iang: https://wiki.cacert.org/Roots (23:47:13) andreasbuerki: I don't expect this to be planed here, but to get your unconditional support! (23:47:23) andreasbuerki: thx Ian (23:47:24) markl: why don't you bring this up on the policy list, and put forward your proposal for creating that task force? (23:47:30) iang: https://wiki.cacert.org/Roots/NewRootsTaskForce ... is more or less the index for those pages (23:47:34) markl: because it's *their* support you need (23:47:35) markl: not ours (23:48:07) PhilippDunkel: Something along the lines of "The board resolves that the roots need to be reissued and charges XYZ with preparing to do so" (23:48:33) andreasbuerki: if borad thinks it is no emergency, the others will thinkt to! Board has a leding reaponsability! (23:48:33) iang: PhilippDunkel: in a sense, yes. But who is XYZ? It isn't me, I don't think I have time until post-AGM. (23:48:51) markl: PD: you were just a while ago complaining to the effect that we were usurping the community's authority.. this is the community's task thru the policy group (23:49:02) markl: has anyone recently made these suggestions on the policy list and been rebuked? (23:49:15) markl: if you have, lets hear it, and deal with it here to send the right message (23:49:19) iang: also, the budget for the last one was probably 1-3k spent. (I didn't account for all of it, so not sure) (23:49:20) andreasbuerki: it has been requested by the support list (23:49:29) iang: so it can't be done until finance is resolved :) (23:49:31) markl: but if not, the right place to start this discussion is on the policy list (23:49:46) PhilippDunkel: @mark: That was one of the silliest statements yet: (23:49:47) PhilippDunkel: markl: PD: you were just a while ago complaining to the effect that we were usurping the community's authority.. this is the community's task thru the policy group (23:49:54) andreasbuerki: this spending we save on zero-cost hosting Iang ;-) (23:50:02) markl: it will spill over to board business when it comes time to implement it, by assigning budgets, etc, but it isn't right now (23:50:28) iang: markl: i don't think there is a policy question to ask: the CPS does not recognise the current roots as auditable, so of course, the policy group agrees they have to be re-issued (23:51:07) iang: but if you want to ask, we can have that debate there :) (23:51:21) markl: policy group at least has the right people in it (23:51:29) PhilippDunkel: I am getting thrown out of the place I am at in about 4 minutes. I will then move and try to rejoin in a bit. Until I can, Andreas has my proxy (23:51:30) andreasbuerki: And Philipp Ghuering was as well proposing: (23:51:31) markl: to develop a plan, build a task force, etc (23:51:35) andreasbuerki: The next thing we need is a decision, whether we want to issue a new (23:51:35) andreasbuerki: Class3 root beyond our current Class1 root, or whether we want to issue (23:51:35) andreasbuerki: a whole new Root certificate-structure as well. (23:51:59) andreasbuerki: so OK, PD (23:52:02) markl: these are largely technical discussions, too (23:52:10) andreasbuerki: agree, marl (23:52:10) markl: class 3 vs class 1, which attributes, etc (23:52:10) iang: we have most of that decided already. we just do the plan on the Roots, I think. (23:52:27) iang: GolfRomeo: do you see any reason to vary the 2008 plan tremendously? (23:52:41) GolfRomeo: iang : no (23:52:56) GolfRomeo: iang : I guess it is ok (23:52:59) markl: so, if there's even the slightest debate about the technical side of things, again, this isn't the place to decide it, because we don't have, nor do we need to have, the knowledge to make those decisions by ourselves (23:53:07) iang: my view is that *if* we have to do anything, we should do everything. There are no short cuts (23:53:12) iang: so we have the plan. (23:53:13) andreasbuerki: markl, of course... (23:53:29) iang: or at the very least we have a working plan to start with, update for a year's extra thought. (23:53:36) andreasbuerki: so, who has the knowledge? (23:53:44) markl: andreas: my point in all this is I agree with you as to the need to do it, but I don't think this is the right place to start the discussion (23:53:53) PhilippDunkel: Ok, got to go. CU (23:53:54) markl: the policy and systems lists (23:53:55) PhilippDunkel hat den Raum verlassen (quit: Quit: PhilippDunkel). (23:54:13) markl: this is a conversation that needs to be had with all the stakeholders (23:54:15) iang: markl: polite reminder of spam discussion :) (23:54:15) andreasbuerki: agree, mark, I justr wanna have the formal support of the board (23:54:49) GolfRomeo: I support we do everything needed to avoid security issues (23:54:54) andreasbuerki: to put into place a task force (23:55:04) markl: iang: I didn't start the spam discussion either ;) (23:55:08) iang: golfromeo has some of the knowledge, having done it twice (23:55:15) andreasbuerki: what takes imdediate care of 665 (23:55:24) GolfRomeo: (if we have the funds to do it, else we need to find a quick fix) (23:55:41) GolfRomeo: iang : yes right I can advise (23:55:44) andreasbuerki: if GR has time to help... higly welcome (23:56:05) iang: Security Policy rules over this, we'd need to check it ... the thing that I am thinking of in answer to andreasbuerki's question on "who" is that we need 2 or 3 directors in the same place to do this (23:56:13) GolfRomeo: Key generation is more interesting (23:56:30) iang: and the thing that is missing out of the plan is how to then protect the keys. That's a debate to have over on policy I think. (23:56:43) GolfRomeo: But all the material on the wiki/svn is enough to make a new ceremony (23:56:51) iang: (e.g., how does the board keep control of its root backup copy) (23:56:55) GolfRomeo: but advise is ok from me (23:57:01) andreasbuerki: ok... but again, I kindly ask for your fomal support by a motion (23:57:29) iang: andreasbuerki: do you want a motion or a solution? (23:58:05) andreasbuerki: a motion, as the solution is not available (23:58:38) iang: a motion is easy, because the position of the prior boards going back to 2007 was that the roots must be re-issued ... we can repeat those words (23:58:52) markl: yeah, there is an existing mandate for this (23:59:16) markl: but motions do not make the work happen, someone has to do the actual work of proposing it on the right lists, etc, getting the remaining policy issues hashed out, etc (23:59:27) iang: yes (23:59:29) markl: a motion will neither help nor hinder that work, andreas, if you want to take it up (23:59:49) iang: and this one is quite a bit of work ... plus also requires travelling, and integrating calendars for people (23:59:49) GolfRomeo: yes but the pb is we *did* the key ceremony already (00:00:06) markl: but I would suggest taking it from a different angle, and almost putting the MD5 risk to one side, because it will get lost in endless technical arguments about whether it's a real risk (00:00:27) iang: GolfRomeo: yes, but there is an issue with those keys. personally I'd prefer to do it again. (00:00:35) markl: we have other, in my opinion far more important reasons to reissue the roots (00:00:48) pemmerik hat den Raum verlassen. (00:00:49) andreasbuerki: aha... even more reasons..... (00:01:07) GolfRomeo: iang : I understand there is the same gap we have between Sydney and Vienna (00:01:15) GolfRomeo: s/have/had (00:01:30) GolfRomeo: (lost control of the keys) (00:01:45) iang: yes, hence my comment on how the board looks after its copy of the root. you got it. (00:02:25) markl: as to the altnames issue you raise concerning the two universities, someone probably just needs to write a patch for the system (00:02:39) markl: it doesn't have any policy effects, as it's only modifying the CSR (00:02:46) andreasbuerki: would a claas-3 replacement take less time and ressources? (00:02:51) iang: markl: at least, that's the start of the practical work (00:02:54) markl: just needs someone technical to get it done (00:03:10) iang: andreasbuerki: not in my opinion (00:03:12) GolfRomeo: andreasbuerki : pb you need to define the ceremony and test it (00:03:19) andreasbuerki: ok... (00:03:52) iang: although, potentially, it is easier to do a non-auditable class 3 replacement ... but even then we may as well do both ... and the work afterwards still has to be done (00:04:14) markl: yeah (00:04:21) andreasbuerki: According to Philipp Guehring / by e-mail:The first thing is that we need a small improvement to our software to (00:04:21) andreasbuerki: support expiring CA certificates, to avoid breaking the CRLs. (I (00:04:21) andreasbuerki: implemented half of this already, only the second half is missing). I am (00:04:21) andreasbuerki: able to do that within a week I guess. (00:04:21) andreasbuerki: The next thing we need is a decision, whether we want to issue a new (00:04:21) andreasbuerki: Class3 root beyond our current Class1 root, or whether we want to issue (00:04:21) andreasbuerki: a whole new Root certificate-structure as well. (00:04:21) andreasbuerki: Then we have to generate and deploy the new CA certificate. (00:04:21) andreasbuerki: Then we have to enable the usage of the new CA certificate in our software. (00:04:21) andreasbuerki: In the mean time, we should inform our users about the new certificate, (00:04:21) andreasbuerki: which they have to do correctly for Certificate-Chains. (00:04:43) GolfRomeo: We can use the class 3 root we made in 2008 (00:05:05) markl: all great questions, but all outside our mandate (00:05:49) markl: there doesn't seem to be consensus for a motion on this issue, and we're down to debating techie stuff again, so I propose we move on unless someone has a motion to put (00:05:55) iang: If you're asking whether we issue a replacement class3, or a whole new structure, I say whole structure. (00:06:22) GolfRomeo: iang : why don't we use the class3 cert we made last time ? (00:06:46) iang: because it isn't signed by the class 1, it's signed by the new root instead (00:06:56) andreasbuerki: As said by PD: The point is, we don't need to have the new roots issued by tomorrow. All we need to do is make the decision to do so and then create a group of people to come up with a solid plan. These should include the "New Roots Taskforce" as well as some outside experts. (00:07:11) iang: although maybe I'm confused, I don';t think we made a class 3, we made a new "assured root" (00:07:11) markl: andreasbuerki: but we already have that decision, several times over (00:07:21) markl: it hasn't translated into someone doing the ground work to prepare for it though (00:07:35) markl: *that* is what is needed now.. people doing the work to make it happen (00:07:46) iang: yes (00:07:54) GolfRomeo: iang : yes it is not a big problem as people are less likely to use the class3 root cert anyway (00:08:10) andreasbuerki: as usual... it needs to be written and coded and done (00:08:19) markl: I honestly think if you start this conversation on the policy and systems lists, you'll get a positive response, and find a bunch of people to start help moving on it (00:09:04) markl: it really probably just needs someone to take the initiative to lead it... that person can be you, Andreas :) (00:09:06) iang: ok, that can be done. my view is we need someone to manage the process. and I don't see that someone. When the someone is found, it'll move (00:09:18) andreasbuerki: and their is not more formal stuff needed, mark? (00:09:36) markl: andreas: not in my opinion.. there's an existing mandate (00:09:36) iang: last time it was Teus, with Guillaume doing a lot of the writing of code (00:09:52) andreasbuerki: what are the qualifications for *someone*? (00:10:08) iang: i would be happy in theory to do it, but not in practice. no time, no budget. (00:10:12) markl: just needs someone to champion it (00:10:22) GolfRomeo: andreas : knowing X509 certs and coding (00:10:22) markl: to start suggesting the things that need to be done (00:10:25) iang: possibly in the new year. (00:10:28) andreasbuerki: be more precise, gentlemen... ;-) (00:10:32) markl: like finishing off the policy of how to handle the keys, etc (00:10:36) markl: it's not a precise task (00:10:42) markl: your job is to lead the discussion (00:10:53) markl: to identify what work is left to be done (policy work, patches to systems, etc) (00:10:56) iang: andreasbuerki: read the pages on the wiki. Find someone who understands all that stuff (00:11:12) markl: document those things, find people to take on tasks (00:11:17) andreasbuerki: so I could incloud the Universitiy guys, as they are assurers as well? (00:11:24) markl: find people who are experts in their niche, and put them to work (00:11:30) iang: you need a manager who's also a techie and won't get snowed by a PKI nut. (00:11:47) iang: I reckon that would be PD, ML, or me, to add my toot-toot (00:11:50) markl: can include your next door neighbour if it helps... that's the whole point, by doing this on the lists, *everyone* can help (00:12:03) iang: but I'm guessing we're all busy :) (00:12:19) markl: if you want to get the ball rolling, Andreas, I will certainly pitch in where I can, and I'm sure the others will too where time permits (00:12:29) andreasbuerki: no prob, Ina, I'll find people interested in the issue... ;-) (00:12:37) markl: you *have* our support, 100% :) (00:12:53) GolfRomeo: 110% (00:12:55) andreasbuerki: thx :-) (00:12:58) iang: andreasbuerki: you have more chance of finding the uni guys to help on the root re-roll (00:13:03) andreasbuerki: woow... next bid... ;-) (00:13:05) iang: than on the patch for that fix. (00:13:26) markl: ok, lets move on to the next item ----- END TRANSCRIPT AGENDA POINT 2.4 -----
YYYYMMDD-YourName
Text / Your Statements, thoughts and e-mail snippets, Please
Category or Categories
CategoryTechnology
CategoryQualityManagement
CategoryAudit
CategoryProjects
CategoryCustom note: Please, replace "Custom" with an existing Category or if needed create a new, meaningful one.