operty prior to initialization,
> the first use of ObjectInputStream, which is quite easy if an application
> doesn't use it. In future developers who don't use Java serialization will
> need to make sure it has been initialized so it can't be used as an attack
> vector, who will remember to do that?
> >
> >>> Other techniques that are yet to be developed. OpenJDK is
> deprecating SecurityManager prior to the implementation of it's
> replacement, a little more notice would have been nice. I'm ready for you
> to deprecate Serialization, we saw that coming, but this is just completely
> unexpected out of left field.
> >> First, any deprecation proposal could be said to be unexpected until it
> is proposed. But that is why
> >> we have a deprecation policy that makes the process gradual and gives
> people time to adjust. Second, I
> >> don’t think this is "out of left field" at all. The writing on the wall
> was pretty clear when, after twenty-five
> >> years, few projects use the Security Manager and few libraries are
> properly instrumented for it, other platforms
> >> have decided not to adopt a similar model, and those few that have have
> already abandoned it some years ago.
> >
> >
> > Library's don't need to be instrumented for it, the Java platform is
> already and provides the necessary protection for network connections, file
> access and class loading for example.
> >
> >
> > - Peter.
> >
>
>
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
On Wed, May 12, 2021 at 10:49 PM Ron Pressler
wrote:
>
> > On 12 May 2021, at 22:41, Peter Tribble wrote:
> >
> > Let me give a concrete example:
> >
> > Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> > We
On Wed, May 12, 2021 at 10:22 PM Ron Pressler
wrote:
>
>
> > On 12 May 2021, at 21:46, Peter Tribble wrote:
> >
> > We're (partly, at least) in that group. We can't block the access from
> outside
> > the JVM (and we are containerized with restric
for years to come.
>
I appreciate that there will be older versions we can run; the issue is
always
that there may be some external driver why we have to update - either to
gain
a critical feature, or because something else doesn't support the old
version.
I know I would feel a lot happier wi
ill find a way take
> advantage of it for that reason.
> >
> > It is clear that no further progress will be made in this matter and I
> will simply have to live with the consequences. Stick a fork in me, because
> I'm done.
>
> You are conflating the Security Manager with security. A lot of security
> work has been going on in the JDK for the past few years
> (and will continue for as long Java exists), but not in the
> code-protection-domain-sandbox known as the Security Manager.
>
> — Ron
>
>
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
