Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes | Hacker News Reader

Logs in High Sierra Show Plaintext Password for APFS Encrypted External Volumes

mac4n6.com

461 pointsreimertz110 comments

What exactly happened to macOS development at Apple? There's always bad luck but Apple has had multiple very visible and very serious vulnerabilities over the last few quarters. They've made multiple grave errors with encrypted volumes. I don't think Microsoft with Bitlocker or Linux with dm-crypt has ever made mistakes as bad as Apple has made here and multiple other times.

Forget the stability issues, a lot of the vulnerabilities are very alarming. I'm by no means a cryptographer, I should not be allowed anywhere near any security sensitive code and yet of course I know that command line options are accessible by all. All it takes is a glance at ps to realize that this exposes the password so how exactly was this functionality added to both the UI and CLI without anyone realizing what a blunder this was? This reminds me of the bug where the System Preferences app would perform privileged operations by basically calling an undocumented API that would create an arbitrary file with arbitrary data and arbitrary permissions (including SUID) as root. What's worse is that Apple already "fixed" a vulnerability in that API when in reality all they did was modify the API client to not run if the user wasn't root.

Why does it seem like there's no real oversight on macOS development anymore? An implementation bug or a complex design that leads to a vulnerability is one thing but so many of these vulnerabilities should have stuck out as a terrible design from the start.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1775

In my honest opinion senior developers quit from Apple long time ago (or was fired).

Then missing labor force was quickly reinforced by rushed hires of unskilled juniors.

> Why does it seem like there's no real oversight on macOS development anymore?

It may seem like that, but don't forget 15 years ago Mac OS X 10.3 erased external FireWire drives.

http://kottke.org/03/10/important-glitch-in-apples-panther-e...

https://web.archive.org/web/20031202034911/http://www.apple....

> external

An upgrade to the beloved 10.6 could potentially outright rm -rf your home dir. I was unaffected but it did make me retrospectively shiver when I learned about that bug post-upgrade.

Still, the frequency of those goofups seems to be getting worse, possibly amplified by the growing expectations in what looks like to be an increasingly hostile digital environment.

Didn't Apple essentially get rid of their MacOS team by taking them off it full time and putting them into the iOS team? (So they essentially had to apply their time between the 2).

So much this. Teams are probably smaller than we realize, and the really great people get shuffled around.

Got to pay off that debt one of these days, but 'not today' I guess...

Actually it was almost the opposite. In this case I think you are remembering the events of one release where Apple had to delay an iOS release and pull more resources to get it thought. A couple minutes of searching has not found it for me.

But in general the motion has been in the opposite direction. In the beginning iOS was its own project, and had a dedicated staff that took from MacOS (both staff and code) and did their own things with them. Once iOS was successful they decided to merge the parts that made sense to merge, and did so back into the MacOS teams.

So there are a lot of teams that are shared between MacOS and iOS projects, and a long-term goal of merging as much of the codebase into one as makes sense (to Apple). An example of this is APFS, which was partially written to resolve the differences that had grown between the MacOS and iOS versions of HFS+.

I think that they want more features to differentiate their OS. And with focus on features quality will be inevitably lost, because sometimes you must stop, review stuff, refactor, fix all bugs, but it takes time and it's hard to justify that time to management which wants more features, not "useless" work. Current situation with Apple seems like a classic example of technical debt striking back.

My theory: the NeXT developers who were around for osx v10.0 and around then have all retired.

I understand what you're trying to say but still, 10.0 was quite unusable at the time due to performance and stability issues ;-)

That's fair, but I think simply the fact that a badly behaving application couldn't bring down the entire OS was so revolutionary that people overlooked the performance issues.

Most of worst issues were sorted out by 10.1.

You don't even need to look at security vulnerabilities to wonder what happened to macOS development at Apple.

My wife recently bought a mighty mouse. It worked for a few days, but then macOS would fail to associate with it via Bluetooth unless it's plugged in via the lightning cable, in which case it's unusable, the connector being on the side that normally sits on the table.

Anyways, after a quick Google, I found a workaround that I couldn't believe would work, but I tried it anyways: open preferences, and check off "Allow Handoff between this Mac and your iCloud devices". ... and it worked instantly.

My wife doesn't even have an iCloud account...

The problem (and workaround) has been known for at least 4 years.

There are other problem known for years and no fix in sight. ( Last time I checked )

Having Whatsapp Backup using iCloud Drive ( By Default ) and using iCloud on Mac would means you download (cache) these iCloud content on your Mac, and you would be downloading 10s GB of Whatsapp backup to your Mac, every single day if you have Whatsapp set to auto.

It is not a problem if you have an fast internet connection and you wouldn't feel the difference. If you have a slow connection your Internet will literally come to a halt. Even worst if your internet connection is dependent on 4G.

Imagine 10M Whatsapp user are also a Mac user. Even at 1GB per backup, that is 10PB /Day wasted.

Or this awesome issue on any of the newer MacBook Pro laptops, if you plug or unplug any USB devices while the system is either going into or recovering from sleep mode (I.E. after you've closed the lid, but before you see the login screen again after opening it), it will randomly kernel panic. I spent almost a month trying to figure out why I would randomly get a kernel panic in the morning since my evening routine was to close the lid, disconnect my keyboard/mouse/monitor, and then in the morning do the exact opposite (plugin keyboard/mouse/monitor, open lid). Once I read about the issues with USB devices and sleep mode I changed my routine to first open the lid, wait for the login screen to show up then plugin all the USB devices. Since I made that change I haven't seen a single kernel panic.

Thank you so much! Now I know why half the time after a meeting when I connect my laptop again it'll simply hang then shutdown. (I didn't see the panic since it's clamshelled)

Since we're complaining about stupid stuff that's broken in macOS that shouldn't be, I'll add my Ethernet problem. Apparently, it's no longer supported to move between Thunderbolt Ethernet adapters without rebooting.

I have 2 Thunderbolt Ethernet adapters, one at home and one at work, and if I move between them my wired Ethernet connection stops working. The hardware is working fine and it even shows up properly in System Report but the networking stack is completely brain dead. One "solution" is to unplug the adapter, turn off wired Ethernet, wait 30 seconds, plug the adapter back in, turn wired Ethernet back on. Or I can just reboot.

This started happening in 10.12.x and I've filed a bug report for it with every release. Still no fix. WTF?!?

This is not really new. Apple's file vault passwords could be greped from the page file for many, many years, for example.

There is just more reporting of security incidents and more customer awareness.

I still like to imagine that there is some bright eyed and eager Cal or MIT grad who goes to work at Apple because they are first and foremost a Mac user - and haven't done iOS development.

Working full time on macOS might not be all that exciting, but it's the foundation that holds the rest of the house up.

It seems there's nobody with the clout at Apple to be able to say, "No, it's not good enough."

This isn't the first time they've logged passwords. Back around 2014, I found that they were dumping apple id passwords into one of the log files for iBooks (CVE-2014-1317). It was dumping the request body in hex for a redirected login request.

Fixed in 10.13.2 - but wow, was High Sierra ever a sloppy release.

It’s appallingly sloppy. I can’t say I’m regretting my switch to essentially holding off on major OS upgrades until just before the next one is released. I wish Xcode’s current version still supported the most recent two OS versions, though.

how do you deal with the constant update prompts? ignoring them, or is there some defaults system key that can be used to turn them off?

https://appletoolbox.com/2018/01/disable-macos-software-upda...

You rock, thank you very much.

Shame on Apple for the "control click on a hidden control" design pattern in order to stop the update messages. After not seeing an option to hide it, my morning ritual lately had consisted of clicking "Details" button and then quickly CMD+Q'ing out of the MAS dialog that popped up. Glad it's finally disabled, but really kind of ridiculous that it was literally a hidden option.

Actually, I just tested this. And it's not a control-click, it's a right click. The person that wrote it probably uses the old control click to right click paradigm.

Thank you!

The post mentions that it's also back in some cases on 10.13.3 - which is probably why this post came back up

> This is still vulnerable on current versions of macOS 10.13.3 when encrypted an ALREADY EXISTING unencrypted APFS volume

Only partially.

Sloppy and marketed as a stability build. There were hardly any new features in it.

Yeah, they just deployed a whole new FS to 100s of millions of users, in record time, with almost zero incidents.

Hardly any new features...

Well... Almost zero but not quite. I remember it causing a lot of trouble for us using Vagrant for development, since the upgrade automatically (and silently) converted the FS to APFS on supported devices and broke all Vagrant's synced folders that were using NFS. The bug was only fixed in 10.13.2. https://github.com/docksal/docksal/issues/377

That's technically impressive but it's not much of a feature.

What new features do users gain from the new file system?

being able to duplicate a 1GB directory in an instant

Is that a new feature? Isn't that just a performance improvement?

"What are these 'car' things? Do they really offer new features over horses? Isn't that just a performance improvement?"

It is most certainly a new feature.

APFS is copy-on-write, so when you duplicate a folder, it happens instantly regardless of how big it is because it doesn't have to make a copy until you start modifying the files. Moreover, because of COW, duplicate folders don't take up any extra hard-drive space. I literally just duplicated a 100 gigabyte folder to test, it completed instantly and I'm not using any more drive space than I was before. It will only start using drive space if i start modifying the files.

APFS is seriously cool (there are many other features besides this). It's not revolutionary (ZFS and Btrfs did all this before), but it's miles past HFS+. Apple has needed a new filesystem for more than a decade, and I'm glad it has finally happened, even if the OS update that brought it sucks pretty badly.

Optimized for SSDs, 64-bit inodes, faster timestamping (modification times etc), faster size calculations, faster cloning, safer copies, per-disk and file encryption, space saving sparse files, and more.

The main feature is that it is a modern filesystem that doesn’t carry around 25 years of baggage.

That doesn't mean anything other than "it's new which is somehow better."

It implies the design isn’t compromised by decisions that only made sense 25 years ago. For instance originally HFS didn’t even have journalling, it’s bolted on and not integrated.

It looks like the replacement has been compromised by other things however

Certainly not transparent file system compression. Can save developers couple 10 GBs but hey (source code, binaries, debug symbols, all compress nicely).

> new FS [...] in record time

That's an odd brag. I might be from a bygone era but it used to be the case that filesystems were particularly conservative and rollouts equally so. Getting one deployed in "record time" is hardly difficult because everyone else is so conservative it can take tens of years in some cases.

Look at Microsoft's ReFS, available in Server 2012, 2012 R2, Windows 8.1, Server 2016 and Windows 10 and has had eight public versions. Yet even after all of that it isn't the default partition type for Windows installations, and Microsoft only recommends it in specific circumstances[0].

So congrats to Apple's record time but I like my filesystems like I like my Toyota, reliable.

[0] https://docs.microsoft.com/en-us/windows-server/storage/refs...

It isn't the default version because currently it can't be booted from.

ReFS is a pure storage-style File System, and it's been full of headaches since release for those trying to use it as such. Comparing it to APFS isn't really reasonable as they're meaning to accomplish two different goals both systems. (Keep in mind, some of the bugs that ReFS had included silent corruption on files over 2 TB, which is kind of important for even the upper-end of the small business spectrum when it comes to data. [1] Even with that many technical previews and idling in beta for many iterations, they missed a pretty big show-stopper for ReFS, which has no built in volume repair since it's not supposed to break. (To clarify, there is Integrity Streams, but it's more that if you still see corruption with Integrity Streams running, MS has no more tools in its kit to assist)

I get what you're saying, you don't want to watch a FileSystem do the 200 meter, you wanna see it's averages across several marathons, and I agree. However, what is important to take from such an install base is that so far the reports have been embarrassing implementations of stuff around the filesystem, not the filesystem itself not doing what it should. The fact that users aren't howling about data silently corrupting or extreme system slowdowns is a fairly good portend thus far, Apple's sloppiness on the surrounding code not-withstanding. APFS being stable doesn't excuse the rest of Apple's mistakes, but I would say separate the two; it's pretty clear APFS was a pretty important project for them, and it's clear where their attention was.

[1] - https://blogs.technet.microsoft.com/filecab/2017/01/30/windo...

How’s that Takata airbag treating you?

Hope it’s as reliable as the acceleration is “unintended”… http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...

"Takata airbag"

That is an interesting recall. I was thinking about it today as my girlfriend is getting one replaced on her car right now. She commented on the incompetence of repair people these days and how they didn't even know if the repair was going to take one day or a week.

With the death toll from the airbags at only 22 globally so far [1] and maybe a few hundred injuries [2] and a total number of recall repairs at 65-70 million [3], you can bet the number bad repairs are going to cause more deaths than if they had not done the recall. Plus the cost of the recall in the billions of dollars that could have done a lot more good. I guess the lawyers are coming out alright though.

[1]http://www.thedrive.com/sheetmetal/18154/death-toll-continue...

[2]https://consumerist.com/2015/04/27/takata-airbag-defect-now-...

[3]https://www.nhtsa.gov/equipment/takata-recall-spotlight

>That's an odd brag. I might be from a bygone era but it used to be the case that filesystems were particularly conservative and rollouts equally so. Getting one deployed in "record time" is hardly difficult because everyone else is so conservative it can take tens of years in some cases.

Point missed entirely.

The "hard part" they've managed is getting it right (with few/no incidents) in record time, not just getting it out on record time.

> I like my filesystems like I like my Toyota, reliable.

Not sure if you're deliberately joking or not, but the quality of software in Toyota cars is hilariously awful.

There was a stunning writeup by one of the people who got source code to investigate the unintended acceleration issue a few years back. [1]

IIRC, as part of the cruise control, if they decided the car was going too slow it'd be given a command to accelerate. There was a second process which checked the speed, and once the car was going fast enough, it'd kill the accelerate process. Except the check/kill process would regularly crash, so the car would be told to accelerate and then nothing would be there to tell it to stop. Don't worry though, there's a software watchdog process to catch this! Except the watchdog ran under the same process manager as the check/stop script, so when the stop script crashed it'd take the watchdog process down too - and this was only the top of the iceburg when it came to problems.

tldr: software quality in Toyota's was abysmal and there's little reason to believe it's gotten fundamentally better.

[1] https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_...

[1.5] Actual Talk: https://betterembsw.blogspot.co.uk/2014/09/a-case-study-of-t...

This is missing the point. He/she isn't talking about the software.

There is an old car-vs-computer joke about this I'm going to butcher, but I think it is more in line with what the parent meant:

Computer Engineer: If cars advanced as fast as computers, they'd go mach 1 and get thousands of miles to the gallon by now!

Car Engineer: If cars progressed like computers they'd inexplicably die on you and you'd have to uninstall and reinstall your tires to get it to drive again

Very Interesting. Thanks!

> with almost zero incidents.

Sparse files are hopelessly broken, prompting Docker for Mac to roll back to qcow2 when using APFS[0] (HFS+ sparse files are fine).

[0]: https://docs.docker.com/docker-for-mac/release-notes/#docker...

EDIT: reference

HFS+ sparse files - now that’s a contradiction in terms.

HFS+ sparse images, sorry (not quite the same as sparse files, but here DfM uses sparse files are used to create a raw image, so I wanted to lift some possible confusion, and tripped on)

That's pretty bad. It's been known for decades on other Unix systems that you shouldn't pass passwords by command line parameter, or even support doing so. I guess no-one told Apple.

Exactly. More to the point, even if it doesn't log it any more, I bet it's still on the command line itself.

The usual trick here is to pass it as an environment variable instead of cmdline, that can be done without much effort so they're probably doing that.

Bad idea

cat /proc/<pid>/environ

Wait, what's your threat model? Surely you're not imagining that you can pass data from one process to another without root being able to see it? (On Linux, since you're using /proc.)

Other users' processes can't see /proc/$pid/environ, unlike using cmdline.

Don't recall right now for sure, but doesn't ps have an option to display the processes environment? I've done it by accident a few times and it does not take root.

It has an option (e) to attempt to display environment variables, but ps is just a program that reads from /proc, and the kernel enforces isolation of environment variables by breaking reads to /proc/pid/environ for processes you don't own (or more precisely, can't ptrace), so `ps e` can't show anything for those processes.

  λ whoami
  cjb
  λ cat /proc/1/cmdline
  /sbin/init%
  λ cat /proc/1/environ
  cat: /proc/1/environ: Permission denied

And if you can see /proc/*/environ, you can probably attach to the process via gdb and read the secret from the process memory. At that point, it's not relevant how the secret was passed to the process.

Unless the secret is some kind of one-time token, or time based token, but then it's also not relevant how the secret was passed to the process. It's invalidated soon.

> On Linux, since you're using /proc.

Exactly; macOS doesn't use /proc.

Not to disagree, but could you provide some references to the statement?

>> It's been known for decades on other Unix systems that you shouldn't pass passwords by command line parameter

> could you provide some references to the statement?

If you search the Usenet archives, you can find many discussions about this. It's one of those topics that came up frequently in the comp.unix newsgroup as early as 1991 that I see in some messages.

Usenet discussion from 1994:

"ps e gets you a processes environment. It is totally unsafe to store anything that should be secret. if there needs to be secret data, the best way to get it is with scanf(), once the program is running."[1]

And here is the Secure UNIX Programming FAQ from 1999:

"A security hole related to FreeBSD's 'ps' utility. The utility would allow users to view another process' environment variables. Consequently applications like pppd that accepted passwords via environment variables became vulnerable to unauthorized release of privileged information attacks. In fact, thehole was not related to 'ps' if you think about it critically. The application that places privileged information in the environment variable is at fault."[2]

[1]https://groups.google.com/forum/m/#!search/ then search for "ps shows command line parameters" (for the exact message, search for "ps e gets you a processes environment")

[2]http://faqs.cs.uu.nl/na-dir/unix-faq/programmer/secure-progr...

If you run the ps command you can see all processes with all the command line arguments. They’re not secret, which is why you shouldn’t put passwords there.

Now typically these processes only run for a short time so it’s difficult to catch passwords manually but it’s predictable so a script can.

So what is the proper way?

Either store them in environment variables or pass them through file descriptors, such as standard input.

Note that you do need to take care to clean up the environment if you create new, unprivileged subprocesses or these secrets may leak.

Thanks.

But really, how big of an attack surface is there? By that I mean, how many people have external encrypted APFS drives?

By my estimation, I would guess the number is smaller than people think for a few reasons.

1. How many people who aren't technically saavy have external drives at all? If they do, it's probably a Time Machine volume. Which leads me to my second point...

2. Directory hardlinks - the tech which makes TM work - don't exist on APFS, so a fair number of these drives are probably still using HFS+, and last I checked, external SSDs of any sufficient capacity are still pretty costly, which brings me to the last point...

3. Given that APFS is really SSD-only (with a small asterisk for Fusion Drives), converting a TM volume on a spinning disk is a recipe for pain.

I'm not excusing the bug, only reiterating that its effect is probably less than you might imagine among people who aren't nerds (or HN readers for that matter).

I am still on Sierra and a few weeks ago found a fix for a problem that Apple introduced apparently in "good faith". I had been wondering for a while why my mid-2015 maxed out Macbook Pro Retina didn't perform well when doing programming in XCode etc. So finally on a weekend I decided to find out the problem, and saw that "kerneltask" is using 500% CPU ...

Apparently, Apple has programmed kerneltask to grab available CPU resources when it determines that the CPU might overheat due to other tasks stressing the CPU too much. In my case though, there was no danger of overheating (running somewhere between 55 and 60 degrees), but kerneltask just reacted to my 4K monitor being plugged in in addition to me using the internal laptop retina display. As soon as I would unplug the monitor, kerneltask would release CPU resources and go back to < 10% !!

So basically, shitty programming on Apple's part had rendered my laptop unusable for quite a while.

Luckily, I found this article which worked in my case also: https://www.davidschlachter.com/misc/kernel_task

My laptop is now a joy to use again, but I can't believe that something like this remains unfixed for so long. I've seen many people on message boards running High Sierra with the same problem, so this just doesn't seem to get fixed.

Why is the kernel even playing such a stupid game to "manage" temperature? I would have though Intel temperature management was idiotproof in the "You literally don't even have to touch it" way.

Closed source disk encryption products: Not Even Once.

Please don't link to mac4n6, it serves malware on some page loads. The article author is aware of it but apparently doesn't have the ability to fix the issue

What kind of malware did you run into?

It was a malware dropper masquerading as a Firefox update. I hit it when I visited this page a few days ago and so did someone else.

You can see it here — https://twitter.com/iamevltwin/status/976627634066132992

Not calling you out but I'd like to see a source for this. A quick web search for mac4n6 malware didn't turn up anything.

Source: Me, and at least one other person on twitter after I mentioned it there.

Here is the source — https://twitter.com/iamevltwin/status/976627634066132992

To save others a click, that's the author of the website confirming that the site was compromised by a code injection attack via Squarespace control panel.

After doing a quick sweep of the network and processes, I didn't find anything overtly malicious (unless you count 6 MB pages for a blog, 150k lines for squarespace's JS, and 3000 rules over 400KB).

When I last examined it, the malware was loading from a domain called eventsbysteph. If the page still pulls js from there then the malware's still around (doesn't activate on 100% of loads)

I'm only getting typekit, squarespace, the auther's other domain for the blog, and google analytics -- with ublock off for all pages.

To be fair, does linux/unix system also has similar thing? If the cmd tool supports passing the password as argument, it is supposed to be logged in whatever logging facility in the system. I am not aware of a feature to sanitize the password argument.

The usual way is the cmd tool supports supplying password as password prompt, and the user should always supply the password in the prompt except testing purpose.

So, I think it is more like a UI problem then a vulnerability.

So, I think it is more like a UI problem then a vulnerability

It's both, it's a vulnerability in how the UI calls the CLI command. Passing the password on the command line is bad for a number of reasons, not just because it can end up in a log file.

I could be wrong but I do not think dm-crypt supports CLI passing of the passphrase. It uses interactive prompt only.

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_...

At some point, certain things ought to add up to become a firing offense. I don't feel confident that Apple is going to get things much better without drastic changes right from the top. If anyone at Apple senior management is reading this, please do a shakeup and a rethink. It's badly needed for the software you have been producing.

Just curious, could Apple actually ditch Darwin and use linux as their kernel? I'm not sure how the licensing works in regard to their proprietary stuff that may have to touch the kernel. It seems that if they aren't going to invest the money on MacOS dev teams, this may help them out by not having to do as much kernel dev stuff.

Darwin is a custom mash of BSD, not linux. You could use a BSD kernel, but you would have to customize it a lot for device and feature support... which is how we got the Darwin kernel in the first place. They're already including some modern BSD projects.

From "Design Principles of the I/O Kit": https://developer.apple.com/library/content/documentation/De...

> "OS X is largely the product of two strains of operating-system technology: Mac OS 9 (and its predecessors) and BSD. Given this pedigree, one might have expected Apple to adopt the device-driver model of Mac OS 9 or FreeBSD. Instead, Apple chose to redesign the model. Several reasons motivated this decision.

> "First, neither the Mac OS 9 driver model nor the FreeBSD driver model offers a set of features rich enough to meet the needs of OS X. The OS X kernel is significantly more advanced than its Mac OS precursors; it handles memory protection, preemptive multitasking, multiprocessing, and other features not present in previous versions of Mac OS. Although FreeBSD is capable of handling these features, the BSD model does not offer other features expected in a modern operating system, including automatic configuration, driver stacking, power management, and dynamic loading of devices."

It sounds like switching to a different kernel, and extending it to support everything that the Mac needs, would be a lot more work than finding and fixing the issues they have now. 3 nasty security bugs in 6 months is bad, but how many would they have if they changed kernels entirely? Mac OS X 10.0 sure wasn't bug-free. (For fun times: try creating a new user on 10.0 with login "root".)

I suspect it's very similar to why they didn't switch the display layer to X11: https://developers.slashdot.org/comments.pl?sid=75257&cid=67...

Even the UI issues Apple has now are appalling let alone bugs they don’t even seem to know how to consistently have a lock button across devices for example. If the basics are poorly thought through, how is something like security going to be done properly?

I guess that’s the reason why APFS is still only supported for internal volumes?

I don’t get the implication.

Windows users have long waited a year to install new versions. If Mac users did the same they would have fewer such problems.

Windows 10, of course, gives you no choice but to install new versions immediately (besides enterprise deployments, of course). Apple's updates are getting sloppy, but at least they're optional.

Not if you paid for it (Pro version). I never install the latest Windows 10 right away.

Lots of Mac users wait before they upgrade. (Myself included)

I recently looked at stats for my app, and only around 60% of my users are on 10.13, 30% on 10.12, and 10% on older versions.

If you use your Mac professionally, there‘s no point in updating every year — it‘s always a hassle and a few weeks of upgrading 3rd party software and fixing random things that don‘t work any more.

If we are sharing anecdotes: it was never a hassle for me.

It seems quite a lot of people around here have a thing for El Capitan. Coincidentally this is the last one called "OS X".

Confirm. El Capitan is the last good and stable version.

Does 10.11 still get security and reliability updates?

As for 10.13. If an OS changes filesystem, its often recommended to wait (same with in the past e.g. FAT32 -> NTFS, Ext2FS -> Ext3FS, Ext3FS -> Ext4FS although IMO the latter two went flawless for me).

The reason I went for it -even though benchmarks of encryption + APFS specifically were abysmal compared to encryption + HFS+ whereas no encryption + APFS or no encryption + HFS+ were acceptable differences)- is because it was already tested on iOS.

> Does 10.11 still get security [...] updates?

Yes.

https://support.apple.com/en-us/HT208465

Anyone have ideas how to detect passwords in logs?

Any ideas how to detect passwords in logs?

Reply on news.ycombinator.com