On 7/8/14, 5:33 PM, Valerie Peng wrote:
I modified the ProviderConfig class to skip providers when the
corresponding provider class failed during initiation time (e.g. lacking
certain permission). Thus, for tests which do not need/use crypto
providers, their test policy don't have to contain the
I modified the ProviderConfig class to skip providers when the
corresponding provider class failed during initiation time (e.g. lacking
certain permission). Thus, for tests which do not need/use crypto
providers, their test policy don't have to contain the entries for
crypto providers.
Than
Looks good, although do you know why you were able to remove the grant
AllPermission from so many of the test policy files without granting
additional specific permissions?
--Sean
On 07/07/2014 05:14 PM, Valerie Peng wrote:
Updated the webrev to include the updates of test policy files.
Also
When looking through the code and running regression tests as well as
some of my own sample programs, SunPKCS11 needs permission to access
"sun.security.pkcs11.allowSingleThreadedModules" property.
As for other providers, they seem fine without the PropertyPermission.
But the required permis
Hi Valerie
I didn't read your previous webrevs, but why is "permission
java.util.PropertyPermission "*", "read";" needed by every provider? I go to
sun/ec, sun/pkcs11, com/sun/crypto and find no special System.getProperty()
calls there.
Thanks
Max
On Jul 8, 2014, at 5:14, Valerie Peng wrote
Updated the webrev to include the updates of test policy files.
Also changed the ProviderConfig class to ignore provider instantiation
failures, so that we don't need to include the entries for crypto
providers in the test policy files when the tests themselves do not
use/depend on functionali
Updated the webrev in place (still at webrev.01), now that Mandy has
putback'ed her fix for the ClassLoader.loadLibrary issue.
Thanks,
Valerie
On 6/20/2014 3:30 PM, Valerie Peng wrote:
Webrev is updated at:
http://cr.openjdk.java.net/~valeriep/8043406/webrev.01
Sure, I will file a bug aft
Valerie,
On 6/20/14 4:57 PM, Mandy Chung wrote:
Yes please file a bug and it does look like a bug in the loadLibrary.
I'll look into it. It'd be helpful if you can include a stack trace
in the JBS issue without granting FilePermission to access all files.
I have a patch and going to send
On 6/20/2014 3:30 PM, Valerie Peng wrote:
Webrev is updated at:
http://cr.openjdk.java.net/~valeriep/8043406/webrev.01
Thanks Valerie. Good to see the security providers granting only the
permissions it requires.
Looks okay to me.
Sure, I will file a bug after Mandy's confirmation.
Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8043406/webrev.01
Sure, I will file a bug after Mandy's confirmation.
Thanks,
Valerie
On 6/20/2014 8:46 AM, Sean Mullan wrote:
36 // Needed by Runtime.loadLibrary(String) call
37 permission java.io.FilePermission "<>
36 // Needed by Runtime.loadLibrary(String) call
37 permission java.io.FilePermission "<>", "read";
It seems like this is due to a bug in Runtime.loadLibrary, since you
have already granted the provider the permission to load the library. I
think possibly the call to ClassLo
Sean,
Not sure if you can get to reviewing this before your vacation.
If not, I will find someone else to help...
Webrev: http://cr.openjdk.java.net/~valeriep/8043406/webrev.00/
Thanks,
Valerie
12 matches
Mail list logo
