Reimplement or not?

Because of a requirement of the Auditor, a group of three CAcert.org members met him near Innsbruck the week of Sunday 19 of April 2009 to review LibreSSL, the software we run in https://www.cacert.org, and to see how hard would be to make it fill our current and future software needs.

Analysis of Existing Code

  1. 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.
  2. Documentation
    1. Documentation of the code is non-existant.
    2. Existing documentation 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.
  3. 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 object orientation. The code follows a series of paths that feels like spaghetti code.
    4. No separation of display from query from business logic. HTML is generated inline, with echos. No possibility of doing layout changes. Code directly 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.
  4. Security
    1. For all we know it is perfectly secure, but we cannot confirm it as secure. There are many wrappers.
  5. 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.
  6. 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.
  7. 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.
  8. Miscellaneous
    1. Use of Javascript is light, mostly pointless. The location part is ok but could be done differently. (this is not a reason against)

Conclusion

In an email to the board they concluded on April 22:

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.