Skip to Content.
Sympa Menu

cacert-devel - Re: Arbitration case a20090427.2 - "Ad hoc SQL query requested (locations database export)"

Subject: CAcert Code Development list.

List archive

Re: Arbitration case a20090427.2 - "Ad hoc SQL query requested (locations database export)"

Chronological Thread 
  • From: Ian G <iang AT>
  • To: cacert-devel AT
  • Cc: ulrich AT, gstark AT, 'Philipp Gü hring' <philipp AT>, 'Markus Warg' <markus AT>, 'dirk astrath' <dirk.astrath AT>, 'Wytze van der Raay' <wytze AT>, p.dunkel AT, 'Andreas Bäß' <andreas.baess AT>, 'Michael Tänzer' <michael.taenzer AT>, mario AT, cacert-board AT, cacert-sysadm AT, aphexer AT
  • Subject: Re: Arbitration case a20090427.2 - "Ad hoc SQL query requested (locations database export)"
  • Date: Thu, 29 Jul 2010 14:37:19 +1000
  • Authentication-results:; dkim=pass (1024-bit key) header.i= AT; dkim-asp=none

Hi Ulrich,

speaking perhaps from pov of board, but not as board.

On 29/07/10 12:31 PM, 
ulrich AT
Dear Arbitration Participients,

Regarding Arbitration case a20090427.2

I'll today publish a recomendation "Solution I"
that has a couple of advantages, but needs to be accepted
by the teams first as a pre-step for the ruling in this case.

To your information:
There is a limitation set over the locations database set
              "for CAcert usage only"

*Property* As far as I know, this is a claim that has been verbally stated by someone, so I would question whether we have a reliable understanding of that. I'm also uncertain as to whether we should accept on face value any such claim, as it has quite important ramifications. Some questions... to establish any facts:

Has the Arbitrator managed to clarify the nature of the intellectual property claim and the nature of the licence that we have (verbal or implied or otherwise) ?

If NO to the above, is the Ruling likely to include a statement that clarifies the licence for us? By dictat, as it were?

Those are questions to establish facts, here are my thoughts:

This Community has always preferred open source. It's not always possible to arrange this, but there is a sense that it should be the case for all the critical domain software. Indeed, audit criteria establish strong control provisions over our critical assets, which tends towards us needing either full ownership or control established under a strong licence (aka, agreed open source licence).

The current location database doesn't seem to fit that ... even though we can recognise that when it was first given to us, the nature of its usage and provision might have been a good thing, and we're grateful for any help.

Things have moved on from then, I suspect. In practice, we have google earth and other open alternatives. Also, BirdShack team advanced the theory that the location database did not need to be in the critical domain at all. Sure, it was there for convenience of coding when Duane had one website and that was it. But we are a bit bigger now; we have a lot of separated platforms, and we want a tight CA. We have a track record in Client Certs and we'll push that more....

So, BirdShack decided that the best thing to do would be to kick the location database out of the critical domain, and suggest some sort of infra or community tool. Leave that up to the others.

== Discussion ==


To move the authority over the locations database set
to the Software-Assessment team and turn the distribution
order from live system to the outside to
Software-Assessors to live system

In this sense, giving the Software Assessors some sort of control over the location database strikes me as perhaps going in the other direction. In the past, SEs just added anyone as location administrator after doing some informal due diligence.

(Correct me if I'm wrong here, I haven't looked up how it is done.)

Now it is to be controlled as if software?

- I would speculate that the location database is really a database, not a source code file, so it complicates the distribution goes. (Same commment has been made about policies! :)

- Are the database fields part of the main database? Does this mean that a software distro from the Software Team is now going to include data components?

- There is the practical issue that software changes are generally a long cycle, compared to SE changes which are short. OK, both could be quicker, but at least simple SE changes like this can be done within a week.

a) Updates onto the Locations database can be tested
    thru the Software-Assessment team

What is there to test? Either some town is in the right place, or not? Is this really a critical issue?

b) Export requests can be handled by Software-Assessors

(I'm happy with that authority being handled by any of the critical teams, the Board/officers, or the Arbitrator. But I also think it could be handled by anyone who's an Assurer and has a manual on how to do it... e.g., a year ago, we stopped the Board from approving any maillists or email addresses, it's just too much bureaucracy.)

  * Requests from CAcert developers can be easily handled
    without first building a framework to handle this request
  * Updates to the locations database are under Software-Assessments Team
    authority and can follow the Software-Assessment procedures for updates
  * Updates can be send easily to connected CAcert developers update

I'm unclear to me why this would be an advantage. As a programmer, the last thing I'd want to do is deal with ... data updates. But perhaps I'm missing something?

  * recuring updates are no longer needed to be transfered from the
    critical system, as the main repository is under authority of the
    Software-Assessment team. Updates will be sent from Software-Assessment
    team to the critical system
  * Software-Assessment team is also under control of CAcert so the
    database set is under control

CAcert developers can send a simple request to the Software-Assessment
to get the locations database for development purposes. Also other teams
of CAcert (Board, Arbitration, Infrastructure) can request a copy of the
locations database set for CAcert usage. The Software-Assessment team have
give notification to the requestor, that the database set can only be used
for CAcert purposes. No transfer to other projects, allowed.


The transfer format of the locations database set is not limited to
a special format. It can be transfered within an CAcert developers image,
as sql-dump or whatever else format.
The only limitation is, that the download links aren't publicy available
and access is secured, so that a requester needs download infos from
the Software-Assessment team by either Account/Password combination and/or
a hashkey URL and/or an ACL secured access point and/or a client cert
access point thru one or more possible and applicable services (i.e. ftp,
or other services)
An initial complete export from the critical system to the
Software-Assessment team is allowed to receive the current state of
the locations database set. Critical team and Software-Assessment team
have to deploy a transfer concept for the initial transfer.


please comment on the recomendation, if this is a usable
and acceptable solution

I want to get answers from:
  1. Claimant
   and the following teams:
  2. Software-Assessors
  3. Software-Assessment Project
  4. Critical Sysadmins

   and probably others to comment on
  5. board

Speaking from pov of Board, but not as board: I am keen to establish just exactly what this licence is (implied or otherwise). The natural party to the licence is the Board as representative of CAcert Inc. Although we might vary that, convention pushes us in that direction.

Also, I and others have worked hard to get out of these particular difficulties created by "special contracts". E.g., CCA 1.3, PoP 6.2, past decisions from Duane to transfer the IPR to CAcert Inc, audit argument over old CPS as owned by another party.

So I would be hoping for any decision that takes us further along that path. As a principle, we want control of our own location database if it is part of the critical system, *OR* we move it out of the critical domain.

  6. developers


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

Archive powered by MHonArc 2.6.16.

Top of Page