In 2016, that laptop also came with System Integrity Protection - you couldn't change /usr/bin/python if you wanted to. And you still can't to this very day. Changing System-provided python was always against recommendations in prior OS versions because the next OS update could re-replace it at any time.
I agree that it probably contributed to python 2 inertia as it was re-exposing people to the idea that "typing python in the Terminal gets me python 2" and "I just used what I already had" - but it definitely wasn't stopping people installing a newer version.
It depends on where you're authenticating to. If you're authenticating to yourself, then sure a signature is will just be converted to a yes/no and be no better. But if you're authenticating to a server, the server can do the signature verification, whereas a server looking at a yes/no that a client sends would be mostly useless.
The next time you'd like to diagnose, you can reboot into Recovery and use "csrutil enable --without dtrace --without debug" and you should be able to avoid those issues.
One workaround is actually to just cp /bin/whatever to /tmp/whatever and debug that, but in this particular case I needed to follow forks (from zsh to ssh) so that wasn't as easy. Or I guess I could have played games with $PATH. Ah well.
Either way, there is something funny going on with ssh and private keys and their passphrases. Very odd how "-o BatchMode=yes" fails to load encrypted private keys that don't require any user input in normal use. And it's definitively something new because this was never a problem in 10.11 or below.
I think Apple stopped loading the passphrases into the agent automatically. I think they're strictly only loaded from the keychain now, per connection, unless you explicitly use -A to add them to the agent.
In prior versions, it was stored in Login keychain, which was not synchronized.
Additionally, the items were visible in the security command line tool and in Keychain Access, so you could delete them.
The Local Items keychain / iCloud Keychain is a new style keychain that was back ported from iOS. The security and Keychain Access tools have no visibility into it, it's 100% handled by the secd service.
Edit: Ah, sorry, you meant in Sierra specifically. Yes. But I'll leave these clarifying details here for posterity :)
Edit2: Additional detail - in prior OSes, there was a GUI prompt asking if you wanted to store the passphrase in the keychain. This is gone now. It just does it (unless you preemptively edited the ssh config file to disable keychain storage in advance)
Edit3: Can confirm that "ssh-add -K -d" does in fact delete the passphrase from the keychain, even though it may throw an agent error.
> The security and Keychain Access tools have no visibility into it, it's 100% handled by the secd service.
That's not quite true: Keychain Access can write to Local Items keychain, but not everything in Local Items are visible to Keychain Access. Apple changed ssh to store private key passphrases differently than before, in a way that's invisible to Keychain Access. However, you can freely move / copy entries from, say your login keychain, to Local Items with Keychain Access, and vice versa, and they would remain visible.
Fortunately, the Local Items keychain, stored in ~/Library/Keychains/<UUID>/keychain-2.db is just a sqlite3 database, with (presumably) encrypted fields. If you run "ssh -vvv" you can even see the query.
> Edit3: Can confirm that "ssh-add -K -d" does in fact delete the passphrase from the keychain, even though it may throw an agent error.
Huh, I thought I'd tried that before resorting more drastic measures. Or maybe "-d" works but not "-D", hmm or maybe I'd neglected to also pass "-K".
There's an IL interpreter in the mix - it's simulating an app and what it would do based on the opcodes emitted by the compiler for the code you write.
This is indeed in line with existing scripting languages (Lua, Python, etc) which are in the App Store.
But the presentation of it might be too close for comfort for Apple. He's not presenting it as ".NET scripting" but specifically mentioned porting the .NET Roslyn compiler.
It all boils down to the same thing, but I wouldn't be surprised to see an App Store submission reviewer deny it, misunderstanding what's they've read/seen.
I would love to see this develop into a widely adopted standard. Apple uses a similar technology with their Airport Express devices for printer sharing, always been annoyed it was so restrictive in being able to connect to it.
It's using third-party APIs for the .torrent content and search engines for content.
But it doesn't even need that. You can use a .torrent or magnet URL from anywhere on the latest builds.
Just drag-n-drop a .torrent file onto the UI or simply paste (Ctrl-V / Cmd-V) a magnet URL that you already had on your clipboard and it will gladly attempt to live stream any arbitrary torrent.
The built-in video player generally works the best with .mp4 video files, but I've seen it successfully stream other media types as well.
When the torrent file in question contains multiple media files, a file chooser dialog appears letting you select which one you wish to watch.
The application could literally be re-written at any time to use any torrent site for showing content.
.. and since it's open source, the genie is out of the bottle.
Tried them out in Chrome and they're mostly all the same though I do notice a slight jitter to the rendering in the smoke example.