CAcert Code Development list.

[Alejandro Mery Pellegrini <amery AT cacert.org>]

Hi People,

Attached you can find the LibreSSL's review done during this week in
a software camp at Wattens (near Innsbruck). Once at home I'll try
to make public the rest of the documentation we wrote public asap.


This is most probably the last sent mail from this software camp.

Alejandro Mery

--- Begin Message ---

• From: Alejandro Mery Pellegrini <amery AT cacert.org>
• To: CAcert Board <cacert-board AT lists.cacert.org>
• Cc: Philipp Gühring <philipp AT cacert.org>, Bernhard Fröhlich <ted AT convey.de>, Ian G <iang AT cacert.org>, Mario Lipinski <mario AT cacert.org>, Philipp Dunkel <p.dunkel AT cacert.org>
• Subject: LibreSSL's review for Audit - Innsbruck meeting
• Date: Wed, 22 Apr 2009 20:43:36 +0200
• Organization: CAcert.org

Dear Board,

We met here in Innsbruck the week of Sunday 19 of April because of a
requirement of the Auditor to review LibreSSL, the software we run
in https://www.cacert.org.

Attached you can find the analysis we made.

Having reviewed this application we believe there are several
difficulties within it, and we see three options:

1) We can keep patching the current code base to inject the features
we need. We consider this impractical, difficult, and as now it will
keep contributors away.

2) We can also redesign/rewrite some parts of it to get into a more
documentable/maintainable state, but without really understanding
the workflows and the implications of each change it may produce
security problems.

3) Or we could design something new from scratch for our modern
needs, implement it and then swap when it's ready. It will consume
time and resources but the result will be much more maintainable,
extendable, scalable and we can attract more contributors and
developers.

Having considered this, we believe the only sensible choice is the
third so we started a new design and it will get reported when we
have it's ready.

Best regards,
Alejandro Mery
Mario Lipinski
Philipp Dunkel
Analysis of Existing Code

Extendibility
1. Extendibility is difficult. We have lots of needs, things that should be 
done within the system.
2. With current code base it is too hard to get involved in the code so we 
cannot get the people to implement the features. If it was designed well, we 
could get contributors to implement and reimplement things we need.
3. Finding out how to add multiple names is very hard. We will have to 
redesign those parts. Everything in the code assumes one source of points, 
person has points. Fundamental data changes are hard.

Documentation
1. Documentation of the code is non-existant.
2. Existing documention and available source code is not enough to let 
developers install and get a version for testing.
3. Even Mario who has 10 years experience PHP cannot read the code by now 
with a reasonable effort to figure out the important points and came to the 
conclusion that it is not worth the time to figure it out. The effort is more 
than is reasonable to invest, motivation needs to be very very high, and most 
people won't which is why most people won't contribute.
4. There should be support that allows easy install and getting running.

Design
1. The current software follows no familiar or acceptable development 
paradigm.
2. Numbers are used to identify files which contain actions, rather than 
meaningful names. Everything around topics is spread around files, rather 
than functionally divided. Getting structure out of the code flow is 
difficult.
3. No modularity. The code follows a series of paths that feels like spagetti 
code.
4. No separation of display from query from business logic. HTML is generated 
inline, with echos. No possibility of doing layout changes. Code direcly 
accesses data from REQUEST, not layered.
5. There is no clear API.
6. Assurance rarities are incorporated in code rather than being regularised 
into some framework. Tverify. Buergerkarte. Should be an API to do 
exceptional assurances.
7. Documentation for CAcert users is interspersed through the system. Large 
text parts are within the source code and need a programmer to adopt them. 
There should be some content management facilities. For documentation changes 
no patches should be needed.

Security
1. For all we know it is perfectly secure, but we cannot confirm it as 
secure. There are many wrappers.

Coding style
1. The code uses deprecated features of PHP.
2. The code is clearly old (this is not a reason against).
3. Basic coding uses fall-through style with many 'if' statements rather than 
'case' and function calls.
4. Usage of strings doesn't help translatability.

Efficiency
1. Queries are not optimised and do one query per record instead of one 
single queries over all data. Queries in loops, not using joins. Assurer 
search takes minutes, Assurers with many assurances slow down. Inefficient 
use of backend storage. The amount of data we have is very little. redesign 
is the only realistic solution for this.
2. Currently slow queries can be DoS and make it difficult to grow.

Functionality
1. Support interface has important missing features.
2. Roles are confusing, appear to be added in an ad hoc way.
3. Lacks good features for searching for people is difficult.

Miscellaneous
1. Use of Javascript is light, mostly pointless. The location part is ok but 
could be done differently.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

--- End Message ---

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature