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.
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.
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
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.
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.
Certainly not transparent file system compression. Can save developers couple 10 GBs but hey (source code, binaries, debug symbols, all compress nicely).
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.
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.
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.
>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.
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
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)
You have to give Apple credit that they showed some restraint and didn't just add all the features to their new file system that they found in a table on some Wikipedia page.
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.
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.
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.
>> 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")
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.
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).
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
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)
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?
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.
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.
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.
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.
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.
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.
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).
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.
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.
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?!?
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.
.... in a galaxy far far away ... an egocentric narcisistic CEO with a god complex and hell-of-a-neck for usability would never agree with the full extent of what "external forces" were requesting from his company. Getting rid of him led to mistakes he'd never allowed to happen. But that's the price you have to pay when you are (due to product demographics aot) sitting on the most valuable private data in the world..not even a neverending chain of government-funded privacy PR stunts could make a difference.
/end
As a new-ish iOS mobile user, I was very dissapointed
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.
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.
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.
> "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".)
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.
122 comments
[ 1.6 ms ] story [ 223 ms ] threadShame 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.
Only partially.
Hardly any new features...
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.
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...
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...
Hope it’s as reliable as the acceleration is “unintended”… http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...
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
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.
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...
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
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
https://en.wikipedia.org/w/index.php?title=Comparison_of_fil...
cat /proc/<pid>/environ
Other users' processes can't see /proc/$pid/environ, unlike using cmdline.
I think the better solution is to read it out of a wallet into stdin
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.
Exactly; macOS doesn't use /proc.
> 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...
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.
Note that you do need to take care to clean up the environment if you create new, unprivileged subprocesses or these secrets may leak.
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 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.
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.
Yes.
https://support.apple.com/en-us/HT208465
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.
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.
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_...
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
Then missing labor force was quickly reinforced by rushed hires of unskilled juniors.
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....
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.
Got to pay off that debt one of these days, but 'not today' I guess...
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+.
Most of worst issues were sorted out by 10.1.
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.
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.
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?!?
There is just more reporting of security incidents and more customer awareness.
Working full time on macOS might not be all that exciting, but it's the foundation that holds the rest of the house up.
/end
As a new-ish iOS mobile user, I was very dissapointed
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.
> "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...