Previous:
Innsbruck Software Camp 20090419.
Present: Markus Warg, Dirk, Walter, Wolfgang K, Ulrich, Mario, Andreas Bäß, Iang, Christopher Etz.
Photos by Walter.
Meeting called by Ulrich after concerns about software repository and patching procedures. Started 15:00 closed around 20:00, informal after that.
Estimated cost €400, see details in Minutes for Hamburg MiniTOP.
Arbitration for ABC: Wolfgang K interviewed, ABC is started. Software, repository.
Ulrich opens: What is planned? next steps? What People? Philipp and?
Dirk + Andreas. nobody working on software, everyone asking ... why? First problem was source and documentation. Dirk has the patches, but not being installed?
Why is the software not moving forward? Andreas found out why, he says. He is familiar with software development, quality control, etc. Talked to several people and got support. Wytze, Mendel. Start with the version control system (SVN w/certificates) (not the birdshack one).
Establishing the procedure to get prudent and stable releases. Asked the critical system administrators what needs to be done:
Andreas and Markus now installing two test systems. First will track the core-server directly. Second test system will have the actual branches the developer wants. Will improve the doco to show the process. So developers can then follow the process and do the work.
Integration test environment is up and going. Will use the CCA patch(s) to shake-out the process, document it, to find out what would happen if the patch was applied. Responsibility of critical sysadms.
The test system should have the up-to-date software base. Current software bases won't be maintained forever, PHP / linux. 1st stage will be more up-to-date. 2nd stage will track current installed old versions.
Ulrich has provided the hardware. Two HP zeon cpus, 2.8ghz will be located in office of Andreas. These are not critical systems. However, critical systems admin team will configure the 2nd system, over ssh so it is tracking the core production server's software base.
(Others will work with the database.) They will build the process with goal of preparing a release candidate. As it is readying for release, we do code freeze on the production system. If there is any changes after code freeze, there will be problems, and we'll have to watch this part carefully. Any changes and someone will be shot. Only tests will be run. Will put limit the number of big fixes.
Big problem is a lot of fear in making the changes because nobody can see what is going to happen. Regression tests: andreas was intending to write his own. Iang mentioned existing system, which is not currently working, but there is probably lack of documentation for it.
Andreas was asked why not work on birdshack path. Going for the update/patch path first because he wants the procedures in place first before writing the code to do it. Hard to tell a story of high quality without having the procedures / software alignment.
Mario: see no conflict with birdshack path, we need all this anyway.
Markus asked whether he has looked at code. Responds, yes, code is "self-grown" or "home-grown". We have 2 developers: Markus & Dirk.
How are the patches working now? The cert-display-for-SEs patch that is in the queue got a response that it could be improved, which is good, a dialogue is in place, and there are reviews in place. Now to fix that and send it back.
Patch from Markus generated confusion of versions, hence we need that SVN to coordinate branches and versions.
Repository is up and going. Haven't got the test system, just the developer system. We expect to have everything together by end of January.
Where is the tracking of decision number or bug listing, and the reviewers? Probably in the svn commit comment? How is it done now? There is no visibility of the comments, Dirk to ask Wytze whether that is available.
CCA patches are going to be used as a test of the process, to create the documentation. Need to get Markus and Dirk through as Software Assessors so they can work together to approve the patches.
Ulrich asked for a birdshack explanation for the software developers. Mario presented the high-level doco.
The basic high-level design for a new system was done, but the project stopped at that point, more or less. The documentation is at https://dev.cacert.cl/ (this wiki) which includes use cases, roles and so forth.
In the new year, likely the board will put more attention on re-starting that effort. No problem with using the infrastructure set up by Andreas and his team.
Markus made comment that separated boxes over net/protocol/API is risky (has seen it fail in the past) and suggested something more monolithic. Iang made comment that it heavily depended on who was doing the production; he has done this separated design (2 or 3 tier) before.
Ulrich asked for description of the 2008 root project. Iang described.
Problem with the root is that the subroot has MD5 signature, which is under a cloud. The 2009 attack is currently not feasible on CAcert because of the use of nonces, but the whole environment is now aggressively against use of MD5. Should switch to SHA1 at least.
The audit review over the old roots resulted in a FAIL over the roots because there was no history of the Sydney era. Hence decision of 2007 board to create new roots. This opportunity came when the systems were moved from Vienna to Ede.
The basic requirement is to create the roots with high security in both hardware and people. 2 Directors need to be present and at least one sharp sysadm. We need coding skills to generate the keys and we need scripting skills to codify the process as a protocol. Guillaume wrote the generation in Java, Teus wrote the scripting in shell.
We attempted to do this 1st-2nd October after the machines had been moved. This effort failed due to bugs in the process. We re-convened 1st December (dates from memory). This time the process worked.
Process involved building hardware and installing software from scratch. Strong emphasis on protecting the hardware and software from backdoors or injections of malware. Once the process is done, the hardware is destroyed. Result places the root(s) onto memory sticks for escrow and delivers the subroots to critical team for install on Ede.
In May, auditor returned to review the situation; but there was no success in escrowing the roots. They were still located in single safe under no dual control / no 4 eyes. Also, although encrypted, the password was not separated. Consequently these roots would have difficulties meeting an audit.
Failure of the escrow was due to the difficulty with the method. Concept was to place the keys with notaries but they were not so familiar with the need, and their work is more to do with securing documents for future juridical needs than securing assets from theft, etc. So while the current roots could be used, there is somewhat of a difficulty; likely we'll have to go through the same process again.
In order to re-do this process, we have to do: planning, collection of the people, budget, hardware, and also to come up with a new concept for protection of the root. This latter is important, and the whole thing will need to be serious and documented for presentation to a new auditor.