#11 CJAN Project Objectives - Security

[Michael Davey]

There have been many good points raised about security
within the replicated network. For example, what if an
unscrupulous person introduced a false server
temporarily on a server node & uploaded 'antisocial' code?

One of the advantages of building something like the
CPAN for Perl is that in Perl all of the source code is
always exposed, not so with Java. Since code will be
distributed in package form, it is possible to access
it from a non-secure environment. What is to stop a
person of malicious intent from introducing
trojan-horse functionality into the library?

Forcing an Open Source license on users is not the
intent of this project. (See LICENSING)

[Nobody/Anonymous]

Logged In: NO

But forcing a digital signature on all contributions is probably reasonable requirement.

Then the trust of the server is almost irrelevant,
and whats more it removes implicit requirements for accountability from server administrators.

Of course this pushes the PKI out of CJAN, but it IMNSHO it only belongs in CJAN in the form of code to implement PKI.

Clearly some consistent approach is desirable so some reasonable policy needs to be set.
My guess is to use a "web of trust" rooted in the initial set of CJAN servers, with digital signatures being added to the categories of material for indexing. [ To stop it being a general key store require that a signature is only accepted if either its linked to the web of trust, or its applied to some accepted (non-sigtaure) material upload. ]

- JonT