Site@School and Syndeo CMS

Site@School and Syndeo CMS

By Dirk Schouten and Karin Abma (members of the Site@School Development Team)
Due to a lot of work on the Site@School project, we have little time. Ap9logies for typos.

Contents

1. Introduction
2. A shot across the bows
3. The security meeting
4. Hacked!
5. The first security report
6. What Fred and Dirk agreed
7. The second security report
8. A laymans explanation
9. A team meeting
10. Memo's from Richard
11. Richard and Freds wife enter stage
12. Another team meeting
13. Our own forum stolen and our project hostaged.
14. Latest developments
15. March 8, 2007. Case closed

1. Introduction

This page explain in detail the backgrounds of the schism in the Site@School team. We will explain the backgrounds, how we tried to keep Fred in the team and how he left the team. After leaving, contrary to his promise, he tried to stay project admin on our own Sourceforge site until the first of July 2007, thus holding the project hostage.
And, on security and maintainability, we shall prove with detailed reports why our choice for a complete rewrite of the code is the best choice for a school CMS

Ofcourse we will underpin these assertions with evidence. We shall give evidence in the form of e-mail copies, security reports, usenet messages, scans and PDF's of memos, i.e. all evidence that we can produce to make clear that:

Fred's fork (clone) of Site@School, Syndeo CMS and what is connected to it is risky stuff to choose as as a CMS for your school or to migrate your existing Site@School version to

We hope that, when you have read this material, you have an informed opinion on what has happened and why we took the difficult decision as we took it. That is, that a complete rewrite of the Site@School code is necessary to keep the system secure, manageable, maintainable, make it more robust and to ensure that it becomes compliant with government security legislation. Security must be a matter of constant concern in a CMS that has education as its primary target group.
We see it as our duty to explain all this to our users who have trusted their valuable website material to our Site@School CMS. And, since it's Open Source, it's better to be open about matters. For example, when we would keep the security reports secret, we risk being discovered. Then our reputation would really be damaged. An interesting article about how to handle security issues is written by Eric Allman (Sendmail): On the Receiving End.
Our personal opinion on the whole matter? Unprofessional behaviour for a project admin and main developer. And that's all we shall opiniate about the matter.

As you know Site@School is made in the Netherlands. Some material on this page is in Dutch. Find a Dutchman! (or woman).

Ah, a last word for this chapter:
WARNING:As promised earlier we will be releasing a new version of Site@School later this year. Until the new version is ready, the team will be issuing security fixes and patches for the current version, 2.4.10. Also we will provide a migration path from 2.4.10 to the new version.

Please be aware that, if you switch to the 'other' CMS, upgrading to our new version of Site@School will almost certainly become impossible, so please stay with Site@School and wait for the new release.
Do not mess with your school's data!

(top)

2. A shot across the bows

There were security issues which we tried to handle as careful as possible. As an example, an e-mail from Dirk to Fred, dated the second of July 2006: 

Hoi Fred,
Peter belde me rond 15.00 uur, waarna ik direct jou belde.
Er zit een veiligheidsprobleem in de file upload en/of de multiple file upload en/of de fck editor en/of .....?

Peter kon via de file upload files neerzetten in mijn document root en, zo hij dat wenste, in staat zijn mijn document root te wissen.

De inhoud vn de files vind je hieronder.
Het was voor Peter aanleiding om op de 8 servers die hij beheert de file upload buiten werking te stellen. ICT'ers worden op de hoogte gebracht.

Zijn advies: breng een fixpack uit zonder te noemen dat dit issue gefixt is. Er is vast nog wel iets anders dat gefixt moet worden. Het noemen van dit lek zou slapende honden wakker kunnen maken.

Dit is de inhoud van het file dat hij neerzette:
[root@jh htdocs]# cat hello.php

[root@jh htdocs]#

En dit is waarmee hij het deed:

[root@jh htdocs]# cat wyxs.html

Send this file:

[root@jh htdocs]#

Ik vind het alarmerend.
Groet,
Dirk

Here we were still struggling with the issues Mr. Eric Allman brought up in his article On the Receiving End.
How do we deal with with this serious security issue? We solved the issue by being a bit more open. However, how open or not open we have been is a matter for evaluation.

As usual, Fred made a quick fix and reported on the same day (2nd of July): 


Dirk, Peter,
Dit is niet zo mooi!
Ik heb de javaUpload.php script aangepast met twee checks:
1. wordt de file wel via een S@S script aangeroepen, zo nee exit
2. is wel een sessie via een userid van S@S , zo nee exit.

Peter, is deze code ok zo dan breng ik hem gelijk uit in fixpac 2.4.02.

Bedankt maar weer voor je kundigheid op dit gebied!

Groet Fred

In another mail, the same day, Peter expanded the matter. Some parts are anonymised for security reasons: 

Het gaat m.i. niet alleen om javaUpload.php maar ook om de andere files in
bovenstaand lijstje.
{list removed for the bad guys, DS} 
Ik heb gezocht naar plaatsen waar XXXXX_file()
voorkwam in de source (zoals ik al aankondigde in de thread met de YYY-school
op het forum: ca 10 files). Op de meeste plaatsen zie ik geen validatie op
'verboden' extensies zoals .php en vaak ook geen check op het ingelogd zijn
en/of het include()'en van het bestand vanuit de index.php
(if !defined('IN_SAS') ...etc.). Dat betekent dat iedere buitenstaander
deze bestanden zou kunnen aanroepen van buitenaf (zoals vandaag aan Dirk
gedemonstreerd). Da's mij te link om te laten staan, dus daarom:
helemaal weg. Ik heb geen zin in indringers.

Ik denk dus dat je er niet bent met slechts het aanpassen van 1 of 2 bestanden;
gezien het feit dat er op verscheidene plaatsen bestanden geupload kunnen worden
zijn er dus mogelijk issues op al die plaatsen. Ik kan de code niet goed
overzien (o.a. omdat de textuele layout in mijn editor een sub-optimaal
resultaat geeft) en ik heb geen idee waar ik moet zoeken. Mijn ingreep van
vanmiddag op de ServerAtSchool-scholen was grote-stappen-gauw-thuis. Lang
leve grep en de Linux command line.

{cut, DS}

Groeten,

--Peter Fokker

Two issues mentioned in this mail need closer attetion. There is no validation for extensions and on several places the issue could exist. These points will reenter stage when we decided that a rewrite was unavoidable.

(top)

3. The security meeting

We took the matter very serious. The team (Dirk, Fred, Karin) organised a meeting on the 19th of July 2006 with Peter. He is a professional server software engineer, developer and security expert. We asked Peter to investigate Site@School in terms of its security aspects. An extensive report would be beyond Dirks financial resources. Peter would do his utmost to keep the matter as inexpensive as possible without sacrificing precision. A generous gesture, thank you! Peter promised to do the work as quickly as possible, inbetween his other activities.

(top)

4. Hacked!

The real trouble started in the summer of 2006. From one moment to the other a lot of Site@School sites were compromised. That is, the sites content was replaced with a picture of a bearded person and notions that were 'unfriendly' to Jewish people. Fred was on holiday. We were flooded with requests on what to do. Luckily Peter and others gave help and after a week or so there was something like 'damage control'. Peter gave advice on the forum about what to add to the code, a quick fix was brought out and for the moment the problem was 'solved'. Solved, in this case, means: you fix the vulnerability but you do not know if there are other vulnerabilities, you do not know if, by fixing that one, you create another, etcetera. Much more investigation would be necessary to do a real good job.

About the same time that summer, Dirk phoned with an ISP we know well and found out that one of his Site@School sites was used as a phising site for VISA credit cards. The ISP immediately took action, reported the incident to the police and told Fred about it. Fred never told Dirk about the incident.

(top)

5. The security report

On the 13th of September 2006 the security report arrived. With growing concern we read Advies Site@School (advice Site@School).
Below is a brief summary of a 10 page report. The numbers between brackets refer to sections in the report.

The report recommended:

(apologies to Peter for this brief summayr by a non-expert: DS). The points for improvement became known as 'The Eight Points'.

(top)

6. What Fred and Dirk agreed

Fred and Dirk had discussions about the report. One of them took place on the 25th of october and another one on the 29th of november.
We discussed the 8 recommendations in Peter's report. It became clear, as Fred said "My focus is not on security". We both agreed on that. In the years that Fred was the main developer, we took advantage of his good qualities: rapid development and an open ear for users. This was a good chance to learn and omprove the quality of Fred. It can also be seen as a way to keep Fred in the team.
We agreed on the following points: Fred attended the course, given on the 31st of October, see document.
We decided to take the mail page module which Fred would rewrite according to the 8 recommendations in the report. The trial would be reviewed and a report produced.

(top)

7. The second security report

Fred's trial was reviewed and on the 22nd of December 2006 a second report, Bevindingen mailpage-module Site@School was produced. A brief summary (figures between brackets refer to secions in the first report). (apologies again to Peter for this brief summayr by a non-expert. The conclusions are literally translated, DS)
The conclusions speak for themselves. It would be impossible to end up with a secure, manageable, maintable, robust Site@School.

To be absolutely sure, I contacted another expert. With such heavy conclusions one must have a second opinion. The expert's conclusions were not that well balanced as Peter's conclusions. Here are a few quotes from Usenet and e-mails: 

Usenet posting, 26th of October 2006:
Ik moet je eerlijk zeggen dat ik na 5 minuten code doorkijken al zoveel
xss bugs heb ontdekt en zelfs mogelijke sql injecties tegen kwam dat ik
me afvraag of jullie met de kennis die je wil opdoen niet beter een
herstart kunt maken van het geheel. Dan uiteraard met een beter inzicht.

and, in another Usenet message: 

Usenet posting, 8th of November 2006:
Wat ik heb gevonden staat eigenlijk los van de postings 
die je aan haalt. Wat het probleem van site@ is is dat met
over het algemeen geen clue heeft van wat input is.

De fixes die gedaan zijn kunnen goed zijn maar het probleem
is dat het nogal verweven is in de hele structuur van site@,

Fixes lossen nu problemen op die gevonden zijn maar lossen 
niet het echte probleem op.

Neem eens contact op en ik zal verder uitleggen wat ik bedoel.

The contact per e-mail revealed we had a top security expert. He basically gave the same advice as Peter: rewrite the code from scratch. The expert wanted to stay anonymous because he foresaw trouble.

(top)

8. A laymans explanation

Both the experts findings were clear, a complete rewrite of the code was necessary to cope with the problems. I got several explanations in laymans terms on what the problems with the code were. Here are two explanations:

On many places in S@S user input is possible, for example, in most modules, in the management part, in the editor, in the mass-upload of files, etc. In all those places site visitors, or pupils, or admins can enter data in the system. All those places are separately protected against malicious user input. When one place is hacked, you can fix it, but you have to fix all other places as well. And be absolutely certain not forget one. Or to make a mistake in one of those places. When your insights on security grows or changes, you have to go through all places of user input and fix them, and do not make one mistake or forget one. As even I could understand, this becomes unmanageable. Either you forget something or you make mistakes. As the systems grows, it becomes more unmanageable.

The other explanation was given by a mathematician:
Observe this equation: 

Site@School = (security + module1) + (security + module2) + etc.

Each module has it's own code to obtain security. Algebraically this can be written as: 

S = (ab) + (ac) + (ad) + etc.

Where S = Site@School, a = security measure and b,c,d = modules. Above is shown how the Site@School code is written at the moment.
What needs to be done in the rewrite is: 

S = a(b + c + d)

Explanation: There is one function that takes care of security regarding user input. Of course this is a very simplified explanation. There are many more problems in the Site@School code.

(top)

9. A team meeting

We had a team meeting on the 11th of January 2007 we had a team meeting where I told Fred that I had to withdraw my E 7.500 offer. Reasons: the money comes from a donation. I have to be accountable for my decisions to the donator. I could not say in all honesty and conviction to the donator: "For your E 7.500 the matter is solved". I also said that I believed that the only solution was a complete rewrite of hte code.
Fred was very upset and cosidered it a 'murder on his child'. He would not take part in it.
Karin was unsure what to do. Se asked Fred, as she had done on another occasion to share the passwords for the Sourceforge site. Fred said that, when trouble would arise, he would make her also project admin (or something like that, I do not exactly remember). Anyhow, we did not have access to our own site.
We tried to convince Fred of the necessity to rewrite, but Fred kept the same position in ht debate.

(top)

10. Memo's from Richard

This new character on stage needs some introduction. Richard is an 'authorised supplier' of Site@School services. He has a Dutch site and offers schools extra services. On the 12th of May 2006 the team granted Richard permission to use the S@S logo for his company for a one year period, ending in May 2007. In compensation for this right S@Sschool receives E 10 per school per year from every school Richard sells his services to. Fred gives support to Richard on a freelance basis by selling his services per quarter of an hour. Richard tried to register the logo which was far beyond the agreement we had with him. In fact, he tried to get involved in everything that had to do with Site@School.

On the 1st of January 2007 Richard has it all worked out. In a PDF memo he states among other things: "After analysis from our site it became, in contradition to what we thought before, clear to us that the ownerships rights of the Site@School logo belong to the Rosa Boekdrukker school (with her board as highest body)." Richard concludes that the school is the owner of the project.
Here is our mail to Richard dd. 2 january 2007: 

Beste Richard,
Naar aanleidng van je memo dd. 1 januari 2007 het volgende:

Ik juich je idee toe om de rechten op de naam en/of het beeldmerk 'Site@School' onder te brengen bij de gemeente Amsterdam. Aanstaande maandag 8 januari zal ik één en ander in gang zetten door onze directeur hierover te benaderen.

Mogelijk berusten je vooronderstellingen en conclusies  op verkeerde aannames. Pro forma behoud ik mij daarom alle rechten voor, ondanks mijn positieve benadering van je voorstel, naar eigen inzicht te handelen. Dat zal altijd in het verlengde van de belangen van het Site@School project zijn. Daaruit voortvloeiend heb ik reeds contact gezocht met de gemeente Amsterdam.
Met vriendelijke groet,
namens het Site@School team,
Dirk Schouten

We contacted the municipality to ask how to do something with the logo. They did not even understand what I was talking about. At that moment I decided to register the Site@School logo and trademark myself. And to do it as quickly as possible because I felt Richard was playing tricks.

I hope the reader understands that by claiming ownership on the name and the logo it is not my intention to enrich myself with this project. I thought and still think it is in the projects best interest to have registered the name before anybody else and certainly before Richard would do it as he tried before. Here is the letter I wrote him after his first attempt.

We are willing to hand over the rights of Site@School to any instituion, board, association or foundation that is capable of taking care of the project in a way that ensures that it remains the best, and more important, a secure and robust CMS for primary schools.

On the 16th of January Karin and I receved another interesting PDF memo. See for yourself. It's not that important, but it is revealing to see how Richard is trying to take control. We have to send him copies of all our mails, all our letters, he wants to attend all our meetings, wants a say in our decisions, etcetcera. We thought it was time for a meeting with Richard. See next chapter.

11. Richard and Fred's wife enter stage

The meeting took plae on the 25th of January 2007 at the primary school Rosa Boekdrukker. To our surprise Richard came with Trinette; Fred's wife.
We agreed that the meeting would be short, each party would have a quarter of an hour to explain its position, whereafter discussion could follow. The team would start. Here are our notes, from a mail dated 24th of January 2007: 

Hoi Karin,
Dit is ongeveer zoals ik me 't morgen voorstel.
We praten met Richard niet over de code. 

Er zijn drie gebieden waarop we Richard hebben meegemaakt en alledrie zijn ze ons niet bevallen.
Vanaf het begin hebben we de rode loper niet uitgelgd.


1. Als verkoper:
- mail karin van April. We zijn voorzichtig
- contract: we zijn voorzichtig want voor 1 jaar
- adviezen aan Richard over verkoop:
	Goede ideeën geleverd: telefonische verkoop met 2 monitoren.
	R. huurde iemand in die niet kon verkopen
	R. ging 't toen maar zelf doen
	R. vond telefonische verkoop niet leuk
	18 scholen nu, sinds de zomervakantie
	Bij minste trouble roep je dat je de verkoop stil hebt gelegd. Dat is waar of het is niet waar.

Conclusie: je kunt niet verkopen of je spreekt de waarheid niet over de verkoopcijfers.. Wij hebben er  geen vertrouwen in. 

2. Als parter.
- Wat voor 'parter' ben je? zie je memo en email.
memo: je vraagt ons alles op tafel te leggen, cc's enzo
Maar in een mailtje zeg je: ik zeg iets wanneer het mij uitkomt. Mail Richard dd 17 Januari 2007: "De afspraken tussen Fred en mijzelf/Scorpio b.v. is een aangelegenheid tussen hem en mijzelf/Scorpio b.v."

Zo gaan de dingen: als 't _jou_ uitkomt.
- Jij registreert siteatschool.nl en komt dan pas langs
- jij registreert merk en meldt het dan pas. Wij moeten in actie komen met een waarschuwing
- jij vindt dat het eigendom van het merk anders ligt en wil 't anders aanpakken. Geen overleg. Jij stelt hoe het zit.

Conclusie: je gedraagt je niet als partner maar als een autoritaire baas die denkt dat ie ons de wet kan voorschrijven. Dat lijkt ons geen vruchtbaar toekomstperspectief.

3. Als ondernemer:
- Vanaf het begin heb je gepoogd mij mee te trekken in je ondernememing. Talloze telefoongesprekken waarin je aandrong op samenwerking, overleg. Het zou mij er steeds meer intrekken dus zei ik: je moet het _zelf_ doen.

- Je wringt je tussen Fred en het Site@School team. We hebben Fred gewaarschuwd dat dit zou ontstaan. 'Knecht van twee meesters'. Nu heb je 't misschien voor elkaar: ons uit elkaar gespeeld. Dat laten wij niet over onze kant gaan. Wij vertegenwoordigen een meerderheid en kunnen besluiten nemen. Ziehier.

Conclusie:
Als ondernemer heb je het stom aangepakt. Het was niet nodig geweest.
Je hebt een 'lose-lose' situatie geschapen.
Wij hebben de plicht jegens het project en de scholen  de verliezen beperkt te houden.

Zoiets,
Groet
dirk
PS, dit is mijn spiekbriefje voor morgen.

Richard and Trinette listened. As agreed, no comments. Thereafter Trinette said that what she and Richard had to say was written in a memo that would certainly shock us. They handed us over the memo, left the room to give us time to read. We were presented with a memo, printed on heavy paper with their initials on every page (Dirk cot a four page copy, Karin a 2 page copy) and the last one with their signatures. This must be an important document.
Memo page one
Memo page two
Here is a brief summery:

A summary: Fred signed an agreement with Richards company 'Scorpio BV'. Fred and Scorpio want to cooperate with Karin and Dirk. Karin and Dirk may continue their educational involvement in Site@School. Freds work as programmer in the team can be continued. The three of us may decide what will be the basic version of Site@School. Fred will do the international forum for 1 hour per week.
The memo continues with a lengty explanation about their business.
Then they say that, due to the 'happenings' they do not want to give the Sourceforge root password (the project admin password)
They will not use the Site@School logo with the jigsaw puzzle pieces. [End of summary]

That's the memo. Well, we were not shocked. We were surpirsed. We immediately called Fred and tried to make an appointment with him. See next chapter.

(top)

12. Another team meeting

The meeting took place on the 30th of January 2007. Beforehand Fred had said he did not want to discuss with us. The reason was that Dirk 'could say things so clevery you cannot beat him". I apologised to Fred for this; it has never been my intention to beat him or anyone. Anyhow, I prepared a statement. 

Gesprek met Fred dd 30 januari.

- We spraken af dat je niet wil reageren, dus dit is een monoloog.

- Rewrite  van de code ervaar je als een verlies van je eigen kind.

[Fred agrees, DS]

- Ik begrijp dat je zeer emotioneel bent over je kind. Die emotie
verduistert ook dit gesprek en verduistert ook de oplossingen die er nog steeds zijn.  We hopen dat je je emotie even opzij zet en naar ons wilt luisteren.

[Fred agrees, DS]
 
- Dit is niet het eerste OSS project is dat opnieuw 'from scratch' begint. Het is niks bijzonders. En, waarom ik er niet zo koud of warm van wordt komt omdat ik uit de film kom en daar kennen we de uitspraak: 'Kill your darlings'. Nou, ik heb er vele om zeep geholpen bij het schrijven van artikelen, boeken, bij regisseren, bij monteren. En anderen hebben mijn geliefde stukken in de bak laten lopen.

- We denken dat je 't ermee eens bent dat er mensen zijn die meer verstand van coden en veiligheid hebben dan jij.   

[Fred agrees, DS]

- Zoals ik 't vorige gesprek begon met  'ik wil dit team bij elkaar houden'
haal ik  nu Bertold Brecht aan: "Hij dacht dat ze op hem schoten, maar hij zag niet dat ze hun best deden hem niet te raken". En beiden doen we nog steeds.

Tot nu toe zijn er vanuit ons geen onomkeerbare zaken gedaan. Alles ging in gesprekken, in overleg zelfs met meningsverschillen waardoor veranderingen mogelijk waren.  

Vanuit ons is dat helaas niet meer zo. De zaak heben wij nu niet meer in de hand. We moesten de directie 
[van de Rosa Boekdrukkerschool, DS]  't vertellen. 
Die wil nu concrete stappen:

1. Standpunt directie:

- De directie is verantwoordelijk voor websties van de OBSRB. Dus ook het forum.
- De directie volgt Peter's en de andere adviseur's advies.
- Hou rekening met de Wet Bescherming Persoonsgegevens.
- Je kunt 't niet onder de pet houden. Je moet je 't zo snel mogelijk
openbaren anders verliest 't project zijn geloofwaardigheid. Doe aan damage control en buig 't advies positief om.
Tot zover het advies van de directie

2. Probemen voor Fred, als coder en teamlid: 
- 't is OSS/GPL: iedereen op de wereld kan met de code doen wat ie wil zolang hij/zij zich aan de GPL houdt.

- de rewrite gaat door; we kunnen niet anders: zie boven de punten van de directie.

- Als we nu zouden zeggen: "we doen het niet", dan denk ik dat we verder van huis zijn want:
	* Peter gaf in het overleg van de zomer bij Karin al aan zijn scholen te kunnen adviseren van S@S af te stappen. Ik denk vat hij dat binnen een paar jaar doet als er niets fundamenteels verandert. 
	* Het is OSS/GPL. Peter hoeft niets onder de pet te houden. Hij heeft zelfs belang bij openbaarmaking vanwege zijn professionaliteit als systeembeheerder en veiligheidsexpert.
	* Vroeg of laat vallen we door de mand bij de gebruikers. De schade is dan niet te overzien. Ook niet voor degenen die beroepsmatig geld verdienen aan S@S zoals Harm Hofstede, Ruud Bredewold, Retze, Stephen Pallet, Richard, Chris Flanagan,  Je schaadt dus ook anderen in hun commerciële belangen als je 't verzwijgt. Scholen zullen voor wat anders kiezen. En ik heb het niet eens over het gezichtsverlies voor mijzelf of Karin of de OBS Rosa Boekdrukker.

- De nieuwe code wordt waarschijnlijk met tools herschreven die een steile leercurve hebben.  Dat heeft de volgende gevolgen voor jou positie binnen het team:
- Binnen een jaar is jouw rol in S@S uitgespeeld. Waarom:
	* De gebruikers willen de nieuwe veiliger code. De oude code is daarmee 'dood'.
	* in de tijd die nodig is om je 't eigen te maken hebben anderen de voorsprong genomen en bieden dezelfde dienst als jij goedkoper aan. De 'tweede wet van Schouten' was ooit je voordeel, maar keert zich nu tegen je. Richard zal gaan shoppen. Die is goedkoper uit bij Barry die ook meedoet en graag wil verdienen.
	* we hebben de sourceforge site niet nodig. Ons grote netwerk van contacten zal ons sites en download space aanbieden. Zie daarvoor onze ervaringen met S#S.
	* we hebben domeinen: .net, .org, .biz, .nu.
	* We willen die domeinen gebruiken, voor aankondigingen  over de nieuwe versie, voor publicatie van de adviezen en ook ook voor financiële  activiteiten rond S@S. Deze zijn niet gericht op persoonlijke winst, maar om middelen voor S@S te  verwerven. Dit hoeft niet alleen geld te zijn. We hebben veel goodwill wereldwijd.
	* Siteatschool.nl heeft weinig bijgedragen aan versteviging van de banden.  We proberen jou buiten schot te houden, maar dat doen we zeker niet naar Richard toe.
	* Je gaat zelf de veiligheidsproblemen oplossen en brent een nieuwe versie uit. Prima! Moge de beste winnen. 

3. De oplossing: 
Fred doet volledig, vol overtuiging en zonder enig  voorbehoud mee met de nieuwe code en doet daarvoor wat nodig is. Een opsomming die niet compleet is:
- Snel contact met ...[naam verwijderd, DS] zoeken en zeggen dat je 100 % meedoet en  je volledig achter de rewrite staat.
- Je verdiept je in zaken, leert en wordt beter als coder en als
professioneel OSS ontwikkelaar. Dat is jouw belang als je binnen S@S als ontwikkelaar wil blijven functioneren.
- Deelnemen aan overleggen met een constructieve opstelling. 
- Andere ontwikkelaars mee laten werken aan het project.
- Wachtwoorden worden gedeeld door ontwikkelaars en S@S team, CVS moet open en wat er verder nog nodig is voor de nieuwe code. Wij moeten ook de site kunnen aanpassen, net zoals we dat nu doen met siteatschool.sourceforge.net.
- Je naam als main developer kan op de site blijven staan. Wij weten wat het voorstelt. Dat hoeven anderen niet te weten.

Dit is het bericht dat we willen publiceren in forum, BIC, persbericht, website, etc.: 
------------
Esteemed Site@School user,

In the summer of 2006 many Site@School sites were
hacked and/or defaced. In the same summer a Site@School site was replaced with a phising site for VISA. Security issues were fixed.

The team took the matter very serous and consulted two professional
security experts. Both came, independently, to the same conclusions:

- In a couple of years it will be impossible to maintain the code and
guarantee security to schools, for example for stuff on the  intranet.
- To solve future problems the code needs a complete rewrite.

This is an enormous task that will take too much time from our volunteer developer Fred who also has a fulltime job and a family. 
The S@S team decided to hand this job to specialised, professional security  coders who will do the job for a modest fee. We do our utmost to release the new version on the scheduled date, i.e. end 2007. Donations are welcome.

It is the teams conviction that this is the best guarantee that Site@School will remain the best and the securest primary
school CMS for years to come.
The Site@School Development Team,
Dirk, Fred, Karin.
----------
Uitleg: de user base informeren en geruststellen, positief nieuws brengen, nadeel ombuigen tot voordelen,  we geven je alle eer, we doen aan damage control, we kunnen adverteren met de verbeterde veiligheid, fondsen werven, etc.


4. Aan jou de eer.
- meedoen, dan kun je wat betekenen.
- niet meedoen:  blijf zitten waar je zit of niet. 't  Maakt ons niet uit. 

Wat wij willen:
Voor donderdag 12.00 uitsluitsel per e-mail. Tijdsdruk in verband met de BIC en 't Forum. Als je wat stuurt, stuur het dan voor de zekerhied naar  Karin, mij en de obsrb info. Dat hebben we de zekerheid dat het aankomt.
Als we niks ontvangen ook goed. Up to you.

Zoals je ziet zijn we zeer loyaal aan je en proberen we over je hoofd heen te schieten.

(top)

13. Our own forum stolen and our project hostaged

We received the following mail from Fred (header trimmed): 

Date: Wed, 31 Jan 2007 20:04:58 +0100
From: Fred Stuurman 
To: Dirk Schouten 
	Karin Abma 
Subject: aanbod


Karin, Dirk,
Ik bedank voor de eer.

Groet Fred
--

Fred thanks for the honour. As we interpreted this message: Fred decides to leave the team. We asked Fred to give us root access to the Sourceforge site. He refused. At that moment Fred was the only project admin, so in total control. Fred refused to make Peter and Barry project admin.
A long email exchange followed:

Date: Tue, 6 Feb 2007 08:50:49 +0100
Date: Tue, 06 Feb 2007 20:15:21 +0100
Our principal offers to mediate between Fred and Karin,Dirk.
Then a mail from Fred arrives (header trimmed): 

Date: Wed, 14 Feb 2007 14:19:57 +0100
From: "Fred Stuurman"
To: "Karin Abma" 
	"Dirk Schouten"
Subject: S@S team

Beste Karin en Dirk,
Gezien de ontwikkelingen van de laatste maanden in het S@Steam,
heb ik besloten geen deel meer uit te maken van het Site@school team 
en ik ben een eigen sourceforge project begonnen.
Na een overgangs periode zal ik het gehele sourceforge Site@School project aan jullie overdragen.

Ik zal Peter en Barry opvoeren als members van het project zodat ze CVS kunnen gebruiken.
(hiervoor heb ik hun sourceforge gebruikersnamen nodig) 
Na de overgangs periode zal ik ze project admin maken en kunnen ze mij "admin af" zetten en zal ik mijn
sourceforge gebruikersnaam verwijderen van het project.

In de overgangsperiode wil ik op de  http://siteatschool.sourceforge.net een "tussen scherm" met
hierop mijn beslissing om een nieuw project te beginnen en jullie verhaal over jullie 
beslissing om S@S te herschrijven. Die tekst moeten jullie me maar aanleveren. 
Hierop twee links, een naar mijn project site en de andere naar de homepage van Site@Scool zelf.

Ik zal zelf in het forum een posting doen, zie hieronder.

Groet Fred

------------------------
Forum: 

Esteemed S@S users,
I have decided to to leave the S@S development team because within the team there is disagreement
on the future on how to continue with the S@S project.
How the future of S@S will be, is best that Dirk or Karin explains that to you. 

I have created my own sourceforge project http://sourceforge.net/projects/syndeocms
and will continue to work on the 2.5 version of the CMS as I have been doing the last couple of months. 

If you want my support on S@S 2.4.10 you need to visit a new forum which I will create on
http://www.syndeocms.org .

Kind regards Fred Stuurman. 

------------------------

Groet Fred

Hm, we are held hostage. Fred wants to keep total control. At the same time we get a test message from the Syndeo CMS forum. Fred has copied the complete contents, usernames, passwords from our forum! That is computer related crime by Dutch law.
At about the same time (the fourteenth of January 2007 ) you could read on the Syndeo CMS homepage:

"Syndeo CMS is the follow up of the Site@School cms."

This is a lie. We were very angry. We were really hostages. Fred was in total control. On the 17th of February a developer that wanted to take part in the rewrite of the code said goodbye to the team. He found the matter with Fred a threat to his good name. So, due to Fred's acts we lost a very professional developer. Thsi really made us angry.

14. Latest developments

On the 20th of February our mediator receives a mail from Fred which he sends to the team: 

[Mediator name removed],
Na ons telefoon gesprek hier de beloofde email.

De project pagina http://sourceforge.net/projects/siteatschool/
heeft een link naar de homepagina van Site@School : http://siteatschool.sourceforge.net/

Wat ik wil is dat als een bezoeker vanuit de de projectpagina op project->webpagina klikt dat hij/zij 
een tussenscherm te zien krijgt waar op staat dat het project team besloten heeft twee verschillende wegen 
te gaan en hierop een link naar mijn nieuwe project en uiteraard een link naar de huidige homepage van site@school.

Ik heb Barry, Peter en Karin reeds "members" gemaakt van het site@school project zodat ze CVS kunnen gebruiken. 
Dit CVS systeem wordt door ontwikkelaars gebruikt om de project code te kunnen delen. (dit hebben ze in ieder geval nodig)

Op 1 juli 2007 zal ik iedereen project admin maken en dan kunnen ze mijn gebruikersnaam admin "af" zetten 
en zal ik m'n gebruikersnaam verwijderen van het projekt.

Mijn motivatie is dat ik vind dat ik 4 jaar meer dan 100% me heb ingezet voor Site@School en dat op deze manier
een beetje recht gedaan wordt aan die inspanningen. 

Ik hoop dat het zo duidelijk is en anders hoor ik het graag als dat niet zo is.

Groet Fred Stuurman

The mediator asks our opinion about Fred's propositions. Opinion:

The mediator is a great help, and again, to make a long story short, after some email exchanges, he archieves the following: 

Date: Thu, 1 Mar 2007 09:05:55 +0100
From: "Fred Stuurman"
To: "Karin Abma",
	"Dirk Schouten"
Subject: S@S


Beste Karin en Dirk,

Ik vind het _niet_ moeilijk om mijn fouten toe te geven, jullie hebben daar duidelijk wel moeite mee.
Daarom heb ik mijn forum aangepast en alle orginele postings en gebruikers die uit het S@SUS forum kwamen verwijderd. 

Ik vind het jammer dat jullie alleen maar oog hebben voor jullie eigen gelijk en standpunten
maar het zij zo.
Ik had het sourceforge project nog heel lang kunnen vast houden maar zo zit ik niet in elkaar (gelukkig voor jullie) .

Daarom wil ik er nu een punt achter zetten en heb ik jullie vandaag project admin gemaakt.

Ps. Lichten jullie de "directie" in. 

-- 
Groet Fred

Syndeo CMS : Opensource Content Management Systeem for schools. 
http://syndeocms.sourceforge.net

The hostages are released and have to be gratefull too. What Fred writes is: "I could have hold the sourceforge project for quite some time but I'm not that kind (lucky for you)"

We can only repeat what we said in the beginning of this long story:
Our personal opinion on the whole matter? Unprofessional behaviour for a project admin and main developer. And that's all we shall opiniate about the matter.

15. March 8, 2007. Case closed

On the 7th of March, we write: 

Fred,

Als beloofd komen wij terug op enkele zaken die nog aandacht behoeven. Het betreft de gemaakte cursuskosten en de naleving van het copyright op het manual.

Je hebt op onze kosten een cursus bij Pine gevolgd. Daar heeft het project Site@School de vruchten niet van kunnen plukken omdat je uit het project bent gestapt. Het lijkt ons redelijk dat je de gemaakte cursuskosten terugstort. Zou je Euro 589.05 willen overmaken op 'Vereniging Scholen Tezamen Rijk met ICT', postgiro 5155248 te Bussum?

Wat betreft de naleving van de licentievoorwaarden van het Site@School manual. Voor alle duidelijkheid, gezien onze ervaringen met jouw copieer-aktie van ons forum; wil je aan de licentievoorwaarden houden.

Het ga je goed.
Groet,
Dirk Schouten, Karin Abma

Summary: We want two things settled: We would appreciate Fred paying back the costs of the Pine workshop and we want him (lessons learned from the stolen forum) to respect the license rights on the Site@School manual.

And that's the end of the story. We can go back to work: re-design the Site@School code.
One afterthought: It is a blessing in disguise.

 

Authors: Dirk Schouten, Karin Abma <%%AUTHOREMAIL%%>
Last updated: 2007-03-11