I'm done with M4L until it is unbounded from (outdated) Java

Questions and discussion about building and using Max for Live devices
Post Reply
hyperscientist
Posts: 71
Joined: Mon Feb 16, 2015 9:37 pm

I'm done with M4L until it is unbounded from (outdated) Java

Post by hyperscientist » Mon Aug 22, 2016 12:19 pm

I'm terribly disappointed.

Ableton Live Suite - otherwise fantastic and progressive piece of software relies on so outdated piece of technology that is beyond reason. It's a security risk and a bloat and terribly annoying. Also, it's something that could be fixed with relative ease since Java could be bundled to Max.

I'm done with it which means that I now paid for extra for Suite which will now be only marginally more useful than Standard.

Fantastic deal, Ableton, thanks! Especially since I and almost every other client of yours never signed up for it since you do not state these ridiculous requirements on your website, which obviously is a borderline cheat.

TomSwirly
Posts: 109
Joined: Wed Apr 30, 2008 7:55 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by TomSwirly » Mon Aug 22, 2016 2:28 pm

I didn't believe you were correct, but apparently you are.

I did a lot of Java in the past. It's likely that the explanation that since there's no web component there's no security violation is correct, but it's not certain. For example, the version of Java you're using might have been used for the web some time in the past, and then compromised and partly overwritten by the attacker - so when you run it now, you restart their attack vector. Rewriting binaries is a common trick for attackers, and I have been sitting in front of a Linux machine where I gradually realized that most of the binaries had been rewritten by some intruder (there was no solution but to extract all data from that disk, and then wipe it).

In practice, I think that's unlikely, and unless you know there's some reason you're personally targeted by government forces or black hat hackers, I wouldn't worry. This bug (it's an actual bug to rely on dependencies that are known to be obsolete) should still be fixed, though - if only because running Java when you never use it has to consume a reasonable amount of RAM for nothing.

stringtapper
Posts: 6273
Joined: Sat Aug 28, 2004 6:21 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by stringtapper » Mon Aug 22, 2016 2:37 pm

Here's some info another user posted about this:
Stormkraft wrote:With Apples Java 6 version or any Java version, you should go into the java control panel (in System Preferences) and set it to be inactivated in web browsers. Security holes are in the browser.

As far as I know Max never responds to the network or tries to access it, so having Java 6 installed with web browsers off, shouldn't pose a security threat.
Unsound Designer

hyperscientist
Posts: 71
Joined: Mon Feb 16, 2015 9:37 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by hyperscientist » Mon Aug 22, 2016 2:56 pm

Thank you Tom and stringtapper for taking the time.

We could go deep and analise particular vectors of reasonably possible attacks, but why bother? It’s literarily as simple as: “unsupported software” equals “software at highly elevated risk”. Also, it’s an annoyance, also it’s not stated up front, also it’s a bloat on my computer and also it already bit me in the ass once in the past when I tried to setup some Java based web server (I’m a software developer).

If humongous Apple decided to cut it out for whatever reason, then who am I to say it was unnecessary? :)
Also, Cycling74 themselves claim that Java 6 may not even be possible to install on next revision of OS X: MacOS Sierra! So, basically in a month or two we may not be able to Run M4L at all! Sadly, I believe that some users already confirmed it works and so there's no compelling reason for them to do anything about this relic.
This version of Java is several years out of date, and there will be no further updates from Apple. OS X 10.11 "El Capitan" will be the last version of OS X to support the installation of legacy Apple Java for OS X; later versions of OS X can only use Oracle Java.
The rest of this post isn’t really important - I’m just elaborating for those who have too much time on their hands and like to argue on the internet ;)

Yeah, sure, we cut it out from Internet access and we expect our computer to be safe, but is it? But what if an attacker finds a way in and then uses outdated software to elevate its privileges? That is exactly how it often works.

And with this particular piece software it is impossible to for example constrain installation to one particular user.

Also, I may not be important enough person to be a specific target, but that is NOT how 99% of hacks these days occur - most of the attacks are carried out by bots - scanning all computers in all networks they have access to for known vulnerabilities and they have access to a seriously vast libraries of exploits.

These things do happen, for example: years back I was connected to dorm network and by the time I formatted and reinstalled fresh Windows my computer was already compromised and malware was installed. Very recently I installed fresh system on my Raspberry Pi an left it connected for few days without securing it first and when I got back to it I found a running Bitcoin miner software (which is obviously ridiculous, but on a global scale…).

stringtapper
Posts: 6273
Joined: Sat Aug 28, 2004 6:21 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by stringtapper » Mon Aug 22, 2016 3:22 pm

The thing to understand is that from a purely technical standpoint this is all on Cycling 74's side. The Java dependency is due to the Java objects that exist in Max; they're like external objects that you can code directly in Java.

Because of the history of Max, a program whose core is nearly forty years old (!), there has always been an MO to not break backwards compatibility with older patches. Making broad changes to the toolset would potentially break older patches, so this is why keeping older features like Java support is important to Cycling 74.

Why they can't use an updated version, I don't know.

What will happen to the Java features when Apple computers no longer support Java, who knows. They could have to bite the bullet and finally relent to cutting some features for once.

Max has always been a Mac-centric piece of software, so they certainly won't be able to ignore it for long (and I doubt they actually are ignoring it).
Unsound Designer

TomSwirly
Posts: 109
Joined: Wed Apr 30, 2008 7:55 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by TomSwirly » Mon Aug 22, 2016 3:39 pm

You shouldn't be forced to load anything you _might_ use; and why would it have been unreasonable to say, "Sorry, no Java in M4L patches" anyway?

It might very well be that not even one person is using Java in a M4L patch - I could find no one claiming to be doing that! Even if a few are, we're all paying something in RAM and disk space and security for a facility that only a tiny number of people use.

Also, M4L will allow you to open a patch that refers to a Max box that isn't on your current machine, I've done it plenty of times before. That box simply does nothing. So there is at least some way to pull something like this off - though I understand that a binary linkage is quite different to a textual linkage like a Max box.

Don't get me wrong - Max is an amazing thing, and Cycling '74 is responsive to bug reports; plus, they are a tiny company putting out an entire programming environment.

Overall, while the Java 6 dependency is a blemish, I don't think it's a real quality defect that should lead one not to use M4L.

stringtapper
Posts: 6273
Joined: Sat Aug 28, 2004 6:21 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by stringtapper » Mon Aug 22, 2016 3:55 pm

TomSwirly wrote:Also, M4L will allow you to open a patch that refers to a Max box that isn't on your current machine, I've done it plenty of times before. That box simply does nothing. So there is at least some way to pull something like this off…
Pull what off?

What you're describing is an instance where someone used an external 3rd party object in a M4L device and didn't freeze the device to allow it to bundle the external with the device.

In other words, that external not being there means the device won't function.
Unsound Designer

TomSwirly
Posts: 109
Joined: Wed Apr 30, 2008 7:55 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by TomSwirly » Mon Aug 22, 2016 4:53 pm

Yes, I understand that entirely. I've been using Max for over 20 years...

But consider from a higher level what's happening. During the loading process for the M4L document, a box is encountered which cannot be resolved to code (for the specific reason you listed).

The loader is able to substitute it with an "empty box" that does nothing.

So why can't it just "put in the empty box when it sees Java content and no Java" - so if there's no Java, there are no problems?

My answer is that conceptually this is no big deal; that even theoretically it's straight-forward; but practically it might be a huge amount of work, though one would have to see the actual code to know the real answer.

---

I did give you a taste of the answer above - it's entirely to do with when and how the binary code that implements the JVM is loaded into the executable image in memory.

Now, Max clearly has some way to dynamically load executable (compiled, binary) code when it's running because you can download and run new `.mxo` binary boxes without restarting Max.

However, if there's actual code in the core of Max itself which depends on facilities from the JVM, then the JVM must be loaded at the same time as the Max application starts, even if that Java-dependent code never in fact gets called. It is nearly certain to me that that is the root of the problem.

As to why that code can't be extracted out into its own shared library and loaded on demand, without seeing the codebase one can only speculate.

But implementing it and breaking nothing absolutely isn't so easy as one sentence, particularly for a cross-platform application. That short period while programs load themselves into memory is always a source of problems and difficulties, and this is a 30-year-old codebase. It might take even someone who knew the codebase well weeks of work and months of "wall clock time" to actually get this working - and I'd add that it'd be weeks of boring, tedious work of unpicking dependencies and moving things from place to place. (I'd also say that the codebase would probably benefit from it...)

In general, I shudder to think what it must be like to be working in a 30-year old C codebase. Modern C++ is sleek and fast to write code in; it lets you create really powerful and simple programming abstractions and yet pay no runtime cost for them at all. I wrote plenty of C code at the same time that Max was getting started - it was appallingly slow and error-prone to write, but I don't have to support any of it; indeed, all my codebase is C++11 these days, a really sweet spot in terms of "lots of features/reliable/universally available".

And then to interface this in the same binary with a 15-year old C++ program with its own pathologies (or so I heard - for example, I was told that the reason that Ableton will never be able to open two documents at one time is that there is a single global variable representing "the current document" that is used everywhere).

The mind boggles. I'm very impressed it works at all.

That there are Java dependencies that they haven't yet removed is not because the Cycling '74 guys are sitting there drinking mai tais on the beach and laughing at us users, but that it's probably a lot of tedious work that someone needs to get done.

stringtapper
Posts: 6273
Joined: Sat Aug 28, 2004 6:21 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by stringtapper » Mon Aug 22, 2016 5:11 pm

TomSwirly wrote:However, if there's actual code in the core of Max itself which depends on facilities from the JVM, then the JVM must be loaded at the same time as the Max application starts, even if that Java-dependent code never in fact gets called. It is nearly certain to me that that is the root of the problem.
That would surely have to be the case, right? I would think that the very functionality of the [.mxj] and [.mxj~] objects would require it.
Unsound Designer

TomSwirly
Posts: 109
Joined: Wed Apr 30, 2008 7:55 pm

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by TomSwirly » Mon Aug 22, 2016 5:18 pm

No, it could - in principle - be dynamically loaded. For example, there's a box called `pyext` that does for Python exactly what the Java box does for Java and it's entirely dynamically bound, and loaded at runtime.

EDIT: As I said, "in principle" probably conceals weeks of work. But they're going to have to do something soon because Java 6 soon won't run at all on Mac computers. I'm sure they'll figure it out.

Stromkraft
Posts: 7033
Joined: Wed Jun 25, 2014 11:34 am

Re: I'm done with M4L until it is unbounded from (outdated) Java

Post by Stromkraft » Fri Oct 07, 2016 12:19 pm

TomSwirly wrote:No, it could - in principle - be dynamically loaded. For example, there's a box called `pyext` that does for Python exactly what the Java box does for Java and it's entirely dynamically bound, and loaded at runtime.

EDIT: As I said, "in principle" probably conceals weeks of work. But they're going to have to do something soon because Java 6 soon won't run at all on Mac computers. I'm sure they'll figure it out.
As the released version of Sierra allow the latest Java 6 released from Apple to install and run, then maybe Cycling74 have yet some more time. The solution should already be in place.

To provide their own JVM, as suggested above, probably makes a lot of sense. That would give Cycling74 maximum control over features on both platforms and hopefully would bewilder users the least in practical use. I think it's some undertaking though, having peeked into the source code of java6 myself. Maybe they should cooperate with some open source outfit?

As for why not just update any necessary dependencies to a current version of Java may have something to do with breaking existing devices that do rely on Java and need something from Java 6 that would require a rewrite (which goes against much of the spirit of Java). Otherwise that would seem like a very possible option.

I think it's unnerving you can't tell easily which devices you love that might be affected by such moves. Do you have to open each device in Max to see which objects they make use of to be able to tell or is there some other analysis you can put them thru?
Make some music!

Post Reply