Studies, experts, meetings and academics, without practical application
of the principle of least privilege, these are meaningless. I hope
someone remembered to bring tea and scones.
My point is nothing gets done without workers. It's the Pareto
Principle or 80:20 rule. Li Gong may have
Let me be very clear: the proposers of this JEP, some of whom have worked on
the Security Manager for the
last twenty years, strongly believe that not only will its removal not harm
Java’s security, but considerably
improve it, as do the maintainers of other platforms who have decided to either
On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng wrote:
>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher
>> transformation.
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>
>> Existing AESWrap impl, i.e.
I had hoped by end of this discussion, that there would at least be an
understanding of what OpenJDK is so hastily choosing to destroy.
Once it is gone, it will be irretrievable, it will never be possible to
lock down the JVM so securely again.
On 21/05/2021 11:06 pm, Ron Pressler wrote:
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make some
> performance-based decisions.
>
> Thanks
>
> Tony
On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng wrote:
>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher
>> transformation.
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>
>> Existing AESWrap impl, i.e.
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 revision:
> > fixing
On Wed, 19 May 2021 13:47:53 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.
>>
> The code change refactors classes that have a `SuppressWarnings("removal")`
> annotation that covers more than 50KB of code. The big annotation is often
> quite faraway from the actual deprecated API usage it is suppressing, and
> with the annotation covering too big a portion it's easy to
On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:
>
>> 548: * @throws
On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:
>
>> 118:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
> `-Djava.security.manager=allow` when launched. This PR covers such
On Fri, 21 May 2021 18:26:48 GMT, Phil Race wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
>
>> 1: /*
>> 2:
On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote:
>> Please review the test changes for [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> With JEP 411 and the default value of `-Djava.security.manager` becoming
>> `disallow`, tests calling `System.setSecurityManager()` need
>>
On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman wrote:
>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class
> level is introducing technical debt but if addressing that requires
> refactoring and
The current version of JEP 411 (Deprecate the Security Manager for Removal) has
as its goal "Warn users if their Java applications rely on the Security
Manager.". To that end it proposes to "Issue a warning message at startup if
the Security Manager is enabled on the command line."
I would
On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang wrote:
>> The code change refactors classes that have a `SuppressWarnings("removal")`
>> annotation that covers more than 50KB of code. The big annotation is often
>> quite faraway from the actual deprecated API usage it is suppressing, and
>>
On Wed, 19 May 2021 13:47:53 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.
>>
> Hi,
>
> Could someone please review my code for updating the code in the `java.util`
> package to make use of the `instanceof` pattern variable?
>
> Kind regards,
> Patrick
Patrick Concannon has updated the pull request incrementally with one
additional commit since the last revision:
> The code change refactors classes that have a `SuppressWarnings("removal")`
> annotation that covers more than 50KB of code. The big annotation is often
> quite faraway from the actual deprecated API usage it is suppressing, and
> with the annotation covering too big a portion it's easy to
> On 21 May 2021, at 12:52, Peter Firmstone wrote:
>
> It's quite clear this will be pushed through anyway,
>
No, not *anyway*, but given the fact that the community consists of millions of
users, this
proposal has been well-publicised, only very few people have voiced objections,
fewer
On 21/05/2021 9:14 pm, Ron Pressler wrote:
On 21 May 2021, at 11:29, Peter Firmstone wrote:
Can you share this list please? If I see anything missing I can add it for
you.
No, because this might give the false impression that this is a debate.
It's quite clear this will be pushed
> Hi,
>
> Could someone please review my code for updating the code in the `java.util`
> package to make use of the `instanceof` pattern variable?
>
> Kind regards,
> Patrick
Patrick Concannon has updated the pull request with a new target base due to a
merge or a rebase. The incremental
> On 21 May 2021, at 11:29, Peter Firmstone wrote:
>
>
> Can you share this list please? If I see anything missing I can add it for
> you.
No, because this might give the false impression that this is a debate. In a
community
of millions, almost no decision will be universally accepted.
On 21.05.2021 03:40, Peter Firmstone wrote:
If there are those of us who wanted to maintain a fork of Java 17,
focused on security, we could backport new features after they've been
reviewed for security.
Would we be welcomed to do that here? Otherwise is it something we
should do on
On 21/05/2021 6:58 pm, Ron Pressler wrote:
These are just opinions, it's nice to have them, but they're not
helping. I think you'll find usages of SecurityManager api's are far
more widespread than your opinion suggests, but that's just my
opinion too lol.
I guess you could say they’re my
> On 21 May 2021, at 04:55, Peter Firmstone wrote:
>
>
> Yes everything is a compromise and there are trade-offs. The way I see it,
> the cheapest way to maintain security is to find others who share a common
> pain point is to maintain a copy of OpenJDK focused on security. We can
>
27 matches
Mail list logo
