Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oracle plans to dump risky Java serialization

infoworld.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Oracle plans to dump risky Java serialization

#71

Post by gmueckl »

ta5244626777 wrote: post #25
Hupriene wrote: post #6

Having used java serialization a few times for POC level work, I'll be sorry to see it go. I wish they would just rename it something sufficiently ominous sounding that people wouldn't think about using it on untrusted data sources. Maybe AribitraryCodeAndDataSerialization

Yes it was a nice/quick/dirty way to persist an object graph, I bet it's been abused richly in a lot of codebases out there, it'll be curious to see how this is handled in terms of breakage i.e. the JDK that introduces this might be the Python 2/3 showdown (if that's still a thing). Be curious to do a Github wide grep for ObjectOutputStream or something similar and see what it's like in open source land.

This is made more exciting by the fact that Java rarely introduced big breaking changes in the past. Especially deprecated classes (java.util.Date...) never were actually removed. Starting this now is going to wreak havoc.

Re: Oracle plans to dump risky Java serialization

#73

Post by saryant »

anonacct37 wrote: post #51
sewercake wrote: post #36

Won't this have serious implications for Spark, Hadoop, and other frameworks that distribute workloads across multiple JVM instances?

So to be clear most "code" shipping frameworks in jvm land use jar files. Big data systems are not using native serialization for either code or data.

That's not quite true. Both Akka and Flink use Java serialization in many key aspects.

Re: Oracle plans to dump risky Java serialization

#74

Post by benaadams »

scarface74 wrote: post #37

I was trying to understand if C# has the same issue. From what I can tell, as long as you use the default serialization, it seems to be safe. But I can't really tell. https://www.alphabot.com/security/blog/2017/net/How-to-confi...

There is a dangerous form https://docs.microsoft.com/en-us/dotnet/standard/serializati...

> Binary serialization can be dangerous. Never deserialize data from an untrusted source and never round-trip serialized data to systems not under your control.

The killed it in .NET Core 1.x; but brought it back in .NET Core 2.x due to back compat and interop complaints

Re: Oracle plans to dump risky Java serialization

#75

Post by MichaelMoser123 »

rad_gruchalski wrote: post #59

There are so many great alternatives available. It's a no-brainer. I applaud. [edit] so why the downvote? We have YAML, JSON, protobuf, Thrift, Avro. Yup, these serialize "contents" rather than "structure + contents" but one gets interop with other technologies for free. Every tech mentioned above is so simple to use that removing Java serialization is a no-brainer.

That would also kill RMI (at least JRMP), and that too would be a good thing, RMI doesn't even pass through a router (unless you do RMI-IIOP - and that is very different from regular RMI - JRMP)

For java backwards compatibility used to be very important, so this is big news for the platform.

I think this remoting the bytecode with serialisation madness was once upon a time very important part of RMI/serialisation - back in the thin client java days this was supposed to be the way to distribute code across a network link, security was not the very first priority in the nineties (beats me why they made JRMP non routable)

Re: Oracle plans to dump risky Java serialization

#76

Post by willvarfar »

kibibu wrote: post #67
rad_gruchalski wrote: post #59

There are so many great alternatives available. It's a no-brainer. I applaud. [edit] so why the downvote? We have YAML, JSON, protobuf, Thrift, Avro. Yup, these serialize "contents" rather than "structure + contents" but one gets interop with other technologies for free. Every tech mentioned above is so simple to use that removing Java serialization is a no-brainer.

I suggest you look at the myriad security problems caused by Ruby's handling of YAML and JSON. It's not necessarily the serialization format at fault, but rather developer assumptions.

(Here's a post describing some of the problems back in the day with Ruby's YAML and JSON: https://williamedwardscoder.tumblr.com/post/43394068341/ruby...

YAML is of course a format that is designed to instantiate objects as described in the source, rather than as checked by the destination, so I wouldn't want the world to adopt YAML instead of Java serialization.)

Re: Oracle plans to dump risky Java serialization

#77

Post by adrianmsmith »

ataturk wrote: post #3

It's funny that serialization is noted as a "horrible mistake" from 1997 but no mention of RMI, the even worse mistake. I guess Java has a lot of bad mistakes. I wish Oracle would end Java so I could move on to something else. Or maybe I'll just move on to something else anyways as I'm really rather sick of writing these syntactically crippled lambdas. The streaming stuff is almost good.

Could you point me to some information on why RMI is a bad mistake? (Genuine question.)

Re: Oracle plans to dump risky Java serialization

#78

Post by chopin »

dwaite wrote: post #50
ataturk wrote: post #3

It's funny that serialization is noted as a "horrible mistake" from 1997 but no mention of RMI, the even worse mistake. I guess Java has a lot of bad mistakes. I wish Oracle would end Java so I could move on to something else. Or maybe I'll just move on to something else anyways as I'm really rather sick of writing these syntactically crippled lambdas. The streaming stuff is almost good.

Good news, removing serialization will irrevocably break RMI. And yeah, it would be nice if eventually a spring cleaning could remove some of the mistakes - Enumeration, Date/Calendar, Hashtable, ClassLoader, etc.

What's the problem with ClassLoader?

Re: Oracle plans to dump risky Java serialization

#80

Post by Turbots »

gmueckl wrote: post #71
ta5244626777 wrote: post #25

Earlier quoted context omitted.

Yes it was a nice/quick/dirty way to persist an object graph, I bet it's been abused richly in a lot of codebases out there, it'll be curious to see how this is handled in terms of breakage i.e. the JDK that introduces this might be the Python 2/3 showdown (if that's still a thing). Be curious to do a Github wide grep for ObjectOutputStream or something similar and see what it's like in open source land.

This is made more exciting by the fact that Java rarely introduced big breaking changes in the past. Especially deprecated classes (java.util.Date...) never were actually removed. Starting this now is going to wreak havoc.

why is it going to wreak havoc? Java 8 will be supported until 2020 and Java 11 (next LTS version, due in September this year) will be supported until probably 2022. This change will come even after that. I wish they would have killed classes like java.util.Date long ago, since its one of the worst classes which is widely used in the JRE. Serialization was invented in 1997 and has no real usecase anymore.. You want loose coupling and tightly bounded contexts, not the other way around.
Post reply on HN