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