* Case Number: a20150114.2 * Status: running * Claimant: Eva S. as CAcert Policy Officer * Respondent: None <> * initial Case Manager: BernhardFröhlich * Case Manager: MartinGummi * Arbitrator: BernhardFröhlich * Date of arbitration start: 2015-01-25 * Date of ruling: 2015-02-16 * Case closed: 201Y-MM-DD * Complaint: Wrong version of CCA on website * Relief: None Before: Arbitrator BernhardFröhlich (A), Respondent: None, Claimant: Eva S. (C), Case: a20150114.2 <> == History Log == . 2015-01-14 (issue.c.o): case [s20150114.136] . 2015-01-24 (iCM): added to wiki, request for CM / A, added link to audit incident . 2015-01-24 C sends statement concerning the case to iCM, currently part of the private page . 2015-01-25 A sends initial Mail . 2015-01-25 Ruling concerning notification mailing is given . 2015-01-25 (A): Notified C about ruling. . 2015-01-26 (A): Proposed ruling for second part given . 2015-01-26 (A): Notified C about proposed ruling. . 2015-01-27 Statement by C about proposed ruling received. . 2015-02-08 (A): Some modifications and clarifications made to the deliberation for the proposed ruling, inspired by C's statement . 2015-02-16 (A): Ruling for second part given . 2015-02-16 (A): Notified C of ruling. == Private Part == * '''Link to Arbitration case [[Arbitrations/priv/a20150114.2|a20150114.2 (Private Part)]], Access for (CM) + (A) only''' ## ==> INCLUDE SECTION BOT <> ## <== INCLUDE SECTION EOT ==== EOT Private Part ==== == Original Dispute (anonymized) == {{{ Hello, I have to file the following dispute. Yesterday, when I wanted to test the bug 1345 which should install the voted on current POLICY version p20141008 from the CCA I took a look at the CCA that is displayed by our website (originally to compare the version on the test server against it). By doing so I found that there was an old POLICY version of p20080109. But there should be the DRAFT version from p20140709. I was told by software and critical team that the new version of p20141008 should be installed within the next days, so I treat this as if it would be fixed, by now. The dispute has two parts. a) inform the user who have accepted the CCA on the website since the wrong version was re-installed about the correct version. b) maybe check why the wrong version was installed and if this should lead to further actions. I am not sure, if the second part is needed, but as I also may have been involved I do not want to decide about this and added it here. I am also considering to ask the auditor to treat this as an incident, so it may be handled through this. As Policy Officer my actual focus has to be in a), as I am responsible in this regard. This point has a high urgency, as we have to be sure that our user accept the (correct) CCA. For everybody who has accepted the CCA the first time when the wrong document was there we cannot assume, that they have accepted the CCA as we understand it. So we have to inform them that there was an error and that there is another version. We should treat this comparable to how the other users were informed about the new CCA version so that they have a time frame to cancel their membership and if they do not do so, we can then assume that they have accepted the correct CCA, as well. All members who have accepted the CCA but had accepted it previously have agreed to the new version, before, but they should also be informed about the mistake, as they may have read it and may be confused about the correct version, afterwards. This should be done within a short time after a correct version is installed again. I am not sure if a special authorisation from arbitration is needed for this, as it is a comparable action to the CCA update mailing where there was no reason for an according authorisation, but I am not sure about this. If this part of the case is not handled within days I will try to do the described kind of information with other authorisations (either board or I will try it as PolO). However I would prefer it in the context of this case. So please treat this part of the case as urgent! I will give a recap about known dates, in another mail when there is either a support case number or arbitration case number for a follow up mail. }}} == Discovery (Public Part) == * The case consists of two parts, only the part on the notification mailing is considered as urgent. The second part consists of an evaluation whether more investigation about [[Audit/Incidents/i20150115.1|Audit Incident i20150115.1]] is necessary. * [[https://www.cacert.org/policy/CAcertCommunityAgreement.html#3.4|CCA 3.4]] includes the sentence "Changes [to the Community Agreement] will be notified to you by email to your primary address". The same sentence is included in both versions of the CCA. * Mail from C to iCM sent 24.01.2015 21:44 (GMT+1) (removed parts which were not considered relevant for the ruling): {{{ Hello, I have some additions about that case. 1. I disagree with what was said by the person who initiated the incident that was linked to this arbitration case on multiple levels. The internal Auditor who is managing that case is informed about that. I even have issues by him entering the case at all - as may have the internal Auditor by now, at least there was an according mail he send in a mail that was between board, him and me as PolO. So please be careful to rely on that incident. Here a summary about a) history of events (pre and post dispute) b) what lead to the dispute c) polices that may be relevant in this case d) things that I already proposed for the according teams (you probably know them already because of other roles you have within CAcert) a) history of events (pre and post dispute) --------------------------- There are 3 bugs that are relevant [... see details in bugtracker ...] [1] https://bugs.cacert.org/view.php?id=1131 [2] https://bugs.cacert.org/view.php?id=1293 [3] https://bugs.cacert.org/view.php?id=1345 I added some times, because the timing was the relevant thing in this case. Here a history of the relevant dates: 2012-12-21 bug 1131: was filed to replace all policies that had a .php format by .html versions as the PoP requires this. A lot of work happened until about 2013-09-17, where it stalled for a long time. The original set of files probably included the CCA 2014-07-29 bug 1293: was filed because PolG had finished a vote to a DRAFT CCA version - this bug contained the CCA file 2014-08-29 bug 1293: was installed and closed later. 2014-09-16 bug 1131: 11 policy documents were replaced because PolG finished a vote to move them to POLICY status - CCA was not included - it was handled already by bug 1293 and later bug 1345 2014-12-13 bug 1131: reached needed test and review status 2014-12-13 bug 1345: was added because PolG had finished a vote to POLICY of CCA (and PolO had decided to add an editorial change) [Software Asessor 1] tried to merge the bug 1345 to the testserver but encountered merge issues with bug 1131. 2014-12-16 bug 1131: - Those issues were resolved and reviewed by [Software Asessor 1] - Two tests were done by comparing changes with wot/6 - not clear WHAT was compared 2014-12-27 bug 1131: - final review 2014-12-31 bug 1345: merged to testserver, tests and reviews started - this contained a CCA file, again 2015-01-06 bug 1345: a failed test for this bug was done by me as PolO by comparing the version of the CCA on the testserver with that on the main website 2015-01-08 bug 1131: installed 2015-01-13 bug 1131: I checked all those policies that I thought would be moved by bug 1131 to the website while updating the COD-list as PolO. I did not check the CCA as I was not aware that it could be changed by bug 113 2015-01-13 bug 1345: a test for this bug was done by me as PolO. I wanted to do the same steps and found that the version on the main website was now wrong. This was during the software telco and I told the people there about the issue. [Software Asessor 1] asked me to contact crit with a request to fix this issue, ASAP. I (as PolO) send an according mail to critical, including the information that bug 1345 had probably got the needed test and review status and if it would get the ok by the software team that maybe it should be used to fix the issue. Critical team answered that they wanted to wait for bug 1345, then. [Software Asessor 1] told me that I was not allowed to write such a mail. 2015-01-14 - I filed this dispute and called the Auditor if an incident would be needed (we agreed that it would not help), I previously had informed [Software Asessor 1] that I would file such a dispute - [Software Asessor 1] filed the incident without mentioning my mail. 2015-01-15 - intenal Auditor: orders critical team to install the new version - critical team install new version Afterwards there was a lot of discussion and mails between different groups mostly about who may do what and who may initiate such a mail. Especially since it took so long until this case was picked up, even as it is really urgent, as also the internal Auditor has found. If needed I can provide a summary but only some of them (some positions on PolG) may be relevant. }}} == Deliberation == === Concerning notification mailing === Members who have created a new CAcert account while the outdated version of the CCA was online are in the same situation as members who created their account before the current CCA was first put online. Therefor CCA 3.4 explicitly requires that those members have to be notified by email of the current version. For other users, who have accepted the "wrong" CCA more implicitly, by entering an Assurance or creating a new certificate, the situation is not this obvious. Most of them will not have checked the CCA at that time. But from the policy point of view there's not much difference for them. Therefor a notification of those users is required, and thereby authorized by the CCA.<> It seems somewhat natural that the mailing will be under the auspices of the Policy Officer, as the manager of all policies, laid down in [[https://www.cacert.org/policy/PolicyOnPolicy.html#s1.4|PoP 1.4]]. But as the mailing is authorized directly by a policy this is not necessary, it may be organized by every member of CAcert. === Considering Audit Incident i20150115.1 === I had a look at the events related to the incident, since I got the impression that there are some disagreements about the processed applied in relation of the Incident. My analysis is based on the !WiKi page of the Audit Incident and C's mail sent 24.01.2015 21:44 (GMT+1). There was no verification of the facts presented in those two sources, since there was no reason to distrust any of them. Several areas have been examined: ==== Cause of Incident ==== The incident was caused by a slight fault in the software development process. Several loosely related bugs/patches created an interference. The interference might have been detected by closer inspection of the relations between the cases, but since no such interference was anticipated it is understandable that no closer inspection was made. I see no need for any Arbitration Ruling in this aspect, beside "strive to become better". As reported the fault has already been analyzed by the development team making a corresponding ruling unnecessary. ==== Process of installing the patches ==== It seems that there was some discussion about who's allowed to send mails in the development process. As it is presented by C the bugs were successfully tested and reviewed, as intended by the Security Policy. This fulfils the requirement of being "signed off" according to [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html#s7.4|SP 7.4]]. SP does not define who may notify Critical Admins of the fact that a bug fulfils the requirements to be installed<>. Regardless of who sends the notice, Critical Admins should verify that the requirements are fulfilled by suitable means, for example by checking the bugtracker. Of course the sender of the notification nevertheless takes some responsibility, and may have to face consequences if it turns out that the notification was not justified. <> ==== Emergency Actions taken ==== As reported, the "emergency actions" did not disregard the development process. The error did occur very late in the process, the error was corrected by a corrected packaging of the patch and letting it be applied by Critical Admins. So the standard process was followed, and no Emergency Actions have to be reviewed and confirmed by Arbitration. There seem to be some discussions about whether the internal Auditor was allowed to order the installation of the corrected patch.<> According to the reported process the corrected patch was created according to the procedures laid down in the Security Policy. Therefor it is not relevant who "orders" the patch to be installed, since the procedures were followed. The reasoning might be a different if the action ordered was a real Emergency Action (disregarding procedures because of urgency), but in this case an Arbitrator has to review the actions anyway. ==== Summary ==== As laid down above I came to the conclusion that currently no Arbitration action is necessary. But since the analysis was not explicitly requested by the dispute I did not evaluate this part of the case to the last. Most important I did not verify the stated facts concerning correctness and completeness. So if anyone states that there are additional facts to be evaluated, or that facts presented are not corect he or she may do so by filing a normal dispute.<> == Rulings == === Ruling concerning notification mailing === Following the deliberations above I rule that a mailing to notify all users affected by [[Audit/Incidents/i20150115.1|Audit Incident i20150115.1]] is required, and thereby authorized, by the CAcert Community Agreement (CCA). SQL queries to identify the affected users in the main website's database are authorized, within the regime of the [[SecurityManual#SOFTWARE_DEVELOPMENT|Security Manual]]. It is considered appropriate that the following data of affected users may be extracted from the database to allow the mailing: * personal name (to allow a personal adress in the mail) * primary email address (the target address for the mail) * dates of wrong CCA acceptances (to allow some specific explanation to the user) * reasons of CCA acceptances (Account creation, Assurance, Certificate creation, maybe other reasons. This is also to allow a specific explanation to the user) More data (like record ids) may be selected if necessary for technical reasons, but should only be made accessible to Critical Admins. The details of SQL queries, as well as the details of mail texts are not part of this ruling and left to the discretion of the involved teams. Munich, 2015-01-25 === Ruling considering Audit Incident i20150115.1 === Based on the facts presented I rule that no further actions are considered necessary for Audit Incident i20150115.1 Munich, 2015-02-16 == Execution == N/A == Similiar Cases == || [[Arbitrations/a20140728.1|a20140728.1]] || notification mailing to all members for CCA || == Footnotes == <> ---- . CategoryArbitration . CategoryArbCaseSystemTasks