
Apple to Deprecate Scripting Languages in Future Versions of macOS - bryanrasmussen
https://tidbits.com/2019/06/25/apple-to-deprecate-scripting-languages-in-future-versions-of-macos/
======
l2dy
Previous discussion 3 months ago:
[https://news.ycombinator.com/item?id=20109469](https://news.ycombinator.com/item?id=20109469).

------
cstross
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.)

~~~
weberc2
Whoa, I’ve been using Mac for almost a decade and I never knew it shipped with
perl!

~~~
snazz
Most Unix systems do. Apple just does a terrible job of keeping scripting
runtimes up to date.

~~~
selectodude
Everything seems to be frozen in time at just before a project changed to GPL
3

------
xiaq
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".

~~~
fortran77
If they ship with the OS, they're "integrated" with the OS.

~~~
jboles
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.

------
goatinaboat
_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://blogs.technet.microsoft.com/poshchap/2015/10/16/security-
focus-defending-powershell-with-the-anti-malware-scan-interface-amsi/)

[https://www.microsoft.com/security/blog/2017/12/04/windows-d...](https://www.microsoft.com/security/blog/2017/12/04/windows-
defender-atp-machine-learning-and-amsi-unearthing-script-based-attacks-that-
live-off-the-land/)

It’s not foolproof but it copes with many common attacks. It’s surprising
Apple hasn’t taken this approach.

~~~
paranoidrobot
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.

~~~
fortran77
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.

~~~
jmull
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.

~~~
jsjohnst
> 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.

------
acomjean
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..?

~~~
chongli
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.

------
rapsey
Don’t just deprecate. Remove them entirely please. If I wanted them I would
install up to date versions.

~~~
Dunedan
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.

------
mikece
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.

------
jhanschoo
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.

------
hsaliak
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.

~~~
hhas01
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!

------
chmaynard
If I use homebrew or macports to install the latest versions of these
languages, are their runtimes included? Just asking.

~~~
martius
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.

~~~
polpo
It’s a big deal for Homebrew, which is written in Ruby and uses the version
shipped with macOS to install itself.

~~~
jakobegger
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.

~~~
hk__2
> 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.

~~~
jakobegger
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.

------
IloveHN84
Also AppleScript?

~~~
rahuldottech
AppleScript will remain

~~~
hhas01
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...](https://twitter.com/stroughtonsmith/status/1135956331360346113)

------
sys_64738
Brew.sh

------
rasengan
It’s not really UNIX anymore.

~~~
frou_dh
POSIX defines what Unix is, and there's no Python/Ruby/Perl here:

[https://shellhaters.org](https://shellhaters.org)

[https://pubs.opengroup.org/onlinepubs/9699919799/](https://pubs.opengroup.org/onlinepubs/9699919799/)

~~~
rasengan
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.

~~~
frou_dh
Given that GNU stands for GNU's Not Unix then the whole puzzle is fitting
together just perfectly.

------
crb002
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.

