> All `IntegerPolynimial`s are singletons now. Also, hand-coded implementations
> for Ed25519 and Ed448 are removed. They were not used since `FieldGen` starts
> generating classes for them.
>
> No new regression test. This is a clean-up.
Weijun Wang has updated the pull reques
All `IntegerPolynimial`s are singletons now. Also, hand-coded implementations
for Ed25519 and Ed448 are removed. They were not used since `FieldGen` starts
generating classes for them.
No new regression test. This is a clean-up.
-
Commit messages:
- the fix
Changes:
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeliński wrote:
>> Please review this PR that enables
>> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170)
>> compiler flag, which makes assigning a string
Update Public Suffix List data to the latest version at
https://github.com/publicsuffix/list.
-
Commit messages:
- 8255266: 2021-11-27 public suffix list update v 3c213aa
Changes: https://git.openjdk.java.net/jdk/pull/6643/files
Webrev:
On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote:
> As a follow up of JEP 411, we will soon disallow security manager by default.
> jtreg 6.1 does not set its own security manager if JDK version is >= 18.
This pull request has now been integrated.
Changeset: c24fb852
Author: We
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote:
> The cacerts file is now a password-less PKCS12 file. This make sure old code
> that uses a JKS KeyStore object can continuously load it using a null
> password (in fact, any password) and see all certificates inside.
This pull re
On Tue, 19 Oct 2021 18:49:11 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use a standard name
>
> make/jdk/src/classes/build/tools/generatecacerts/Generate
> The cacerts file is now a password-less PKCS12 file. This make sure old code
> that uses a JKS KeyStore object can continuously load it using a null
> password (in fact, any password) and see all certificates inside.
Weijun Wang has updated the pull request incrementally with one a
> As a follow up of JEP 411, we will soon disallow security manager by default.
> jtreg 6.1 does not set its own security manager if JDK version is >= 18.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
upgrade the versi
As a follow up of JEP 411, we will soon disallow security manager by default.
jtreg 6.1 does not set its own security manager if JDK version is >= 18.
-
Commit messages:
- 8275512: Upgrade required version of jtreg to 6.1
Changes: https://git.openjdk.java.net/jdk/pull/6012/files
On Fri, 15 Oct 2021 14:12:55 GMT, Magnus Ihse Bursie wrote:
>> make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line
>> 74:
>>
>>> 72: cert = (X509Certificate) cf.generateCertificate(fis);
>>> 73: }
>>> 74:
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote:
> The cacerts file is now a password-less PKCS12 file. This make sure old code
> that uses a JKS KeyStore object can continuously load it using a null
> password (in fact, any password) and see all certificates inside.
For pass
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote:
> The cacerts file is now a password-less PKCS12 file. This make sure old code
> that uses a JKS KeyStore object can continuously load it using a null
> password (in fact, any password) and see all certificates inside.
No
On Thu, 14 Oct 2021 19:07:55 GMT, Michael Osipov wrote:
> Generating this trust store with Java code like I do?
What do you mean "like you do"? If you accept the proposed format in this PR,
then just follow what `GenerateCACerts.java` is doing and how it's called. If
you are thinking about
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote:
> The cacerts file is now a password-less PKCS12 file. This make sure old code
> that uses a JKS KeyStore object can continuously load it using a null
> password (in fact, any password) and see all certificates inside.
If
The cacerts file is now a password-less PKCS12 file. This make sure old code
that uses a JKS KeyStore object can continuously load it using a null password
(in fact, any password) and see all certificates inside.
-
Commit messages:
- 8275252: Migrate cacerts from JKS to
On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(up to x20
On Fri, 4 Jun 2021 15:53:42 GMT, Weijun Wang wrote:
> Now that the default behavior of JDK 17 is still
> `-Djava.security.manager=allow`, we can remove the
> `-Djavatest.security.noSecurityManager=true` option from the jtreg command
> line inside `RunTests.gmk`. Three problem-list
On Fri, 4 Jun 2021 16:10:02 GMT, Jonathan Gibbons wrote:
>> Now that the default behavior of JDK 17 is still
>> `-Djava.security.manager=allow`, we can remove the
>> `-Djavatest.security.noSecurityManager=true` option from the jtreg command
>> line inside `RunTests.gmk`. Three problem-listed
Now that the default behavior of JDK 17 is still
`-Djava.security.manager=allow`, we can remove the
`-Djavatest.security.noSecurityManager=true` option from the jtreg command line
inside `RunTests.gmk`. Three problem-listed langtools tests can also be
liberated.
-
Commit
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.c
ions and javadoc tags, build, compiler,
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are
> reviewed. Rest are 2d, awt, beans, sound, and swing.
Weijun Wang has updated the pull request with a new target base due to a merge
or a rebase. The pull request now conta
ions and javadoc tags, build, compiler,
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are
> reviewed. Rest are 2d, awt, beans, sound, and swing.
Weijun Wang has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contain
ions and javadoc tags, build, compiler,
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are
> reviewed. Rest are 2d, awt, beans, sound, and swing.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
rename
On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>
ions and javadoc tags, build, compiler,
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are
> reviewed. Rest are 2d, awt, beans, sound, and swing.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>
ions and javadoc tags, build, compiler,
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are
> reviewed. Rest are 2d, awt, beans, sound, and swing.
Weijun Wang has updated the pull request with a new target base due to a merge
or a rebase. The pull request now c
On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>>
>>> 102: * method will throw an {@code UnsupportedOperationException}). If the
>>> 103: * {@systemProperty java.security.manager} system property is set to
>>> the
ions and javadoc tags, build, compiler,
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are
> reviewed. Rest are 2d, awt, beans, sound, and swing.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
On Fri, 21 May 2021 20:43:05 GMT, Phil Race wrote:
> I haven't seen any response to this comment I made a couple of days ago and I
> suspect it got missed
>
> > Weijun Wang has updated the pull request incrementally with one additional
> > commit since the last rev
On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang wrote:
>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and
>> definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't
>> really ready.
>&
On Wed, 19 May 2021 23:50:04 GMT, Phil Race wrote:
>> I just made it P3 (P4 was the default value), and I will target it to 17
>> once JEP 411 is targeted 17. But I think it's probably not a good idea to
>> include it inside *this* PR. There are some middle ground where it's
>> debatable if a
On Wed, 19 May 2021 22:04:57 GMT, Phil Race wrote:
>> Correct, there are ways to modify the code to make it more
>> annotation-friendly. We thought about whether it's good to do it before
>> adding the annotations or after it. Our decision now is to do it after
>> because it will be more easy
On Wed, 19 May 2021 19:31:24 GMT, Phil Race wrote:
>> This happens when a deprecated method is called inside a static block. The
>> annotation can only be added to a declaration and here it must be the whole
>> class. The call in this file is
>>
>> s =
On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang wrote:
>> Similar as the one above, it's because of
>>
>> static {
>> // Don't lazy-read because every app uses invalidate()
>> isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>>
On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang wrote:
>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>>
>>> 95: * @since 1.0
>>> 96: */
>>> 97: @SuppressWarnings("removal")
>>
>> Same issue as with Component.
On Wed, 19 May 2021 18:26:25 GMT, Phil Race wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/c
On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>
ions and javadoc tags, build, compiler,
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are
> reviewed. Rest are 2d, awt, beans, sound, and swing.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
fixing aw
ystem
> property is now "disallow", most of the tests calling
> `System.setSecurityManager()` need to launched with
> `-Djava.security.manager=allow`. This is covered in a different PR at
> https://github.com/openjdk/jdk/pull/4071.
Weijun Wang has update
On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/java/security/AccessController.java line 877:
>>
>>> 875: @CallerSensitive
>>> 876: public static T doPrivileged(PrivilegedExcept
On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.c
Please review this implementation of [JEP
411](https://openjdk.java.net/jeps/411).
The code change is divided into 3 commits. Please review them one by one.
1.
https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
The essential change for this JEP, including the
On Fri, 18 Dec 2020 19:20:47 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/SCDynamicSt
> 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://bugs.openjdk.java.net/browse/JDK-8257860
On Wed, 3 Feb 2021 11:27:49 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - file attr error
>> - objc use .m
>
> src/java.security.jgss/share/classes/sun/sec
On Mon, 1 Feb 2021 11:41:02 GMT, Magnus Ihse Bursie wrote:
>> Weijun Wang has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
> 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://bugs.openjdk.java.net/browse/JDK-8257860
> 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://bugs.openjdk.java.net/browse/JDK-8257860
On Sat, 30 Jan 2021 00:06:51 GMT, Phil Race wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> phil comment
>
> Marked as reviewed by prr (Reviewer).
Added a test. Unfortunately it has t
> 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://bugs.openjdk.java.net/browse/JDK-8257860
> 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://bugs.openjdk.java.net/browse/JDK-8257860
> 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://bugs.openjdk.java.net/browse/JDK-8257860
On Fri, 29 Jan 2021 22:05:21 GMT, Phil Race wrote:
>> So I should remember how env was retrieved and only detach when it's from
>> `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has
>> never succeeded and it was always attached.
>
> Yes that is the idea. BTW which thread
On Fri, 29 Jan 2021 20:51:04 GMT, Phil Race wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> same behavior as before -- empty realm map
>
> make/modules/java.security.
> 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://bugs.openjdk.java.net/browse/JDK-8257860
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://bugs.openjdk.java.net/browse/JDK-8257860)
-
Commit
On Fri, 18 Dec 2020 19:20:47 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/SCDynamicSt
On Tue, 26 Jan 2021 18:42:02 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote:
> This is the security libs portion of the effort to replace
> archaic/non-inclusive words with more neutral terms (see JDK-8253315 for
> details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as
On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote:
>> Also, to clarify, for me there is a fundamental difference between
>> `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files
>> that are part of the module, owned by the content team, and the `$MODULE`
>> part is
On Mon, 23 Nov 2020 15:08:13 GMT, Sean Mullan wrote:
> This change removes five root certificates with 1024-bit RSA public keys from
> the system-wide `cacerts` keystore. These are older VeriSign and Thawte root
> CA certificates which are no longer necessary to retain and should have
>
On Thu, 24 Sep 2020 21:15:34 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/conf/security/java.security line 636:
>>
>>> 634: #
>>> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage
>>> TLSServer, \
>>> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
>>
On Wed, 23 Sep 2020 23:38:03 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
> On Mar 24, 2020, at 3:03 AM, Magnus Ihse Bursie
> wrote:
>
> I have also moved the build tools to the org.openjdk.buildtools.* package
> name space (inspired by Skara), instead of the strangely named build.tools.*
> name space.
Is this really necessary? Skara is a standalone tool that have
Code change for JDK-8240261 uses $(TOPDIR)/make/templates/gpl-cp-header to
generate source files but it is not available in all source bundles used for
builds.
Request to back out the change. The changeset is a direct output of 'hg
backout' command. You can see the webrev at
Please take a review at
https://cr.openjdk.java.net/~weijun/8240261/webrev.00
Thanks,
Max
I noticed a problem of myself but do not know if update_copyright_year.sh can
deal with it more correctly.
For example,
---
old/src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/Aes128CtsHmacSha2EType.java
2019-12-22 19:00:54.0 +0300
+++
> On Nov 27, 2019, at 9:44 PM, Erik Joelsson wrote:
>
> On 2019-11-26 16:39, Weijun Wang wrote:
>>
>>> On Nov 27, 2019, at 12:14 AM, Erik Joelsson
>>> wrote:
>>>
>>> On 2019-11-25 16:42, Weijun Wang wrote:
>>>>> On Nov 26,
> On Nov 27, 2019, at 12:14 AM, Erik Joelsson wrote:
>
> On 2019-11-25 16:42, Weijun Wang wrote:
>>
>>> On Nov 26, 2019, at 12:36 AM, Erik Joelsson
>>> wrote:
>>>
>>> Build change looks good.
>> Thanks.
>>
>> One q
that one does not log anything
actually.
I can remove all output too, not really important.
Thanks,
Max
>
> /Erik
>
> On 2019-11-22 18:59, Weijun Wang wrote:
>> Please review the change at
>>
>>http://cr.openjdk.java.net/~weijun/8234697/webrev.00/
>>
&g
Please review the change at
http://cr.openjdk.java.net/~weijun/8234697/webrev.00/
The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the
beginning of the same file.
I changed the BigInteger parameter in the FieldParams constructor (the one not
reading terms) to its
Here is the updated webrev
http://cr.openjdk.java.net/~weijun/8225392/webrev.01/
The only change is ordering in 'keytool -list' and its test.
Thanks,
Max
> On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote:
>
> On 6/14/19 1:49 AM, Weijun Wang wrote:
>> BTW, something not rela
> On Jun 14, 2019, at 5:00 AM, Sean Mullan wrote:
>
> On 6/12/19 9:52 PM, Weijun Wang wrote:
>> Hi Sean,
>> The previous fix for JDK-8193255 already made the creation date useless.
>> Before that, each time cacerts was regenerated the date changed. I compar
I've filed https://bugs.openjdk.java.net/browse/JDK-8225687.
> On Jun 11, 2019, at 7:56 AM, Nico Williams wrote:
>
> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
>> Updated webrev at
>>
>> http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
>
fixed one way or other in JDK
>>>> 13, so depending on if you get your fix there in time, I will retract my
>>>> proposal. If your fix only hits 14, I will push mine to 13.
>>>>
>>>> /Erik
>>>>
>>>> On 2019-06-12 08:41, Weijun W
ent cacerts.
I don't have a solution. Maybe in your repo you can @ignore this test.
Thanks,
Max
>
> On Wed, Jun 12, 2019 at 8:42 AM Weijun Wang wrote:
> This is my version of the fix:
>
>http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>
> Now you can still compa
your fix only hits 14, I will push mine to 13.
>
> /Erik
>
> On 2019-06-12 08:41, Weijun Wang wrote:
>> This is my version of the fix:
>>
>>http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>>
>> Now you can still compare cacerts bit by bit.
>>
>> Thanks,
>> Max
This is my version of the fix:
http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
Now you can still compare cacerts bit by bit.
Thanks,
Max
> On Jun 12, 2019, at 10:50 PM, Weijun Wang wrote:
>
> Hi Erik,
>
> Are you going to fix this bug soon?
>
> I am inspi
12, 2019, at 10:59 AM, Weijun Wang wrote:
>
> Good idea about the creation time.
>
> --Max
>
>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz wrote:
>>
>> Google culture really likes build output determinism, and we recently built
>> our own cacert
Good idea about the creation time.
--Max
> On Jun 12, 2019, at 10:53 AM, Martin Buchholz wrote:
>
> Google culture really likes build output determinism, and we recently built
> our own cacerts generator.
>
> To get determinism, we are using cert digest as alias (must have a unique
> alias,
ote:
>
> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
>> Updated webrev at
>>
>> http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
>
> -
> src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java
>
> Ugh, I never no
; Thanks,
>> David
>>
>>> —Max
>>>
>>> 获取 Outlook for iOS <https://aka.ms/o0ukef>
>>>
>>>
>>>
>>> On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes"
>>> mailto:david.hol...@oracle.com>> wrote:
&
keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"
would exclude the date (which has its own line).
--Max
> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote:
>
> The "keytool -list" output contains a creation data (I know it's use
The "keytool -list" output contains a creation data (I know it's useless now),
so if THIS_FILE and THAT_FILE happen to be created on different dates then you
will see difference.
--Max
> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote:
>
>
> On 2019-06-10 16:23, David Holmes wrote:
>> Hi
I'm missing?
I don't remember. I must have copied it from somewhere. The only special thing
about this target is that it includes a header file from the shared area.
I am running make again to see if it's useless.
Thanks,
Max
>
> /Erik
>
> On 2019-06-09 19:30, Weijun Wang wrote:
&g
ase_oid_set before returning failure?
>
> - line 1471: should we return an error code here when FormatMessage() call
> failed?
>
> Rest looks fine.
>
> Thanks,
>
> Valerie
Thanks,
Max
[1]
https://docs.microsoft.com/en-us/windows/desktop/api/sspi/nf-sspi-decryptmessag
> On May 31, 2019, at 11:15 PM, Sean Mullan wrote:
>
> On 5/30/19 8:49 PM, Weijun Wang wrote:
>> Sure. How many info do you want to see?
>> I can prepend `keytool -printcert` but that's too much. At least I think the
>> extensions part is not needed. Also,
-05-30 08:32, Weijun Wang wrote:
>>
>>> On May 30, 2019, at 10:01 PM, Erik Joelsson
>>> wrote:
>>>
>>> In my experience, using directories for dependencies in make does not work
>>> well. Since all the files in make/data/cacerts are in a flat st
he source code via a browser or something
> like that, it would be nice to not have to do that.
>
> --Sean
>
> On 5/30/19 9:01 AM, Weijun Wang wrote:
>> Please take a review at
>>http://cr.openjdk.java.net/~weijun/8193255/webrev.00/
>> Please pay attention to t
> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote:
>
> In my experience, using directories for dependencies in make does not work
> well. Since all the files in make/data/cacerts are in a flat structure, I
> would recommend expressing the prerequisites as:
>
> $(wildcard
ote:
>
> Hi Max,
>
> Not a review :)
>
> On 30/05/2019 11:01 pm, Weijun Wang wrote:
>> Please take a review at
>>http://cr.openjdk.java.net/~weijun/8193255/webrev.00/
>> Please pay attention to the 1st 3 and the last 2 files. Others are PEM files
>&
Please take a review at
http://cr.openjdk.java.net/~weijun/8193255/webrev.00/
Please pay attention to the 1st 3 and the last 2 files. Others are PEM files
for all certs inside the original cacerts.
There is one thing I cannot get correct. If I update the GenerateCacerts.java
file and rerun
t 5:48 PM, Erik Joelsson wrote:
>
>
> On 2019-01-04 10:29, Weijun Wang wrote:
>> Just curious, why were you mentioning WSL and Ubuntu? Isn't this a pure
>> Windows build issue? Or is it possible to use WSL instead of Cygwin to
>> launch the build process now? That's
Just curious, why were you mentioning WSL and Ubuntu? Isn't this a pure Windows
build issue? Or is it possible to use WSL instead of Cygwin to launch the build
process now? That's unbelievable.
Thanks,
Max
> On Jan 4, 2019, at 3:22 PM, Yasumasa Suenaga wrote:
>
> Hi all,
>
> I tried to
> 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.
>>>
>>
1 - 100 of 215 matches
Mail list logo
