CAcert System Admins discussion list

[Ian G <iang AT cacert.org>]

Hi Ulrich,

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

On 29/07/10 12:31 PM, 
ulrich AT cacert.org
 wrote:
> Dear Arbitration Participients,
>
> Regarding Arbitration case a20090427.2
> https://wiki.cacert.org/Arbitrations/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 ==
>
> Recomendation:
>
> 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
>     authority


(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.)

> Advantages:
>   * 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
> receivers

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
> locations
>     database set is under control
>
> CAcert developers can send a simple request to the Software-Assessment
> team
> 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
> to
> give notification to the requestor, that the database set can only be used
> for CAcert purposes. No transfer to other projects, allowed.


OK.

> 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
> limited
> access point thru one or more possible and applicable services (i.e. ftp,
> http,
> 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



iang

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