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 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