Hmm, whitelisting, you're using the principle of least privilege too then.
We have multiple SecurityManager and Policy implementations.
Our policy implementations can decorate each other with different
functionality, including dynamic permissions and permissions granted by
a permission service
On 31/05/2021 08:11, Peter Firmstone wrote:
:
I think also that many more people are using SecurityManager than
OpenJDK realises, and they're not using it how OpenJDK recommends
either, (AllPermission granted to trusted code, and sandbox untrusted
code model of Applets is not how we use it) p
On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev wrote:
> Inspired by PR#4088. Most of the changes are done automatically using
> IntelliJ IDEA refactoring. Some manual adjustments are also performed,
> including indentations, moving comments, extracting common cast out of switch
> expression
Thanks Alan,
Concurrency is difficult too, but Java has gone a long way to addressing
this with concurrency libraries that make the task seem like child's
play, compared to using Java 1.4 language constructs.
On 31/05/2021 5:59 pm, Alan Bateman wrote:
On 31/05/2021 08:11, Peter Firmstone wro
> 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, incl
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.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
For the record, I want to point out that the latest revision to the
JEP 411 draft didn't solve the issue highlighted below, since applications
embedding a Java runtime still would not be able to suppress the warning
issued when setting a security manager. Such applications will thus have
to stay at
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.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
The Utils.remaining(List list) method assumes that it can and
should synchronize on the given list to prevent concurrent modification. In 99%
of the cases this assumption is wrong. There's only one such list (the
SSLFlowDelegate writeList) that requires this synchronization.
Also the `Sequenti
On Mon, 31 May 2021 16:21:29 GMT, Daniel Fuchs wrote:
> The Utils.remaining(List list) method assumes that it can and
> should synchronize on the given list to prevent concurrent modification. In
> 99% of the cases this assumption is wrong. There's only one such list (the
> SSLFlowDelegate wri
> The Utils.remaining(List list) method assumes that it can and
> should synchronize on the given list to prevent concurrent modification. In
> 99% of the cases this assumption is wrong. There's only one such list (the
> SSLFlowDelegate writeList) that requires this synchronization.
>
> Also t
On 05/31/21 11:51, Mikael Sterner wrote:
> For the record, I want to point out that the latest revision to the
> JEP 411 draft didn't solve the issue highlighted below, since applications
> embedding a Java runtime still would not be able to suppress the warning
>
> On Fri, May 21, 2021, at 19:33,
On 05/31/21 12:45, Chapman Flack wrote:
> allow-until-degraded. In 17, that would be treated as allow, but with
> the warning suppressed. In 17+n, wherever functional degradation starts,
> it should become equivalent to disallow.
> ...
> the future "degradation", but commit to one easily-detected "
The deprecation warnings serve three purposes:
1. Help software maintainers know about the deprecation.
2. Help software users (the more tech-literate ones, those who look at logs)
know when the software they use has properly addressed the issue.
3. Help us better gauge, however imperfectly and
On 05/31/21 14:58, Ron Pressler wrote:
> However, if the warning were emitted just once, at startup, if the
> “allow” value is given rather than on each SM installation, would that
> reduce the warning noise for you?
In my case not at all, because only one SM is ever installed per process,
at star
On 05/31/21 03:59, Alan Bateman wrote:
> The SM survey in 2018 showed that there was some usage too.
Out of curiosity, where can I learn more about this survey?
Was it the kind of survey that, if I had been hanging around in the right
places in 2018, I might have been solicited to respond to?
Re
On 01/06/2021 01:11, Chapman Flack wrote:
On 05/31/21 03:59, Alan Bateman wrote:
The SM survey in 2018 showed that there was some usage too.
Out of curiosity, where can I learn more about this survey?
Was it the kind of survey that, if I had been hanging around in the right
places in 2018, I m
Would have really liked to have known about that.
Any chance Java 17 LTS (hopefully with sorted security manager
property), can be supported as long as Java 8, 16 years?
The new security API's don't exist yet, I'd prefer to work with a
version that has a fully functional SecurityManager rathe
18 matches
Mail list logo
