On Sun, Sep 16, 2018 at 2:38 PM Will Sargent wrote:
>
> > The security manager is legacy these days and I think we need to figure out
> > a plan how to deprecate and eventually bury it.
>
> I don't know of any research or papers that explicitly say that
> SecurityManager is "legacy". I did some
On Wed, Oct 3, 2018 at 7:53 PM Sergey Bylokhov
wrote:
> Hi, Sean.
> One question related to SecurityManager and performance, is it possible
> to provide a special version of AccessController.doPrivileged which will
> be noop if SecurityManager is not present?
TBH that method (at least, the no-arg
Then your selector can only be used for SSL things. What if someone
decides to take the exact same approach to solve some other
higher-OSI-layer protocol decoding? Now you have to choose which kind
of protocol you want your selector to support. Note that with a plain
selector and plain sockets,
On Sat, Feb 16, 2019 at 4:19 PM Andi Mullaraj wrote:
> 2. What if someone decides to take the exact same approach to solve some
> other higher-OSI-layer protocol decoding? Now you have to choose which kind
> of protocol you want your selector to support.
>
> They create their own selector. I hav
On Fri, Mar 8, 2019 at 4:17 PM Andi Mullaraj wrote:
>
> Inline my comments but putting this upfront so that it doesn't go unnoticed
> for the occasional reader:
>
> I was directed to this forum for discussing the merits and technicals details
> of a possible SSLSelector/SSLSocketChannels. The le
On Fri, Mar 22, 2019 at 10:29 AM Nico Williams
wrote:
>
> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
> > it is intended to work. Means less code you have to maintain
>
> There's a few reasons:
>
>
This is, AFAICT, expected based on the differences between the socket
layers of the various operating systems involved and their handling of
closed sockets. If you write a similar test program in C using OS specific
APIs, I believe you will see similar results. I don't think this is a
problem wit
I can say that from the perspective of SASL that we don't need any
special indication about handshake, and it would be much easier to
just read the material off of the engine, socket, or session as
appropriate.
On Thu, Aug 31, 2017 at 8:32 PM, Xuelei Fan wrote:
> The failure-and-retry mechanism c
One thing that springs to mind. Some allowance would have to be made
for domain combiners and JAAS Subject propagation: this mechanism also
uses access control contexts, to its own great detriment. I would say
that the JAAS domain combiner strategy should be dropped in favor of a
simple thread lo
On Tue, Nov 21, 2017 at 5:41 AM, Alan Bateman wrote:
> On 21/11/2017 00:48, David Lloyd wrote:
>>
>> One thing that springs to mind. Some allowance would have to be made
>> for domain combiners and JAAS Subject propagation: this mechanism also
>> uses access control
This past weekend I took some time to try out an idea I've been
kicking around for a couple of weeks: a pure-Java (no native)
AccessController implementation [1].
•Rationale•
I have a number of reasons for attempting this enhancement.
• I think it would be beneficial (security-wise) if access c
On Tue, Feb 20, 2018 at 1:57 PM, Xuelei Fan wrote:
> In this implementation, I removed:
> 1. the KRB5 cipher suite implementation.
> Please let me know if you are still using KRB5 cipher suite. I may not add
> them back if no objections.
I am given to understand that we have multiple users using
these after all.
On Wed, Feb 21, 2018 at 9:32 AM, Xuelei Fan wrote:
> Thanks for the feed back. It's good enough to get KRB5 cipher suites back.
>
> Regards,
> Xuelei
>
>
> On 2/21/2018 5:06 AM, David Lloyd wrote:
>>
>> On Tue, Feb 20, 2018 at 1:57 PM, Xuelei Fa
Is it possible that this could make Java 11, or is that a long shot?
On Fri, Mar 30, 2018 at 11:36 AM, wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/332
>
> - Mark
--
- DML
On Thu, Jul 12, 2018 at 2:30 PM Xuelei Fan wrote:
> On 7/12/2018 10:47 AM, Simone Bordet wrote:
> > On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote:
[...]
> >> In TLS 1.3, half-close policy is used. The server may not response with
> >> the close_notify for client close_notify request. See the
On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan wrote:
>
> This is a SecurityManager related change which warrants some additional
> details for its motivation.
>
> The current System.setSecurityManager() API allows a SecurityManager to
> be set at run-time. However, because of this mutability, it inc
On Fri, Sep 14, 2018 at 8:22 AM Alan Bateman wrote:
>
> On 14/09/2018 13:46, David Lloyd wrote:
> > :
> >> There are essentially two main parts to this change:
> >>
> >> 1. Deprecation of System.s[etS]ecurityManager()
> > We (JBoss) use this meth
Here at Red Hat there have been serious discussions about the impacts
of security manager removal on our users, and whether there is an
actual value impact, and if so, whether it can be mitigated or
reversed somehow. We are interested in exploring whether we can come
up with a way in which vendors
Thanks for responding Peter, I've commented inline below.
On Tue, Apr 5, 2022 at 8:19 PM Peter Firmstone
wrote:
>
> Thanks David,
>
> I'd certainly support such a proposal and encourage OpenJDK to consider
> exploring it.
>
> Perhaps also consider; no privileges should be granted unless a
> privi
Hi Sean, thanks for replying. I'll reply inline.
On Thu, Apr 7, 2022 at 2:20 PM Sean Mullan wrote:
>
> With this proposal, as I understand it, the JDK would still be
> responsible for maintaining and preserving essentially all of the
> existing calls to the Security Manager (SM).
I think we'd ac
Small correction:
On Fri, Apr 8, 2022 at 8:03 AM David Lloyd wrote:
> Instead the API would exist to give containers and applications an
> extra layer of authorization which does not exist today.
Of course I meant "which would not exist after JEP 411".
--
- DML • he/him
On Fri, Apr 8, 2022 at 10:14 AM Sean Mullan wrote:
>
> Ok, thanks for some clarification on the proposal.
>
> How many applications currently depend on the SM for this type of usage?
> What other alternate models have you considered?
There are some number of customers and users within our user ba
On Fri, Apr 22, 2022 at 10:04 PM Martin Balao wrote:
> In my view, authorization decisions at higher layer generally
> have better context, are more clear and less riskier. At a lower layer
> there is more complexity and chances of both subtle combinations or
> unseen paths that may lead to check
On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman wrote:
>
> On 25/04/2022 13:53, David Lloyd wrote:
> > Nothing in the proposal causes splitting or delegation of
> > responsibilities. It is _only_ about preserving security checkpoints
> > in the JDK, which *add* a lay
On Tue, Apr 26, 2022 at 8:17 AM Mario Torre wrote:
> I think there's a difference between "perceived" security and "actual" one.
>
> The SM in today's post Spectre, Meltdown and the likes world is
> "perceived" security, which may lead to a relaxation on the security
> of other layers because at l
How would a truncation attack be avoided in this case?
On Fri, Nov 13, 2020 at 8:23 AM Sean Coffey wrote:
>
> removing the "closing inbound before receiving peer's close_notify" exception
> that can be seen with TLS stack if calling close on inbound. After reading
> the relevant parts of the TL
27;re to keep the check in the JDK, should we restrict it to the v1.3
> protocol or should we implement it based on a system property perhaps ?
>
> regards,
> Sean.
>
> On 13/11/2020 17:11, David Lloyd wrote:
> > How would a truncation attack be avoided in this case?
> >
&
If it helps, we've solved this particular problem in a couple of places by
using an MR-JAR which selects an implementation using `StackWalker` when
Java 9+ is used. I will say however that it appears to be slightly less
performant, which is unfortunate (but hopefully fixable at some point in
the f
tyManager
could stay with enough scaffolding for a third party (say, your extension)
to be able to use their own stack-based access checker (made practical
thanks to the new-ish StackWalker API).
Anyway here it is:
------ Forwarded message -
From: David Lloyd
Date: Sat, May 22,
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
wrote:
> 1. Develop authorization layer security provider services in OpenJDK,
> back port it to Java 8 and Java 11 (these provide most of the
> utilised functionality of SecurityManager, allowing developers to
> only implement those whi
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
> SecurityManager depends on Permission, currently there are Permission
> checks throughout the JVM, however Permission implementation classes
> will be removed, although the Permission class itself won't be.
This is incorrect AFAICT. The re
31 matches
Mail list logo
