Perhaps we should sign our proxy jar or *-dl.jar files?
While this doesn't eliminate the complexity of using codebase downloads,
it would allow DownloadPermission to restrict class loading to trusted code.
You can use secure discovery to require a registrar to authenticate
itself and use secure channel communication, but you would need to own
the registrar to restrict services registered only to those that can
authenticate.
If you don't own the registrar you don't know if you can trust the
decisions made by its administrator. In that case the only way to
restrict proxy's received from the registrar is to require
DownloadPermission to restrict proxy's to either reflective proxy's or
trusted signed code. Doing so, also restricts the registrar codebase,
so signing our proxy jar's would allow sharing between djins.
Code signing is location independent.
Signing all our code artefact's could be problematic for some developers
who might use package private access, although that is discouraged.
Cheers,
Peter.
Peter Firmstone wrote:
It's the way Entries are separately serialized.
Yes you're right.
Peter.
Dan Creswell wrote:
Depends what you call a platform service but at least in the case of
both Registrar and JavaSpace the ability to custom serialise on the
client and avoid leaking classes into the server-JVM makes reflective
proxies a non-starter.
On 22 January 2012 01:29, Peter <[email protected]> wrote:
Easy to develop & secure - no proxy codebase required.
No classloading issues.
No class version issues.
The more I think about it, code sharing, whilst a powerful feature,
should be limited to trusted parties who have signed their code, or
have their own registrar that uses secure discovery and requires
authentication.
If the platform only used reflective proxy's for services, River
would be far easier to deploy for new developers.
Has anyone previously looked into why we need smart proxy's for
platform services and what we'd lose if we only used reflective
proxies?
Cheers,
Peter.
