Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: domain of
 SRS0=Z7Bkd6=OP=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.121 as permitted sender)
References: <517CFD97.4070703@zeus.net.au>
Mime-Version: 1.0 (1.0)
In-Reply-To: <517CFD97.4070703@zeus.net.au>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <302DB712-AE05-43B9-9B3B-A34EFD7AE13A@wonderly.org>
Cc: "dev@river.apache.org" <dev@river.apache.org>
From: Gregg Wonderly <gregg@wonderly.org>
Subject: Re: Status of River 2.3.0
Date: Sun, 28 Apr 2013 09:18:29 -0500
To: "dev@river.apache.org" <dev@river.apache.org>
Sender: Gregg Wonderly <gregg@wonderly.org>

The obvious issue is that Java's Applet Security manager was initially explo=
itable in Java-1.0, because the remote DNS config could be negotiated with, b=
y the applet, to return a local network address so that name based checks wo=
uld allow local network scanning to occur.  We need to make sure we don't op=
en that door, again.

The DNS library services, in Java should keep this from happening, unless th=
e default caching is changed to allow expiration.

Gregg

Sent from my iPhone

On Apr 28, 2013, at 5:44 AM, Peter Firmstone <jini@zeus.net.au> wrote:

> All qa suite tests are now passing
> All jtreg tests that are known to pass are passing (those that depend on a=
 Kerberos Domain server and Squid do not as expected).
>=20
> To address concurrency,the issue of threads starting during service server=
 construction (River-418), a new interface has been created:
>=20
> com.sun.jini.start.Starter
>=20
> Any service that uses the start package can now delay starting of threads u=
ntil construction is complete.  This prevents services from becoming visible=
 to other threads before construction is complete, for compliance with the J=
MM.
>=20
> All services except for Fiddler and Norm have been converted to use Starte=
r, remaining services will be updated in River 2.3.1
>=20
> A JIRA issue for each service will be created to document progress on Star=
ter conversion.
>=20
> Security Infrastructure changes:
>=20
>      1. org.apache.river.api.security.ConcurrentPolicyFile - copied
>         from Apache Harmony and refactored for immutable concurrency,
>         all implies permission checks are performed thread confined to
>         avoid synchronization issues with PermissionCollection
>         implementations.  PermissonCollection's are not shared among
>         threads.  Permissions are granted to Principals and CodeSource
>         signed by Certificate and / or by URI, not URL, this avoids
>         consulting DNS to determine URL identity.
>      2. net.jini.security.policy.DynamicPolicyProvider has been
>         reimplemented.
>=20
>   Changes to Policy.getPermissions(CodeSource codesource) semantics:
>=20
>   The contract for Policy.getPermissions changed in Java 6:
>   <quote>
>=20
>       getPermissions
>       public PermissionCollection getPermissions(CodeSource codesource)
>       Return a PermissionCollection object containing the set of
>       permissions granted to the specified CodeSource.
>       Applications are discouraged from calling this method since this
>       operation may not be supported by all policy implementations.
>       Applications should solely rely on the implies method to perform
>       policy checks. If an application absolutely must call a
>       getPermissions method, it should call
>       getPermissions(ProtectionDomain).
>       The default implementation of this method returns
>       Policy.UNSUPPORTED_EMPTY_COLLECTION. This method can be
>       overridden if the policy implementation can return a set of
>       permissions granted to a CodeSource.
>=20
>       Parameters:
>       codesource - the CodeSource to which the returned
>       PermissionCollection has been granted.
>       Returns:
>       a set of permissions granted to the specified CodeSource. If
>       this operation is supported, the returned set of permissions
>       must be a new mutable instance and it must support heterogeneous
>       Permission types. If this operation is not supported,
>       Policy.UNSUPPORTED_EMPTY_COLLECTION is returned.
>=20
>   </quote>
>=20
>   DynamicPolicy grants are no longer included when
>   getPermissions(CodeSource codesource) is called, instead the method
>   delegates to the underlying encapsulated base policy.
>=20
>   ConcurrentPolicyFile getPermissions(CodeSource codesource) is
>   implemented to return either privileged Permissions (CodeSource's
>   granted AllPermission), or UNSUPPORTED_EMPTY_COLLECTION.   This is
>   purely a performance optimisation, allowing
>   ProtectionDomain.implies(Permission permission) to return early for
>   privileged ProtectionDomain's without consulting the Policy provider.
>=20
>=20
> Changes to ClassLoader infrastructure regarding codebase annotations:
>=20
>  1. URL is no longer used as a Key in Collections.  This changes
>     ClassLoading semantics slightly:
>        1. Codebase annotations will be normalised as URI according to
>           RFC3986 and compared for equality, remote code with
>           identical codebases annotations will share a URLClassLoader.
>        2. Previously codebases with different annotations would share
>           a URLClassLoader if they resolved to the same IP address.       =
     This made firewall traversal and codebase replication
>           difficult and also prevented the use of dynamically assigned
>           IP addresses for codebase servers.
>  2. A new class org.apache.river.api.net.Uri has been provided to
>     implement RFC3986 compliance, it was copied from Apache Harmony
>     and updated to strictly comply with RFC3986.  This new class does
>     not support Serializable and is final and immutable.  It can be
>     serialized in it's string form and reconstructed remotely by
>     passing a string to its constructor.   It has identical method
>     signatures to java.net.URI.  Originally java.net.URI was utilised,
>     however while it implements RFC2396 and RFC2732, it doesn't
>     strictly comply and allows additional characters that should be
>     escaped in RFC2396, this means that a strictly compliant RFC2396
>     URI in normalized for may not be equal to a java.net.URI.  In
>     addition java.net.URI didn't support escaped characters in host
>     names, which would prevent registered domains from some Locales
>     from being used in codebase strings.
>  3. URL and URN are both URI, previously only URL's were legal, so the
>     expanded form also allows URN to be utilised legally as codebase
>     annotations, this includes Rio's maven artifact URN scheme.
>  4. PreferredClassLoader no longer lazily loads the preferred list,
>     instead this is loaded during construction.
>=20
> While these seem like huge semantic changes, the end result is codebase an=
notations will still resolve to their correct ClassLoader as they always hav=
e, but instead of using DNS to determine an IP addresses (in the case of htt=
p and httpmd URL's), identity will be based on the RFC3986 normalized form o=
f the codebase string.  The ClassLoader will still use URL providers for res=
olving codebases.  For the real oddball case, where a developer expects thre=
e separate domain codebase annotations to resolve to the same IP address and=
 use the same ClassLoader, that won't work anymore.
>=20
> This won't be rushed out the door, plenty of time will be allowed for test=
ing.
>=20