Before: Arbitrator BernhardFröhlich (A), Respondent: None, Claimant: Eva S. (C), Case: a20150114.2

Contents

  1. History Log
  2. Private Part
      1. EOT Private Part
  3. Original Dispute (anonymized)
  4. Discovery (Public Part)
  5. Deliberation
    1. Concerning notification mailing
    2. Considering Audit Incident i20150115.1
      1. Cause of Incident
      2. Process of installing the patches
      3. Emergency Actions taken
      4. Summary
  6. Rulings
    1. Ruling concerning notification mailing
    2. Ruling considering Audit Incident i20150115.1
  7. Execution
  8. Similiar Cases
  9. Footnotes

History Log

Private Part

EOT Private Part

Original Dispute (anonymized)

Discovery (Public Part)

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.2

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 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 SP 7.4.

SP does not define who may notify Critical Admins of the fact that a bug fulfils the requirements to be installed3. 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. 4

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.5

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.6

Rulings

Ruling concerning notification mailing

Following the deliberations above I rule that a mailing to notify all users affected by 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 Security Manual. It is considered appropriate that the following data of affected users may be extracted from the database to allow the mailing:

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

a20140728.1

notification mailing to all members for CCA

Footnotes

  1. The claimant did not address a party, not even an unknown party, none could be identified during the Arbitration and no actions are considered necessary. So DRP 1.4 Bullet 2 does not apply. IMHO the dispute was more or less a request to furnish an opinion on the subject, so the claimant can have some confidence that her intended actions are covered by CAcert policies. (1)

  2. Note that there is at least a theoretical alternative to a mailing, if the CCA might apply to different users in different versions. Since we currently don't have the technical prerequesites, and it seems that noone wants to go this way, I did not examine this variant more closely. (2)

  3. The Procedure on Software Patches describes a procedure which is obviously considered the default procedure and should be followed under usual circumstances. But it is not described as the only allowed procedure. (3)

  4. Note that if the statement was "The bug was reviewed successfully by two Software Assessors and therefor is ready to install" the notifyer is not responsible for errors made by the Software Asessors. But, depending on the situation, s/he may be responsible that the reviews were made and there's no veto from the team leader. (4)

  5. I would have preferred the term "suggest" over "order", but for the case this is quite irrelevant (5)

  6. This is in contrast to the first part of the case, which may only be appealed according to DRP 3.4 (6)

Arbitrations/a20150114.2 (last edited 2015-03-17 22:00:22 by BernhardFröhlich)