On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>> libosxkrb5/SCDynamicStoreConfig.m](https://b
On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>> libosxkrb5/SCDynamicStoreConfig.m](https://b
Max,
Good catch on the SunRsaSign provider bug.
Looking at the changes, I think we may have to fine-grain the check on
the ensureInit() call, i.e.
use ensureInit(boolean sign) instead of ensureInit(), as the current
method only ensures that at least one of the privKey, pubKey or
fallbackSig
On 6/22/2018 3:23 PM, Weijun Wang wrote:
On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote:
Max,
Good catch on the SunRsaSign provider bug.
Looking at the changes, I think we may have to fine-grain the check on the
ensureInit() call, i.e.
use ensureInit(boolean sign) instead of ensureInit
Great, that's good then.
Valerie
On 6/22/2018 5:40 PM, Weijun Wang wrote:
On Jun 23, 2018, at 8:35 AM, Valerie Peng wrote:
On 6/22/2018 3:23 PM, Weijun Wang wrote:
On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote:
Max,
Good catch on the SunRsaSign provider bug.
Looking at the ch
an be FreeCredentialsHandle and then used and then freed
again.
On Jun 7, 2019, at 10:45 AM, Valerie Peng wrote:
Hi, Max,
- line 424: the "(used to be const)" comment can now be removed.
- line 396-403: on line 338, there is no need to go to err as no memory has
been allocated. What happens
On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino
wrote:
>> This change removes the native elliptic curves library code; as well as, and
>> calls to that code, tests, and files
>> associated with those libraries. The makefiles have been changed to remove
>> from all source builds of the ec c
Hi, build experts,
Can you please review the make file related change, i.e. the new file ||
*make/gensrc/Gensrc-java.naming.gmk*, in the following webrev:
http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/
This is for merging the java.security.Provider file from various
providers and use
rrent list.
I’ll file a bug to follow up to change java.security to list the provider name.
This will wait after the jimage refresh goes into jdk9/dev
Ok.
Thanks,
Valerie
.
Mandy
On May 27, 2015, at 3:29 PM, Valerie Peng wrote:
Hi, build experts,
Can you please review the make file re
decision in a day or two.
Will update the list again.
Thanks,
Valerie
On 06/01/15 16:39, Magnus Ihse Bursie wrote:
On 2015-05-29 00:10, Valerie Peng wrote:
Please find comments in line...
On 5/27/2015 3:42 PM, Mandy Chung wrote:
Valerie,
Did you see my comment yesterday?
http
ding which provider would get picked up. Is that
resolved or do you really need to override all of those providers with
your generated file in gensrc? I can assist in writing that makefile
logic if needed.
/Erik
On 2015-06-04 23:58, Valerie Peng wrote:
Build experts,
Can you please review the
/java.security.Provider file content is not correct,
the new test would fail and it's a clear indication that ServiceLoader
can't find one or more of the providers.
Thanks,
Valerie
On 6/5/2015 10:43 PM, Mandy Chung wrote:
On Jun 5, 2015, at 4:32 PM, Valerie Peng wrote:
I don't know image buil
sun.security.tools.jarsigner.Main to use the new
Provider.configure() api
5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching and
configuring PKCS11 provider
Thanks,
Valerie
On 6/8/2015 4:44 PM, Valerie Peng wrote:
What is the bug id for the image refresh change? Just so I can keep
Hi, Sean and build experts,
Can you please review the fix for 8130665
"java/lang/SecurityManager/CheckSecurityProvider.java failing in jake on
OS X"?
The Apple provider fails to be instantiated in Jake due to the missing
permission grants.
However, it currently only fails in Jake workspace and
Can someone please help reviewing this change?
This is to move Apple provider from jdk.deploy.osx module to java.base
module.
The native library for Apple provider is separated out from the "osx"
one generated in jdk.deploy.osx module and named "osxapple" (sort of
following the convention of S
Updated the webrev in place to use "osxsecurity" given peer feedbacks.
Thanks,
Valerie
On 8/13/2015 7:31 PM, Valerie Peng wrote:
Can someone please help reviewing this change?
This is to move Apple provider from jdk.deploy.osx module to java.base
module.
The native library for Appl
Thanks for the review.
Is one more reviewer from build team needed?
Valerie
On 8/14/2015 4:58 PM, Mandy Chung wrote:
Looks good.
Mandy
On Aug 14, 2015, at 4:30 PM, Valerie Peng wrote:
Updated the webrev in place to use "osxsecurity" given peer feedbacks.
Thanks,
Valerie
On 8/13
Ok, thanks!
Valerie
On 8/18/2015 12:34 AM, Erik Joelsson wrote:
One is enough.
/Erik
On 2015-08-18 02:21, Valerie Peng wrote:
Thanks for the review.
Is one more reviewer from build team needed?
Valerie
On 8/14/2015 4:58 PM, Mandy Chung wrote:
Looks good.
Mandy
On Aug 14, 2015, at 4:30 PM
Anyone can help reviewing this?
The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to
address the E_MACRO_REDEFINED warning.
In addition, I also updated the nativeCrypto.h to remove the workaround
for a Solaris12-specific issue which has now been fixed.
Bug: https://bugs.openj
Could someone please review this build related change for moving
sunpkcs11-solaris.cfg file to the pkcs11 module?
Webrev: http://cr.openjdk.java.net/~valeriep/8039898/webrev.00/
Thanks,
Valerie
Thanks all for the review and tips on webrev.
I have re-generated the webrev following all the tips...
Thanks again,
Valerie
On 9/11/2014 3:42 AM, Magnus Ihse Bursie wrote:
On 2014-09-11 11:51, Alan Bateman wrote:
On 11/09/2014 10:38, Magnus Ihse Bursie wrote:
The webrev shows the file as bei
Hi, build experts,
Could you please review the build-related changes for 8046002: Move
Ucrypto to the open jdk repo?
The rest (src/test) has been reviewed by my peers in security team.
Bug: https://bugs.openjdk.java.net/browse/JDK-8046002
Webrev: http://cr.openjdk.java.net/~valeriep/8046002/we
/2014 11:54 AM, Alan Bateman wrote:
On 15/10/2014 19:46, Valerie Peng wrote:
Hi, build experts,
Could you please review the build-related changes for 8046002: Move
Ucrypto to the open jdk repo?
The rest (src/test) has been reviewed by my peers in security team.
Bug: https://bugs.openjdk.java.net
Well, it turns out that I do have to update modules.xml with the
jdk.crypto.ucrypto module info (Thanks to a tip from Mandy). I have sent
the necessary webrev for this to jigsaw alias separately.
Thanks,
Valerie
On 10/15/2014 2:39 PM, Valerie Peng wrote:
The /modules.xml already allows
could change the findstring construct to a
simple "ifeq ($(OPENJDK_TARGET_OS), windows)", perhaps even fold the
whole ifndef OPENJDK into the previous ifeq since they are now the same.
Otherwise it looks good to me.
/Erik
On 2014-10-15 20:46, Valerie Peng wrote:
Hi, build experts,
y
'/scratch/java_re/builds/workspace/9-2-build-solaris-amd64/jdk9-dev/1534/jdk/make/lib'
Main.gmk:182: recipe for target 'jdk.crypto.ucrypto-libs' failed
gmake[2]: *** [jdk.crypto.ucrypto-libs] Error 2
gmake[2]: *** Waiting for unfinished jobs
-phil.
On 10/20/14 12:56
26 matches
Mail list logo
