Present: PG, PD, iang Location: Moebel == background check == * discussion on board list * bgc is to be a "practice" but not a policy * how to advance the background check forward * teus has asked for a BGC on a new sysadm * according to the practice, this is handled before an Arbitrator * teus has filed dispute? * by implication, yes * Philipp Dunkell should take it through the first time * so as to establish a precedent / pro forma ruling that expresses the result * much easier for other Arbitrators to follow practice + ruling * Philipp D to volunteer as Arbitrator * posted into SecurityManual * all sysadms to be background checked * disputes to be filed * '''PD is away for a week, when back, monday''' == (Assurance) Event == * purposes * bring Assurers up to date * Audit on Assurers * destroy drives * workshops on Assurance * jazz it up * 28th Samstag * Philipp D, Philipp G, Philipp L, iang, Matthias G are OK with this date * can we get Ted here? * can it be paid for -- Yes. * can we find accomodation? * action point: what is location? * '''all to chase''' == Super-assurers == * policy decision is that all past ones have lost their status * however it is left open for board * updating is done by how? * members ... have points up to 150 * 200 super assurers * 300 board members * 400 sysadmins * let's get a list of superassurers * and then turn them off * this is a decision? * the decision was already made by policy or board * "send me an email with that decision" * '''PD to dig out that decision and send it to sysadms/philipp G''' * Assurances can be revoked * then they are deleted from the database * or can they be negative? * apparently they can't be negative * we shouldn't delete assurances * how? is an implementation issue * file a feature request ... * discussion morphed into discussion on logs == logging == * a better idea is to make proper logs of the actions * we need the log for arbitrations * better idea than not deleting them * this is code that needs to be added * can we generate the log with what we have now * "no, ... not much, ... maybe" * if we cannot re-create this for a later time, over the past, this is priority #1 * if we can, no problem * what is the status of logging? * a few things are logged * no cohesive module for logging * some additions to the database structure * what are the actions? * certificate issuance and revocation * account creation? why is that critical? * changing and viewing of personal details * assurance, changing up or down * what are the admin actions? * changing the name * setting a password * activating code-signing * all these should be logged * how is log is done? * into flat files? * then import into SQL * or into SQL and then exported out * rotation of files? * important things are logged * except for deleted Assurances (how to get supers dropped) * are accounts deleted? * yes, because Arbitrator ordered it * no, because accounts should not ever be deleted but should be zeroed! * they are deleted as account * but in future should be zeroed out? == Misc == * Assurance Handbook * => ted needs new minds on the job * iang thinks it is ok for now * maybe at Assurance events we can do recruiting * Code-signing * should be easy * insist on Assurer * 100 points covers the identity * Arbitration covers the enforcement * should Arbitration be used to control it? * this ensures that the Arbitration is agreed as the forum * Does this scale? there are hundreds of code-signing certs, maybe 1000s? * Shouldn't it be automatic? * '''PD to look at it.''' * disaster recovery * Rasika has provided a start at DisasterRecovery deriving from work done on BusinessProcesses using the framework of CISA. * ''PD to look at it.'' * 3rd party vendor agreement * not looked at * CPS * teus posted comments on CPS, mostly fairly light * change in format from HTML to OO will slow down readership, cause name change problems and have to go back to HTML anyway * typos, formatting, suggestions changes copied back to svn.cacert.org/CAcert/policy .htm HTML of [[https://www.cacert.org/policy/CertificationPracticeStatement.php|CPS]] * Evaldo is reading it * need more readership, is it ready for policy group? * discussion on use of IP from xkcd.com, basically good but should clarify the rights, '''iang''' == Software Development == * PG raises apps admins * there should be OS/hardware admins managing the hardware and OS * then there should be apps admins who update and manage the apps * old system is that * CVS repository on primary online website system (not a daemon/online CVS) * manual copy of approved source code to the online server * (by apps administrators) * checked in manually, checked out to online running code * in new arrangements * critical systems admins need access * approvals administrators do not * systems admins should do the svn update from remote repository * do a diff of the cvs copy * pass the diff back to approvals team * when the approvals team approves the diff, systems admins can do the cvs upgrade * but, svn is unreliable / insecure * svn is not a security project! * svn isn't watching for security like the openssh project is * ok, so the ''method'' of transfer is not specified * but the point is that the system administrators do it * sysadms have to develop a procedure for this * to transport it securely, as well as other parts * detail transfer method is not really to be in the SM * either way the systems administrators on the critical team have this responsibility * Wytze loves diffs * should be able to produce a set of diffs on the critical server * match that to the set of diffs on the development server * diff the diffs * when the diffs match, let's go * sysadms could get approval of the diffs? == Software Team Manual == * should not be more than 3-4 paras * does not cover tools * (see above comments about method of transfer of patches) * Software is handed over to Systems team * joining is done by * inside team has to propose and ask * inside team is to do the preparation and interview * initiate the background check / Arbitration * board signs off on it * concept from past: * anyone can contribute the code * team is primarily auditing, verifying * team is not developing * therefore the name code audit team or code verification team * "code improving team" or approval team * this gives us a way for 3rd party code... * how do we define the systems administrators * are the systems administrators * since we have virtualised * application administrators who operate the apps on the machines * e.g., DB is an app admin for email * which team does what? * the critical systems admins currently also manage the apps * the hardware access team is defined with MoU * as the access list in Appendix B * Wytze is currently managing both of these teams * whether these are the same or different is irrelevant * roles * approve software * manage non-crit * manage the app * access the hardware * support person * perceived difference between '''Group view''' and alternate '''Roles view''' * '''iang to review this content for SM''' ---- . CategoryPolicy . CategoryArbitration . CategoryAdvisory