I talked to an Apple engineer recently, 2 weeks ago roughly, and he told me that Apple is advising customers to "move away from scripting".

This is just laughable, and 100% inaccurate. I would say, there is little stock in what the Sales Org at Apple can say to a customer, let alone what they really know roadmap wise. It would break internal macOS things losing the ability to execute code.

@mschroder

I don't really see shipping own versions of python, perl ruby etc as a solution. We are a BYOD environment, almost everything on our site is done via the Self-Service. If there is no more perl, python ruby etc shipped by Apple I can not assume anything about the presence or the version of these. It will be a mess.

There are still plenty of ways to tackle this issue. You have to enroll your BYOD device to even get self service. There are tons of options.

In the end none of these changes should shock you. The last time I inquired about Python 3 (which was about 3 years ago) Apple sent me a link stating you should ship your own third party languages. The writing on the wall has been there for some time. I found a neat tool that makes shipping Python super easy.

Bash 3.2 is old and janky compared to all new and modern shells. Bash 4 is GPLv3 and every corporation out there hates that license, so they refuse to use it. Over the past 3 years Apple has consistently shipped a very new and modern version of zsh . I guessed this even before I officially knew.

These are good changes, it forces us to use best practices and modern tech. Relying on system libs is not always the best practice and the only thing it gets you, is not shipping your own.

@tlarkin

I found a neat tool that makes shipping Python super easy.

Can you post which tool you found and have you personally tested it?

What where your results?

Having been on the wrong end of more than one Qualys scan flagging a Mac server for an old version of tool X because Apple had stopped updating that generation of Mac OS (some G5 Xserve systems had a looooong life) I definitely see an upside of decoupling these things from macOS itself. Nothing in Apple's announcement makes me think they're planning on eliminating our ability to utilize different scripting languages. They're just not going to be responsible for making them available. Kind of like how they stopped being responsible for Java on the Mac (and I've been doing this long enough to remember when they created Macintosh Runtime for Java so there was a decent Mac JVM)

Apologies if these exist here already. Some cool stuff in zsh, but all this new stuff flying in from Apple is hard to keep up with:

bash vs zsh

Apple-HT208050

Some good bits to start...

I’ve hardly had time yet to go through any of the WWDC sessions yet but Robert Hammen has posted a good summary of Catalina changes for admins to be aware of, including links to all the post Charles Edge & Rich Trouton have made (some links require Dev access)

https://medium.com/@hammen/significant-changes-in-macos-10-15-catalina-of-interest-to-mac-admins-fbc3865c055e

@tnielsen That's a "DO NOT LIKE / BUT I AGREE" - Apple's become very much about not enabling independence but monetizing dependence, so this is the direction I fear things are headed.

@tlarkin Your input is always appreciated - I hope your level head and cooler attitude prevail. I could see "removing scripting capabilities" as Apple's answer to Windows 10S to improve security at the expense of usibility.

We're already internally updating what built in scripting components we can; I had to add a step to update ruby in our builds a few months ago, @sdagley thanks to a Qualys scan.

@Sterritt That's kind of my point - if you're getting dinged on the version of the components you have deployed being out of date it's better it's under your control to update them rather than a bandaid to address the issue while hoping Apple will eventually release an official fix.

Very important line at the bottom of this support article that will probably will keep most your old scripts functioning properly. Admittedly I have not tested it.

zsh can be made to emulate sh by executing the command zsh --emulate sh

Everything from grep to rsync is already way out of date on a Mac.

@CorpIT_eB yup here ya go

relocatable-python

I already shipped out a test run to a bunch of Macs after testing it locally. So far no issues, and I even shipped requests with it.

@Sterritt ya I get the ideas that people are coming up with. The fact that macOS relies on a lot of scripts to function tells me we are a ways off from that. Plus, it would kill the Mac as a viable development computer and that would only hurt Apple. You can ship embedded languages in apps, so you need a computer that can run it. They most definitely might make it harder, but I think Apple just wants to get out of the biz of shipping third party libs and languages and leaves it up to us. Also, if you haven't seen, Windows 10 can install Python 3 natively now from their app store. So, even Windows is on that now.

@sdagley yeah you gotta watch those vuln scanners though. Point in case, I had one for a 10.12 version of open SSH not too long ago. The CVE was enumeration and the only thing it got you was the username, which isn't even really a risk if you use keys, and MFA. Anyone trying to attack your company specifically can go to LinkedIN, find the IT or dev or whatever, and figure out that their user name is a combination of the standard naming conventions.

A lot of times security won't vet that stuff, they will just tell you to patch because some vuln scanner said there is a CVE. In reality, if a vuln isn't going to bankrupt your company it isn't critical, but still should be patched.

Apple did not patch this at all in 10.12, but they did in 10.13+. I used it as an excuse to get rid of 10.12 boxes in my fleet.

everyone should watch this

macOS security enhancements

Interesting that the date for Notarization is June 1, 2019 and not the previous date (April 7th?)...
Thanks for the link, @tlarkin

the take away from that keynote is that "all code must be signed in a future release of macOS"

Well, it was going that way anyway, but what I am happy about is that the Full Disk Access items are pre-populated in unchecked state to not have to figure out WTH? goes in there...

@tlarkin I was very intrigued to see everything that is now going under UPP now.

ya I typically stay out of user space as much as I can as a general rule.

@tlarkin as do but I, I agree it looks like there might be a-lot more to it now.

In Cataline, will switching to zsh change how Jamf run scripts on macs? If I write a script in zsh (shebang and all) and scope it to a mac, will it be ran on the mac with the zsh interpreter?

Nope. A user switching to zsh won't effect how scripts are run (which is why your scripts should begin by saying what they're using /bin/bash, /bin/sh, etc).

And, for now, bash, python, and the other languages being discontinued will continue to work... but they could go away in the future (probably with 10.16, but it could be 10.15.3 or something). So, take the time now to review all your shell scripts, and the scripts you may have in pkg installers.

And with Catalina the path to some things has changed. So, test all your scripts.

the jamf binary executes scripts as files, so whatever shebang you are using in code it will execute as. Also, technically bash is not going away, it is just no longer the default shell. There is also nothing stopping anyone from shipping their own bash version 5 binary either. There are still plenty of options to look at.

If there is any glaring lessons to be learned here, is that as an I.T. Admin/Engineer you should really use VCS systems and centralize your code in a repo, so in the event you need to convert or rewrite, it is a lot more easy than chasing downs tons of scripts. Also, try to write reusable static code, it makes things a lot easier.

I'm a bit late to the game, but I haven't had time to check this until now.
I want to check if some of my current important scripts in Jamf (in bash) would still work should Apple decide to remove bash in coming versions. Sadly, ShellCheck doesn't support zsh. Is there another easy way to check if the script contains errors for zsh? Or is zsh --emulate sh an option for this?
I'm still quite new to Apple and Jamf, so I'm trying to figure everything out as I go.

What prevents the install of python, perl, ruby, etc at high priority level at enrollment time with Jamf? (not a rhetorical question)

I feel like this will hurt developers a lot. Many of the big software vendors use some of these third party scripting languages in their installers...

I did a presentation at MacSysadmin in Gothenburg, a series of blog posts and a book on this topic. https://scriptingosx.com/zsh