Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of mloenko@gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=f4QAkRuOtoyNeLUtyIroIijZT3mowDwYhcxoP5QXd44DrwDcylFf0BWFKEiyWtJhmKTannfnz5xOB9t245fjbe61H0N8yN3Az+0KvZgHhVbNTTGMKU2bzIVgIPjU2Ny9uu5bwyS3mtN5ONa9SrlfEXufMsTWAsO+l5SGyfosjSI=
Message-ID: <906dd82e0706262235r5a0c760pdd522f50d56995a8@mail.gmail.com>
Date: Wed, 27 Jun 2007 09:35:25 +0400
From: "Mikhail Loenko" <mloenko@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][security] BC provider as default Harmony crypto
 provider
In-Reply-To: <30a80d190706262230k6ce958a3mba720760a540c80c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <30a80d190706260521hb16dd6agea67108dea8c10af@mail.gmail.com>
	 <e66844de0706260558p504d5263u95b119d297841e3f@mail.gmail.com>
	 <30a80d190706262230k6ce958a3mba720760a540c80c@mail.gmail.com>

2007/6/27, Roman Bushmanov <roman.bushmanov@gmail.com>:
> Hi, Leo
>
> On 6/26/07, Leo Li <liyilei1979@gmail.com> wrote:
> > Hi, Roman:
> >     I think it is reasonable to grant permissions to classes in extension
> > directory and RI has a similar line in its policy file.
>
> You are right, RI has a statement granting AllPermission to extension
> directory. I've missed that.
>
> However, RI doesn't have the problem with initializing the crypto
> provider then the policy file is redefined complitely. I've seen that
> difference on two tests from functional suite.
>
> Probably they create a provider instance before installing security
> manager, e.g. just before they execute application code. However that
> is not an efficient solution because at vm startup we don't know if we
> need a provider.
>
> >     While I must admit that I have tried to delete this line in policy file
> > for RI 6.0 and there seems to be no problem to get instance from crypto
> > provider, I think it is due to the RI's security provider(SunJCE) does not
> > require some priviledge to work and it is the provider's freedom. (Spec does
> > not forbid providers to do this.)
>
> May be I'm missing something but as I understand, each provider
> implementation (a class extending Provider) should set in its
> constructor a variety properties that are required to look up the
> services implemented by this provider. And the only way to do that is
> calling Provider.put() method that performs security access checs. Am
> I right?
>
> >     And Roman, is there an application fails due to this issue? If so, it
> > deserves us to find a solution.
>
> As I've already noted, I've discovered the issue on two functional
> tests. No other applications.

I suggest to mark this as a non-bug difference from RI

Thanks,
Mikhail

>
> Thank you,
> Roman
>