macOS 28 Will Drop Support For Encrypted Mac OS Extended Volumes (9to5mac.com) 90
Starting with macOS 28, Apple will no longer support encrypted Mac OS Extended, or HFS+, volumes. Users will need to decrypt them or reformat them as APFS to keep using them. 9to5Mac reports: In a new support document, Apple explains that starting with macOS 28, "the Mac OS Extended file system format will be supported only for volumes (disks and other storage devices) that aren't encrypted." In practice, this means users who currently rely on encrypted HFS+ external drives or other encrypted legacy Mac-formatted volumes will need to "either decrypt or reformat any encrypted Mac OS Extended volumes."
Apple doesn't explain the reason for the change. Still, the move appears to be another step in Apple's transition to APFS, its file system with built-in encryption support, which replaced Mac OS Extended as the default Mac file system in macOS High Sierra. As a result of this change, Apple says that starting with macOS 26, Macs might notify users when they're using an encrypted Mac OS Extended disk that won't be compatible with macOS 28 or later.
According to the support page, "the notification will identify the volume by name." However, Apple says users can manually confirm whether a volume is both using Mac OS Extended format and encrypted by following these steps [...]. Apple adds that "macOS 28 and later will continue to support unencrypted volumes that use Mac OS Extended format," and notes "Mac OS Extended is also known as HFS Plus (or HFS+)."
Apple doesn't explain the reason for the change. Still, the move appears to be another step in Apple's transition to APFS, its file system with built-in encryption support, which replaced Mac OS Extended as the default Mac file system in macOS High Sierra. As a result of this change, Apple says that starting with macOS 26, Macs might notify users when they're using an encrypted Mac OS Extended disk that won't be compatible with macOS 28 or later.
According to the support page, "the notification will identify the volume by name." However, Apple says users can manually confirm whether a volume is both using Mac OS Extended format and encrypted by following these steps [...]. Apple adds that "macOS 28 and later will continue to support unencrypted volumes that use Mac OS Extended format," and notes "Mac OS Extended is also known as HFS Plus (or HFS+)."
Re: (Score:2)
Re:Remove Encryption? (Score:5, Informative)
They're not removing encryption support, they have a modern filesystem that you can use with encryption. They're only dropping it from their deprecated 1990s-era filesystem. They're telling people to move to the modern filesystem if they want to use encrypted drives.
Re: (Score:1, Informative)
They're not removing encryption support
Except they are. That is the one and only thing they are doing. They just aren't removing it from filesystems you care about, and you don't care about other people.
They're only dropping it from their deprecated 1990s-era filesystem.
And yet they are not dropping support for that filesystem without encryption, which is why Apple is literally doing what you said they are not doing. Not only can't you handle more than one button, you also can't handle more than one idea.
Re:Remove Encryption? (Score:5, Insightful)
Realistically, it's not that rare to change your secure volumes, or move them between services. Changing from VeraCrypt to KDE Plasma Vaults, or, changing the encryption standard in use, something I've done a few times. Supporting legacy just sucks, and there are times when you simply have to, but if you can prevent legacy support, do it.
Re: Remove Encryption? (Score:5, Interesting)
There was another project where to use a Microchip radio transceiver, you had to send the data, then wait Xms, then trigger a register, and yada yada yada, which was due to a bug in the transceiver. They fixed that bug ~1 year after, but we had shipped the old boards into production, so for the life of that product there were two radio functions. One to send via the old radio logic, and one that didn't need that junk, but, to update functionality, you had to add it to both functions and work around it.
Luckily that product died mid-COVID, but, I can keep going on of N products with these stupid, idiotic, annoying, but understandable strangeness in them. So my guess is: They want to clean up the code-base, and get it running in a slimmer, cleaner fashion without the bloat.
Re: (Score:3)
switch( media ) {
case floppy:
doFloppyStuff();
break;
case CD:
doCDStuff();
break;
}
(I can't get tabs in there, but you know what it's saying)
They had this one ginormous multi-paged function that interspersed floppy and CD support in the same function. I undertook the rewrite fo
Re: (Score:2)
I've also said multiple times that ~50% of your code should be comments, explain what you're doing, why, what you're thinking,
Re: (Score:2)
Maybe there was a reason on the original you had to do something stupid
No. It was stupid then, too.
Bad programmers write bad code, in the past and present.
Re: (Score:2)
Re: Remove Encryption? (Score:2)
I don't doubt that you've worked on bad code, but Apple has more money than God and can afford the developer time to fix it.
Re: (Score:3)
I don't doubt that you've worked on bad code, but Apple has more money than God and can afford the developer time to fix it.
The reason why they have that money is that they know when and where to spend it.
Rewriting HFS+ Encryption from the ground-up to support the 1,000 Users worldwide that somehow live in a tiny nexus of those still relying on HFS+Encrypted Volumes; yet for some unfathomable reason, cannot simply convert those Volumes to APFS, with or without Encryption.
Apple has a Step-by Step Tutorial on the Process:
https://support.apple.com/en-u... [apple.com]
Better hurry; you only have TWO YEARS to get it done!
Re: (Score:1)
Want to talk about ReiserFS?
Re: (Score:2)
RFS is dead. Like his wife.
Re: (Score:2)
Can't be maintained? Lol
Not worth it to rewrite from scratch; and too rickety to just ignore it anymore.
Re: (Score:2)
HFS+ has encryption through a bolt-on process.
APFS has encryption designed in from the core. They don't want to maintain the bolt-on that is only used for legacy / external drives any more, on the way to getting rid of HFS+ altogether.
HFS has been around since the 80s for fucks sake. It's okay for us to leave it behind when they've already done the heavy lifting of automatically converting everyone to APFS years ago.
Re: (Score:2)
Re: (Score:2)
My guess, and I don't use macOS, or any Apple product, they want to remove the encryption code to clean up possible future security issues. I would bet they have a separate process / driver just to handle HFS+ encryption, that's not being maintained, or, can't be maintained due to previous compatibility requirements, so they're just forcing users to move.
Realistically, it's not that rare to change your secure volumes, or move them between services. Changing from VeraCrypt to KDE Plasma Vaults, or, changing the encryption standard in use, something I've done a few times. Supporting legacy just sucks, and there are times when you simply have to, but if you can prevent legacy support, do it.
You’re exactly correct.
And to make it even clearer, apparently the HFS+ Encryption handling was kind of spaghetti-coded into several places in the OS; and with Apple doing a big push to remove all x86 Support by 2028, I’m sure there has been an additional directive to identify other things that should be looked at while they have the hood open. . .
APFS Encrypted Volumes aren’t going anywhere; nor is full Read/Write/Format support for regular HFS+ Volumes.
Time marches on. . .
Re: (Score:2)
Re: (Score:2)
Exactly, changes have to happen, so just move your data and be happy. It's not a weekly, monthly, or even yearly thing. This is a once every decade change, and who can really complain? I'm sure some outlier exists that has a very specific reason to need HFS+, but the vast majority of people can't truly be affected. Even if you have a 30TB volume you would need to move, just buy a drive from Amazon, do the move, then return the drive. For some odd reason, Amazon will let you do that, not really sure why, but you can even be honest about it in the return information.
Not only that, but HFS+ Timestamps simply run out of Dynamic Range in 2040; so. . .
Buy a nice 12 TB HDD from Amazon, do your Conversions, then either return it or turn it into your new Time Machine Backup Drive!
Re: (Score:2)
Re: (Score:2)
100%
Thanks for being a NON-Apple-Using Person WITHOUT some inexplicable vendetta against all things Apple!
Mighty Rare around these here Parts. . . :-)
Re: (Score:2)
Re: (Score:2)
No worries, I like Apple's approach of the unified ecosystem, and being its Unix, that's just a bonus, but, I don't agree with or subscribe to the motives, where you have to submit to hard line tracking and telemetry collection. Apple gets credit, they don't lie, they don't hide, they don't obscure, they're honest. They've built objectively great hardware, but it's locked in, locked out, and I can't support that.
Well, I respect your opinion; but in my 50 years of being an Apple User (and the User of other Platforms) I have found that their superior security and almost total lack of Malware, as well as their best-in-class OSes and unbeatable Integration to be well-worth any unobtrusive and anonymized data collection they may do for their own marketing and product development purposes.
Re: (Score:2)
Re: (Score:2)
Fair enough, I think I've used a Mac for all of 10 hours, or some small amount of time over the last 30-years.
Come on In; the Unix is Fine! ;-)
https://www.howtogeek.com/4415... [howtogeek.com]
https://manp.gs/mac/ [manp.gs]
https://developer.apple.com/li... [apple.com]
Of course, there are package managers that make this far easier. Here’s a Popular one:
https://brew.sh/ [brew.sh]
Enjoy!
Get yourself a used M-series Mac mini and have some fun!
Signing up as a Registered Developer is Free, as are the Tools.
This is the Front Door to the Apple Development Multiverse ( 8-D ). This Site is HUGE
https://developer.apple.com/ [apple.com]
Re: (Score:2)
Re: (Score:2)
They are not. The post being responded to alleged that encryption was being removed, it is not. They are removing an encryption option from one filesystem, encryption still exists and is not removed from MacOS, which was the claim. Otherwise how do you interpret "What could possibly go wrong?" or the follow-up "The N$A got to them, guaranteed." The insinuation is clear.
Still, makes no sense to me.
ceci n'est pas un removing (Score:1)
encryption was being removed, it is not. They are removing an encryption option from one filesystem
so they are removing the encryption but they are not removing it, they are just removing it without any removal happening in the process. got it, thanks for this illuminating clarification.
not that it matters, mind, apparently i'm far too dumb to be an apple user and this sophisticated level of reasoning is way out of my reach.
Re:ceci n'est pas un removing (Score:4, Insightful)
The FS itself is likely not being removed because it is one with implementations outside of MacOS (For instance my camera can be hooked to an HFS drive) But HFS Encrypted was always a take-your-life-into-your-own-hands thing. If you got a sector corruption, thats an unrecoverable loss of the whole FS. Whereas unencrypted, it just took a rebuiold of the FAT and you could at least recover the majority. It *highly* unlikely anything other than MacOS supported the encryption.
While its a PITA to lose that support, theres really not a lot to lose by doing so, whilst losing unencrpyted HFS breaks a lot of third party device integrations.
Re: (Score:1)
And yet they are not dropping support for that filesystem without encryption, which is why Apple is literally doing what you said they are not doing.
I cannot mod you up even though I have points, this new /. WEB site really sucks. So I posted, I guess Apple Fanboys are out in force.
This highlights yet another reason to avoid proprietary Operating Systems. People bought these probably overpriced items and encrypted them for a reason, now Apple is saying "TFB, you cannot use the hardware the way you want.". What is next, dropping support for that hardware ?
Yet another reason people should move to Linux or a *BSD.
Re: (Score:3)
What's stopping users from converting the drives from HFS+ encrypted to APFS encrypted? They have a process to do that in-place. People can keep using their existing drives, and can still have them encrypted.
Re: (Score:2)
What's stopping users from converting the drives from HFS+ encrypted to APFS encrypted? They have a process to do that in-place. People can keep using their existing drives, and can still have them encrypted.
Nothing.
Here’s Apple’s Tutorial:
https://support.apple.com/en-u... [apple.com]
Re: (Score:2)
They're not removing encryption support
Except they are. That is the one and only thing they are doing. They just aren't removing it from filesystems you care about, and you don't care about other people.
They're only dropping it from their deprecated 1990s-era filesystem.
And yet they are not dropping support for that filesystem without encryption, which is why Apple is literally doing what you said they are not doing. Not only can't you handle more than one button, you also can't handle more than one idea.
Oh just stop it!
They are removing HFS+ Encryption Support because it was apparently a bit of a Kludge; with pieces-parts scattered in Several places in the OS. With the current push to remove all vestiges of x86 Support from macOS in time for macOS 28, I’m sure there was a general call within Apple to also look for deprecated or poorly-implemented stuff for review. II just seems pretty logical to remove some ugly Deprecated Kruft at the same time, no?
OTOH, The reason why general HFS+ Support remains s
This (Score:4, Interesting)
Re: (Score:2)
Yes but no.
They could have left support for old drivers. They're dropping support for the encrypted drivers they used to support.
For your comparison, the thing about encrypted overlays on file systems is that the encrypted overlay works independently. People will move simply by virtue of using a natively-encrypted file system is easier and more convenient than an overlay system. But nothing precludes the use of an overlay if people want to do it themselves.
In this case there is no more support. It's a m
Re: (Score:2)
Legacy systems aren't going to run macOS 28, since the last release to support Intel processors is macOS 26. This will only affect legacy archives, so, older external disks. Assuming they didn't use exFAT, but you didn't get native encryption in macOS with that either.
Re: (Score:2)
They could have left support for old drivers.
That is a bad idea. Legacy code is a security nightmare. But I guess it's only bloat, bad security practices, and all around a Bad Thing (tm) when Microsoft do it right?
There is no reason to use this old kludge and every reason to migrate to something modern. If anything this is Apple saving idiots from themselves. Time to get with the times. You want to run a modern system do so in a modern way and don't impose legacy cruft on vendors to the potential detriment of all other customers.
Re:Remove Encryption? (Score:4, Interesting)
The problem is that APFS is designed for SSDs. It isn't great for spinny disks, and HFS+ has had a lot of improvements since the HFS/MFS days. It would be nice to have a filesystem with less overhead, especially because APFS doesn't provide any bit rot protection by checksumming.
It would be nice if Apple could "bless" FUSE-t or maybe make some type of IFS that doesn't require kernel extensions and weakening the OS security just so one can use another FS. Or, maybe Apple could offer some filesystems like ext4, xfs or $DEITY willing, OpenZFS. This way, Apple only needs to support a few filesystems, but if someone wants to use ZFS, that option is available.
Other operating systems still work with old filesystems. I can use FAT12 on a Windows Server 2025 machine. I can use the old `ext` or Minix filesystems directly on Linux, and xiafs. If I want to run the original MFS, I will need to jump through a lot of emulation hoops.
Re: (Score:2)
I think Apple should have converted to ZFS in the first place, APFS kind of feels like they decided to re-invent the wheel and missed out on some important stuff (like block checksums) in the process. I still think it's reasonable for them to drop HFS+ encryption support and tell people to convert the drives to APFS if they want to keep doing it, though.
Re: (Score:2)
Apple has had over a decade to tune APFS. APFS was announced around ten years ago, in 2016 WWDC. Back then, it was an advance because it allowed for snapshots, as well as immutable filesystems. However, APFS just (from what I see -- I may be wrong) hasn't really had anything major added. Even if checksumming is an option shipped off, it should be in place. Same with compression and maybe even deduplication, preferably a passive style like btrfs rather than active like ZFS, because Macs tend to be runni
Re: (Score:2)
APFS supports compression, but it's the same compression techniques (deflate, LZVN, LZFSE) that HSF+ supports. And it seems to be a slightly higher-level approach to compression than ZFS uses, making it only mostly transparent compression. So newer techniques that ZFS leverages, like LZ4 or ZSTD, they're not an option. Compression is such a no-brainer with ZFS (particularly with how fast LZ4 and ZSTD can be) that more and more distros/operating systems are enabling it by default.
Re: (Score:2)
ZFS :-)
Re: (Score:2)
I think Apple should have converted to ZFS in the first place, APFS kind of feels like they decided to re-invent the wheel and missed out on some important stuff (like block checksums) in the process. I still think it's reasonable for them to drop HFS+ encryption support and tell people to convert the drives to APFS if they want to keep doing it, though.
They really tried to convert to ZFS.In fact, there was even ONE version of OS X that had experimental Support for it.
Problem was, not only was ZFS not ready for prime time (not supporting Booting, plus large RAM requirements and several Bugs being a few of the problems), But the real Deal-Killer.was the fact that, just about the time Apple started getting serious about ZFS, along came Oracle. . .
Apple in no way wanted to be beholden to the whims of Larry Ellison; so, with that, they rolled-up their sleeves,
Re: (Score:2)
Please tell me you're mistaken. Bit rot is always a concern. I've had plenty of problems with SSDs developing weak blocks even though they are continuously powered. Maybe some drives will do "maintenance" to prevent this, but my experience with Samsung 830 series drives in particular showed massive losses in performance with old files if you don't do a full drive refresh every year or so.
Re: (Score:2)
I do not like the fact that APFS doesn't have bit rot protection, which is why I wish Apple went with ZFS. For phones and devices, maybe ZFS isn't optimal, but it should be an option.
I also wish APFS had the ability to scrub to catch the issues the parent poster mentions. Looking at fsck_apfs, I don't really see anything that not just checks the filesystem, but the actual data itself... and this isn't really acceptable for a modern filesystem. Many Linux distributions use btrfs as default, which does hav
Re: (Score:2)
It checksums filesystem structures, but not file contents. It's also designed in a way that makes it fragment very quickly (both the filesystem structures and file data), so it performs very poorly on media with non-trivial seek times or slow random reads. It feels like a bit of a one-trick pony.
Re: (Score:2)
Maybe some drives will do "maintenance" to prevent this
You misspelled "all drives". Your example here is from one of the very earliest days of SSD which was a wild west shitshow of dataloss. Those were the days of OCZ, the days of drives losing all data on power loss due to lack of capacitors, it's the days where people were sort of trying to figure out how to make a flash controller.
It's not at all relevant to an even decade old PC at this point, let alone something modern.
Yes bitrot protection helps a bit and is important on critical systems, but it's not rea
Re: (Score:2)
I can use FAT12 on a Windows Server 2025 machine.
FAT12 shares a lot of code base with FAT16 and FAT32, and even a significant chunk with exFAT. This is a very different beast to maintain than the difference between APFS and HFS+ with a dodgy encryption layer bolted on it (note that Apple has *not* depreciated HFS+).
I agree in principle with the modularising ability though. The difference though between what you list for the vendor is extreme. Note that while the minux file system is still available as a module to load, no vendor actively ships minux tool
Re: (Score:2)
What a great idea to remove one of the most used filesystems from your kernel. Apple really doesn't care about what their users want and need.
Re: (Score:2)
What a great idea to remove one of the most used filesystems from your kernel. Apple really doesn't care about what their users want and need.
HFS+ Support isn’t going anywhere. Just the HFS+ Encryption Support!
Who knows what will happen when HFS+ Timestamps run out of Dynamic Range in 2040? But until then, Unencrypted HFS+ Volumes continue to enjoy Full Read/Write/Format Support!
In the meantime, this is the recommended answer:
https://support.apple.com/en-u... [apple.com]
Re: (Score:3)
Get a grip. Anybody who cares about encryption either moved on to APFS long ago or won't be interested in updating to MacOS 28 anyway.
Re: (Score:2)
Exactly. HFS+ is used on spinning hard drives and those are mostly used on external storage and backups, and that means the drive will likely be used on different machines. Encrypting the drive complicates things and it may not even work on a different computer.
Re: (Score:2)
Or, they are at the beginning of deprecating HFS+ in favor of the APFS file system they've been using for root volumes for almost 10 years now.
Why should they continue supporting a botched-together implementation when they have a file system that was designed with encryption at it's core?
Re: (Score:2)
What could possibly go wrong?
Apple is becoming more MS every day.
They are removing support for the Deprecated HFS+ Encrypted Volumes ONLY.
APFS Encrypted Volumes aren’t going anywhere.
Apple moved from HFS+ to APFS as their Frontline Filesystem for macOS With macOS Mojave (10.14), back in 2018. They actually switched iOS to APFS a few years earlier. Starting with Mojave, Boot Volumes were automatically formatted as APFS.
The sky did not fall. . .
Also, Non-encrypted HFS+ Volumes continue to enjoy full read/write/format support in macOS, and there is no reason to expect
HFS+ is ancient (Score:5, Informative)
HFS+ was introduced with MacOS 8.1 in the late 90s. It doesn't even support dates past the year 2040. It makes sense for them to start phasing it out.
Re: (Score:3)
start phasing it out.
Stopping support of a specific feature but not the entirety of the technology can be part of a phase out strategy rather than a hard cutoff.
Re: (Score:1)
Finding a new encrypted filesystem must be upsetting you.
Re: (Score:2)
Apple's official method is multi-step.
First, you decrypt the volume - you control-click the disk and click Decrypt. Wait for it to decrypt (takes hours).
Then you convert it to APFS, the current filesystem Apple uses.
Then you enable encryption on APFS and wait for it to encrypt.
Chances are the HFS+ encryption is likely outdated and weak and sometimes it's better to not pretend. Or it was a hacked addon to HFS+ which didn't support it initially. Like ho
Future data recovery will be difficult (Score:3)
Disposable (Score:2)
Re: (Score:2)
Re: (Score:2)
Not really. Nobody will need to dispose of anything because of this. Either they'll reformat to APFS (which they probably already did if they care about encryption) or simply not upgrade to MacOS 28 when that comes out a couple of years from now. HFS will have been deprecated for a decade by then.
Re:Future data recovery will be difficult (Score:4, Interesting)
The step in the "disposable computers" trend was made when it was designed with 32-bit time and date values [wikipedia.org] and doesn't support dates past February 2040. Getting people to switch over to a newer file system that won't just stop working in the future is honestly the opposite of that trend. A feature deprecation about a decade after the release of new tech is pretty mild in narrow Apple golden path.
And because of that narrow path, most people in the ecosystem are going to be pretty unaffected with the 6 to 8 year hardware support expiry. Mountains out of molehills.
The T2 chip may be the reason (Score:3)
The T2 security chip supports/enables APFS encryption (storing the keys in the secure enclave). HFS+ encryption is not directly supported by the T2 security chip hardware. So, if you want to trust the (Apple ecosystem) encryption, you need to move APFS.
APFS is a well respected (by the experts) file system design. While I wish Apple directly provided and supported Linux and Windows APFS drivers, that was never their responsibility, but there are 3rd party drivers available.
Re: (Score:3)
The T2 security chip supports/enables APFS encryption (storing the keys in the secure enclave). HFS+ encryption is not directly supported by the T2 security chip hardware. So, if you want to trust the (Apple ecosystem) encryption, you need to move APFS.
APFS is a well respected (by the experts) file system design. While I wish Apple directly provided and supported Linux and Windows APFS drivers, that was never their responsibility, but there are 3rd party drivers available.
DING DING DING!!! We have a winner!
That (T2 incompatibility) is exactly the reason! Plus, I wonder if some of that code was never converted/can’t be converted to ARM?
Re: (Score:3)
T2 chips were only in Intel-based Macs. The last one came out in 2020.
So much disinformation about Macs here....
APFS is a well respected (by the experts) file system design. While I wish Apple directly provided and supported Linux and Windows APFS drivers, that was never their responsibility, but there are 3rd party drivers available.
Too bad APFS doesn't support data checksums.
Apple moved the T2 Functionality directly Into the Apple Silicon SoCs. Even more secure.
As for Data Checksumming, Apple trusts the ECC built into their SSDs to take care of that Task.In their own words, “Our Storage doesn’t Return Bad Data.”
It’s pretty well agreed that actual Bit-Rot-Style Data Corruption in SSDs is all but unknown.They tend to work perfectly, or not at all. So, ZFS-style Data Scrubbing is nothing but a waste of Resources with APFS.
They do, however, Checksum the Meta
Kinda offtopic but... (Score:1)
Re: Kinda offtopic but... (Score:2)
Re: Kinda offtopic but... (Score:2)
Bleagh, (Score:2)
You can get Veracrypt to work with the Mac, via FUSE, but I don't know how safe/robust that is. It's probably more secure than anything Apple has. It's certainly more secure than anything Microspot has.
But, yeah, it's getting extremely irritating that useful stuff is being taken out of commercial OS' and junk put in.
Re: (Score:2)
That encrypted HFS+ volumes are not as secure as advertised.
And that a CVE is on the horizon. Purely speculating.
As mentioned previously, only APFS has hardware encryption support via the T2 chip with the keys inside the hardware secure enclave. HFS+ does not (and never has had) that level of security/trust. Apple likely wants their users to actually be able to believe in the trust of the encryption (and HFS+ cannot achieve that level). If you believe you can explain to the average macOS user about the various levels of trust/encryption in a way they can actually understand and make well informed decisions, please
ZFS :-) (Score:2)
I'm being partly flippant, but wouldn't it be nice to have ZFS on MacOS.
Decryption keys? (Score:1)
Anyone know if the new system automatically forwards your decryption keys to the manufacturer, like Bitlocker?