It's always seemed strange that an application called TextEdit is actually more than a text editor. I strongly believe that content-type autodetection, much less HTML rendering(!), most certainly does not belong in a text editor.
When they shoehorned the ShellExecute behavior into cmd.exe, they basically just said "if (!CreateProcess(foo)) {ShellExecute (foo)}"
As a result, if you take "foo.exe" and rename it "foo.txt" then try to run it like "C:\>foo.txt" from the command line, it will run as an executable instead of opening in Notepad like you would expect. Do the same with a real text file (that doesn't start with "MZ") and it opens in Notepad.
It's frustrating when I instinctively change a file extension on Windows so I can do some other operation with it (say changing a configuration file to .txt to edit it) and Windows still doesn't know what to do with it.
I'm not averse to the behavior, I just wish I could control when it happens.
Opening HTML files and converting them to rich text certainly does belong as a valid feature for a rich text editor. It'll open and convert Word files too, which is super useful.
The content-type autodetection, however, I agree was a bad idea. Still, this vulnerability presumably existed with an .html file opened in TextEdit.
It wouldn't have been as bad though. From the article:
>Gatekeeper doesn’t quarantine TXT files
It's perfectly reasonable to expect a text editor to support more than literal unicode, and to work with a variety of commonly-used formats.
The blog post states that the contents of said "text file" were quite literally <!DOCTYPE HTML><html><head></head><body>
This is not a mere text file. At all. This is a HTML document that might be deemed valid by a very permissive validator.
Just because HTML might be stored in a text file that does not mean that a noncompliant HTML file ceases to be a HTML file.
One might, possibly, still argue about the text encoding of a .txt file (I’m old enough to remember Unicode being a new fancy alternative to ASCII), but that’s about it.
[0] Sometimes I reminisce about the good old days of classic Mac OS, with resource forks and separate file type metadata: https://en.wikipedia.org/wiki/Resource_fork
That statement is quite wrong and shows a good dose of ignorance. To start off in UNIX systems the extension means nothing regarding whether a file is an executable or not. All it takes is a +x flag and a file format (header, magic number) that can be executed.
Also, file extensions mean nothing. In fact, a popular and very basic trick to fool clueless users to run malware (and one which any anti-malware tool checks) is to sneak executables with a different extension, because it only means something to clueless users.
And a file with a txt file extensions means nothing at all. The only thing that matters is the file content and it's file permissions.
TextEdit.app is the OpenStep rewrite of Edit.app and dates to the mid 1990s. It was likely one of the first OpenStep apps. It supported the same rich text files as the original Edit.app.
Apple bought NeXT, OpenStep became Cocoa, TextEdit was ported to Java, and then back to garbage collected Objective-C, then ARC Objective-C, (then Swift, probably).
Along the way it picked up features for reading/writing/editing HTML and Microsoft Word documents.
Apple used to publish the source code for TextEdit as part of their Xcode sample code, but they stopped a few years ago.
The URL still works if you want it, but, yeah, it's obviously not up-to-date:
https://developer.apple.com/library/archive/samplecode/TextE...
> (then Swift, probably).
Not yet at least; there's no Swift symbols in the binary on Big Sur.
Wait, what? Wow, that’s nuts!
But AppKit was still pure Objective-C, and bridging between AppKit's Obj-C APIs and the Java language presented problems. 3rd-party developers (eventually) preferred the write directly in Objective-C and Apple dropped the Java bridge some years later.
NeXT used Display PostScript for the display manager. If you opened an email that had PostScript commands, the mail agent would happily, automatically, execute them.
A favorite payload sent around the computer lab would smear all pixels downward to "melt" whatever was rendered on your display.
Note that there weren't that many interesting things to exfiltrate back then, so this wasn't a terrible default: there wasn't (any!) online commerce, online banking was rare, and even passwords were never echoed to the terminal.
Some systems (specifically, earlier versions of SGI IRIX) shipped with X authorization disabled by default. This is the equivalent of "xhost +". You could sniff a box as soon as it was plugged into the network, including capturing login session credentials, all terminal commands, and anything else. When they su'd to root, yes, you'd capture the root password.
In those days (mid 90's) almost nobody was running firewalls. At least, nobody in these parts. Putting your "office on the Internet" meant raw, unfiltered IP.
Do MacOS and Ubuntu ship with firewalls?
MacOS and Ubuntu ship with firewalls, though not sure if they're enabled by default.
(For those that might not be aware of it : with IPv6, there's no NAT, since there's no need for it.)
Your opinion is that you like TextEdit for what it is.
Neither opinion/feeling is relevant.
You can make security bugs in simple tools - this security bug is not purely a function of the number of target use-cases.
Nor do you have any rational basis for asserting that the given app "should only do one [thing]".
Anyone with networked filesystems, I should imagine?
You're either missing the point made by GP or being disingenuous. Please keep in mind that you need to explicitly mount a NFS before you're able to open it, and mounting a NFS not only requires explicit authorization but also only provides access to a specific file system mounted in a specific point following specific permissions.
Accessing the whole internet through file:// without being prompted for permissions or consent or even awareness is an entirely different thing. For starters, the access is not explicit nor subjected to conditions.
> visible and understandable
False. Something is neither visible nor understandable if it's misleading - which file extensions are. There are absolutely no guarantees that a file extension will match file contents, and that assumption can cause security risks - like in this article.
An actually good alternative is to encode file type as metadata, instead of inside the file contents or file-name, and then configure viewers to display it. That, while not "simple", is also visible and understandable to the user, while simultaneously being safe.
Only in software that ignores the extension.
> An actually good alternative is to encode file type as metadata, instead of inside the file contents or file-name, and then configure viewers to display it. That, while not "simple", is also visible and understandable to the user, while simultaneously being safe.
Metadata can be just as wrong as a file extension, and is generally far less visible.
No, only in software that blindly follows file extensions.
The exact same thing would happen with metadata - indeed file extensions are just a form of metadata - if the metadata says this is a text file but the application ignores it, we would have the exact same issue.
They are not far better than the alternatives, it's just that no alternative reached a critical mass due to them not being how Windows works.
On the contrary, they're the only kind of metadata that doesn't get mangled when files are moved around, and they're far less of an attack vector than other approaches. Of course you can set the wrong file type, but no approach avoids that problem.
The problems occur when a file, that is said to be of a certain filetype, is erronously treated as something else.
(Though in fairness, text editors do usually have special casing for file extensions and these days tools like ls will colour filenames based on the extension.)
I’d go as far as to call it negligent, not merely strange.
VS Code is cool and all, but it definitely is a lot more manual and laborious than VS. the tooling and automation in VS is missed if you’re used to it.
https://security.stackexchange.com/questions/56307/can-cat-i...
So real question. Is TextEdit a default text editor in a mac?