Apple to Deprecate Scripting Languages in Future Versions of macOS(tidbits.com)
tidbits.com
Apple to Deprecate Scripting Languages in Future Versions of macOS
https://tidbits.com/2019/06/25/apple-to-deprecate-scripting-languages-in-future-versions-of-macos/
66 comments
Previous discussion 3 months ago: https://news.ycombinator.com/item?id=20109469.
About bloody time!
Apple don't keep their scripting languages updated. For example, macOS Mojave 10.14.6 ships with perl 5, version 18, subversion 4 (v5.18.4) in /usr/bin/perl; but my homebrew setup provides perl 5, version 30, subversion 0 (v5.30.0).
(And for those who don't know perl, it's been semi-permanently pinned at "perl 5" as a major version number for about 20 years due to the existence of perl 6, which is effectively a different language—as different as C++ is from C—so those minor version number differences are as significant as a major version number change in another language.)
Apple don't keep their scripting languages updated. For example, macOS Mojave 10.14.6 ships with perl 5, version 18, subversion 4 (v5.18.4) in /usr/bin/perl; but my homebrew setup provides perl 5, version 30, subversion 0 (v5.30.0).
(And for those who don't know perl, it's been semi-permanently pinned at "perl 5" as a major version number for about 20 years due to the existence of perl 6, which is effectively a different language—as different as C++ is from C—so those minor version number differences are as significant as a major version number change in another language.)
I generally set up my own toolchain, with up to date versions of Perl 5, Python, Julia, R, Octave. I've found the system distro installed tooling to be too ancient for productive use.
While this doesn't bother me much per se, the issue I see as looming is what I've experienced on a few platforms. Where their "protection" mechanisms effectively prevent you from building the code you need to function effectively.
I usually test each (new) platform by taking my code and trying to build it. If the platform is important to what I do, I'll spend some time making sure it builds correctly, and passes regression testing.
WSL in Windows 10, albeit running on a kvm on my linux laptop, does not pass muster as a system worth targeting for a number of reasons. Not the least of which is that the environment breaks the regression testing.
My concern is that MacOS gets to that point. Its getting close, as I have to specifically allow perl/python/julia/jupyter to open ports. I suspect that soon MacOS will disable this capability.
I already run Linux everywhere, MacOS is just what the corporate folks indicate is an acceptable alternative to Windows 10, which doesn't work for me. Once MacOS doesn't work, it will be far easier to argue for corporate issued Linux laptops.
Alienating DevOps, developers, hpc/ai folks ... not really a good idea. But hey, Apple does Apple, so why not.
[Edited for grammar]
While this doesn't bother me much per se, the issue I see as looming is what I've experienced on a few platforms. Where their "protection" mechanisms effectively prevent you from building the code you need to function effectively.
I usually test each (new) platform by taking my code and trying to build it. If the platform is important to what I do, I'll spend some time making sure it builds correctly, and passes regression testing.
WSL in Windows 10, albeit running on a kvm on my linux laptop, does not pass muster as a system worth targeting for a number of reasons. Not the least of which is that the environment breaks the regression testing.
My concern is that MacOS gets to that point. Its getting close, as I have to specifically allow perl/python/julia/jupyter to open ports. I suspect that soon MacOS will disable this capability.
I already run Linux everywhere, MacOS is just what the corporate folks indicate is an acceptable alternative to Windows 10, which doesn't work for me. Once MacOS doesn't work, it will be far easier to argue for corporate issued Linux laptops.
Alienating DevOps, developers, hpc/ai folks ... not really a good idea. But hey, Apple does Apple, so why not.
[Edited for grammar]
Whoa, I’ve been using Mac for almost a decade and I never knew it shipped with perl!
It was even used in some unexpected places, for example, see the HN discussion about "Apple's libc shells out to Perl to implement wordexp" [0], [1]
[0] https://news.ycombinator.com/item?id=9025572
[1] https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...
[0] https://news.ycombinator.com/item?id=9025572
[1] https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...
Most Unix systems do. Apple just does a terrible job of keeping scripting runtimes up to date.
Everything seems to be frozen in time at just before a project changed to GPL 3
Title is misleading and makes it sound like Apple is removing support for scripting features that are integrated with macOS - AppleScript for instance.
More like "Apple to stop shipping scripting language interpreters in macOS".
More like "Apple to stop shipping scripting language interpreters in macOS".
If they ship with the OS, they're "integrated" with the OS.
Strictly speaking, yes, but the level of integration is very different. I can get the version of Python which would come bundled elsewhere, but if they remove Automator, there's nothing I can do.
Not really, no. Python/Ruby/Perl interpreters are not “integrated” into the OS like AppleScript and Automator are. They’re just some binaries sitting in /usr/local/bin.
Internet Explorer was integrated into Windows in ways that Calculator or Mine Sweeper weren't — those were merely bundled with the OS.
Python, Perl are the calc.exe of this story — not integrated into the OS, just bundled with it. There's a long history between OSX and Ruby, with MacRuby and RubyCocoa being some efforts to actually integrate Ruby more tightly into the ecosystem, but those efforts have long been abandoned.
Python, Perl are the calc.exe of this story — not integrated into the OS, just bundled with it. There's a long history between OSX and Ruby, with MacRuby and RubyCocoa being some efforts to actually integrate Ruby more tightly into the ecosystem, but those efforts have long been abandoned.
scripts are just text files that can do a great deal when executed by the scripting language runtime
Microsoft have done a lot in Windows 10 to counter PowerShell malware
https://blogs.technet.microsoft.com/poshchap/2015/10/16/secu...
https://www.microsoft.com/security/blog/2017/12/04/windows-d...
It’s not foolproof but it copes with many common attacks. It’s surprising Apple hasn’t taken this approach.
Microsoft have done a lot in Windows 10 to counter PowerShell malware
https://blogs.technet.microsoft.com/poshchap/2015/10/16/secu...
https://www.microsoft.com/security/blog/2017/12/04/windows-d...
It’s not foolproof but it copes with many common attacks. It’s surprising Apple hasn’t taken this approach.
PowerShell has bent over backwards from day one to avoid being a vector for malware. You can't invoke a .ps1 file from ShellExecute (that is to say, by double-clicking it), in its default configuration Windows Server won't run an unsigned script and client won't run a script at all, and there are fine-grained settings to control execution policy and language mode across your enterprise. That's not to say it doesn't get used for malware, but in its default state you have to actually be running arbitrary code in some other language before you can jump to PowerShell. (When PowerShell was being designed, it was right after the infamous security push in Windows, and they knew that if they shipped a new scripting language you could double-click from an email, they'd be crucified for it.)
To do so would run counter to the "Mac's don't get viruses/malware" mythology.
There's been a persistent "That's only a PC thing" for a long time. Fairly sure it was even referenced in Apple's own advertising during the "I'm a Mac, I'm a PC" phase.
There's been a persistent "That's only a PC thing" for a long time. Fairly sure it was even referenced in Apple's own advertising during the "I'm a Mac, I'm a PC" phase.
Apple still advertises their operating systems as "Secure By Design". With the latest news about iOS zerodays in the wild for years, we know this isn't true.
Do a google search for "Secure By Design" site:apple.com to see where they use this term for both iOS and OSX. Someday, someone will win in court over this.
Do a google search for "Secure By Design" site:apple.com to see where they use this term for both iOS and OSX. Someday, someone will win in court over this.
Designing for security doesn’t guarantee no security issues.
Done well it should substantially reduce the number and severity of security issues. To back up your claim from a numbers standpoint you’d have to quantify the number and severity of security issues in Apple OSs vs comparable OSs that aren’t “Secure by Design”. That’s obviously problematic in a few ways. You could also analyze the design of the OS for security flaws. Though again, finding that the design isn’t perfect isn’t enough. You’d need to show how the design disregards security. A proper analysis should acknowledge history, BTW.
Done well it should substantially reduce the number and severity of security issues. To back up your claim from a numbers standpoint you’d have to quantify the number and severity of security issues in Apple OSs vs comparable OSs that aren’t “Secure by Design”. That’s obviously problematic in a few ways. You could also analyze the design of the OS for security flaws. Though again, finding that the design isn’t perfect isn’t enough. You’d need to show how the design disregards security. A proper analysis should acknowledge history, BTW.
> You’d need to show how the design disregards security.
I mostly agree with you, but don’t forget the ‘root login with empty password’ or ‘the password hint showing the password on encrypted disk unlock’ issues. I don’t see how anyone can claim that was secure by design. Sure, it was a bug, but a secure design would not have permitted that issue.
I mostly agree with you, but don’t forget the ‘root login with empty password’ or ‘the password hint showing the password on encrypted disk unlock’ issues. I don’t see how anyone can claim that was secure by design. Sure, it was a bug, but a secure design would not have permitted that issue.
I still hear non-technical people repeating this. I’ve also heard people distinguish them as “macs” and “computers”. Working in tech and surrounded by people in tech all the time makes it easy to forget just how confused people can be over these things.
I think its going to cause problems for developers if they completely remove them. As people won't be able to run the script to install the things that give them up to date scripts.
Its like using the default web browser to download the "browser of your choice".
There is the issue that apple usually "quarantines" executable downloads ("You downloaded this from X, do you really want to run) and these scripts do an end run around that. will apple be forcing a download of a signed package dng that installs macports or brew..?
Its like using the default web browser to download the "browser of your choice".
There is the issue that apple usually "quarantines" executable downloads ("You downloaded this from X, do you really want to run) and these scripts do an end run around that. will apple be forcing a download of a signed package dng that installs macports or brew..?
They won't get rid of zsh, which they've just adopted as the default shell going forward. Macports and homebrew can bootstrap with a shell script.
Apparently homebrew currently pulls a temporary ruby to run its installation on linux where it can't expect there to be a systen ruby installed. Something like that would have to be done.
It's a pain to switch languages, but it looks like there will still be at least 4 scripting languages available: Z shell, Applescript, Javascript, and Swift.
Don’t just deprecate. Remove them entirely please. If I wanted them I would install up to date versions.
It's good practice to not just remove stuff, but to deprecate it first, to give everybody time to migrate. That's exactly what Apple is doing there. The deprecation notices clearly states that they'll eventually remove it:
> Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.
> Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.
So not only is macOS changing from bash to zsh by default, but (potentially) pulling all scripting languages. Reduced attack surface... I like it! I had no idea Perl support was still there since I don't use it.
This sounds good to me. Best practice since probably close to a decade ago has been to use scripting executables with regular user permissions in their own environment with associated required libraries per app, if not in a container.
Good, they were poor at keeping them updated.
Glad they did not limp into python3 and encumber the ecosystem with some version that would have to be supported for a long time.
Amusingly enough, 10.15 is the first and last macOS to ship with python3 bundled as standard.
As to the rest of it, I’ll just re-post the same comment I post every time some muppet starts with all the wailing and rending of teeth:
This is a perfect opportunity for FOSS to position Homebrew—a proven, successful, developer-friendly software distribution channel—as an integral part of the standard development toolkit of ALL Mac developers; up to and including convincing the Xcode team to bundle it themselves.
..
Apple serves on a plate the greatest geek market opportunity in the 20-year history of Mac OS X… and only the geeks could so totally miss it!
As to the rest of it, I’ll just re-post the same comment I post every time some muppet starts with all the wailing and rending of teeth:
This is a perfect opportunity for FOSS to position Homebrew—a proven, successful, developer-friendly software distribution channel—as an integral part of the standard development toolkit of ALL Mac developers; up to and including convincing the Xcode team to bundle it themselves.
..
Apple serves on a plate the greatest geek market opportunity in the 20-year history of Mac OS X… and only the geeks could so totally miss it!
If I use homebrew or macports to install the latest versions of these languages, are their runtimes included? Just asking.
Yes, basically this news means "Ruby, python and Perl may not be preinstallled, install them yourself".
It's not a big deal for users of Homebrew or other package managers.
It's not a big deal for users of Homebrew or other package managers.
It’s a big deal for Homebrew, which is written in Ruby and uses the version shipped with macOS to install itself.
I'm curious why this is a big deal. Naively, I'd suppose that they change their current install script from "ruby: download and install brew" to: "shell: download and install ruby, then install brew". They could even have their shell script download a package that installs both.
They already bring in ruby for installs on ancient MacOS, they'll just do the same here when the time comes.
https://twitter.com/mistydemeo/status/1135934513173811200
https://twitter.com/mistydemeo/status/1135934513173811200
The bootstrap script can just as easily download a ruby binary as its first step.
Don’t be daft.
If the Homebrew team aren’t already busting ass to rewrite brew in Objective-C, and negotiating to get it distributed on AppStore or—ideally—included in Xcode as standard, then they’ll have no-one but themselves to blame when they utterly fail to capitalize on the massive market opportunity Apple has handed them here. Believe me, porting brew is a nothing price and the simplest step by far.
This is a once-in-a-product’s-lifetime chance for a proven FOSS platform not only to grab ten million new users but to influence a global platform vendor’s direction too. Fail to seize this opportunity or blow it execution, and you won’t get another (I speak from painful experience here).
If the Homebrew team aren’t already busting ass to rewrite brew in Objective-C, and negotiating to get it distributed on AppStore or—ideally—included in Xcode as standard, then they’ll have no-one but themselves to blame when they utterly fail to capitalize on the massive market opportunity Apple has handed them here. Believe me, porting brew is a nothing price and the simplest step by far.
This is a once-in-a-product’s-lifetime chance for a proven FOSS platform not only to grab ten million new users but to influence a global platform vendor’s direction too. Fail to seize this opportunity or blow it execution, and you won’t get another (I speak from painful experience here).
I think that telling users to execute a shell command to install software is not the smartest idea in any case (eg. no way to verify signatures of installed software)
A standard installer package would be much better.
A standard installer package would be much better.
> I think that telling users to execute a shell command to install software is not the smartest idea in any case (eg. no way to verify signatures of installed software)
Installing via a shell command has nothing to do with the (in)ability to verify signatures. You aren’t more protected running a random installer package than an auditable shell script from the official Homebrew repo. Also, Homebrew supports more installation methods including cloning the git repo by yourself or un-taring an archive.
Installing via a shell command has nothing to do with the (in)ability to verify signatures. You aren’t more protected running a random installer package than an auditable shell script from the official Homebrew repo. Also, Homebrew supports more installation methods including cloning the git repo by yourself or un-taring an archive.
Installers are signed, scripts piped from curl to ruby are not.
Homebrew circumvents all the protections built into macOS (like Gatekeeper / Xprotect etc) for convenience.
I don't think this method for distributing software has much of a future.
Homebrew circumvents all the protections built into macOS (like Gatekeeper / Xprotect etc) for convenience.
I don't think this method for distributing software has much of a future.
But if they don’t include Ruby in future versions of macOS or Xcode then you’ll have to install that before run big Homebrew...
That being said, this is a good thing. By pinning the interpreters to ancient versions Apple is maintaining this legacy code that is often replaced by homebrew/Macports anyway.
That being said, this is a good thing. By pinning the interpreters to ancient versions Apple is maintaining this legacy code that is often replaced by homebrew/Macports anyway.
The only issue I see is that they'll have to change how brew bootstrap itself, but it should be trivial for them to just make the installer download a minimal ruby runtime.
One good upside from this deprecation is that lots of scripts naively containing "#!/bin/python" and such without invoking them through /usr/bin/env will stop working on macOS, which is good.
One good upside from this deprecation is that lots of scripts naively containing "#!/bin/python" and such without invoking them through /usr/bin/env will stop working on macOS, which is good.
This really needs to be in every article about this: you’d want to use Homebrew anyway to get supported versions so this is a prod to stop trying to avoid it. Especially with things like Python 2.7 where some of the latter point releases had non-trivial improvements for TLS, etc. it really wasn’t worth it staying behind — and I say that as someone who used to ship Mac management tools using Python many years ago.
[deleted]
Also AppleScript?
AppleScript will remain
AppleScript’s reckoning will come once Siri Shortcuts officially ships in macOS 10.16. As Steve Troughton-Smith has demonstrated, the technical guts are already present in 10.15 [1]; it’s just not quite ready to roll as a Product yet.
[1] https://twitter.com/stroughtonsmith/status/11359563313603461...
[1] https://twitter.com/stroughtonsmith/status/11359563313603461...
Brew.sh
It’s not really UNIX anymore.
POSIX defines what Unix is, and there's no Python/Ruby/Perl here:
https://shellhaters.org
https://pubs.opengroup.org/onlinepubs/9699919799/
https://shellhaters.org
https://pubs.opengroup.org/onlinepubs/9699919799/
No, the The Open Group, which owns the trademark on the name "Unix", defines what Unix is.
No, the The Open Group, which owns the trademark on the name "Unix", defines what Unix is, and that group defines macOS as Unix. It also defines z/OS as Unix and does not define any of the Open Source BSDs as Unix, which means FreeBSD, OpenBSD, and NetBSD are not Unix and are, at most, Unix-like. OTOH, the Inspur K-UX Linux distribution is Unix.
And The Open Group doesn't use POSIX, it uses the Single Unix Specification.
And The Open Group doesn't use POSIX, it uses the Single Unix Specification.
Yeah I remember the 90's. Every time I used a system that met the standard Unix definition it felt so vanilla I wanted to dribble chocolate sauce on it.
That was a metaphor. The reality is I'd get in trouble for spending modem time using UUCP to get a decent, usable tool chain in place before I could do anything productive.
That was a metaphor. The reality is I'd get in trouble for spending modem time using UUCP to get a decent, usable tool chain in place before I could do anything productive.
What irrelevancies!
Agreed as it relates to UNIX(R). But, I think we have all come to expect BASH and other scripting to be available on our systems.
So they want to make it Windows? Going to get rid of AWK next? Not cool. Far too many things rely on them.
Good internally for Apple to stop relying on them.
Good internally for Apple to stop relying on them.