Sequoia 15.4 refusing to open files - possible malware

My personal experience is that all applications and related files which have not been validated by Apple, because they are not in the Apple Store or not created by approved software developers, are considered "possibly malware" by all versions of Sequoia, and that includes some independent and reliable applications I use for work for which I alerted the developers, who contacted Apple to fix this issue.

In the case of .srt files flagged as malware, what I am trying to understand is whether they may have been created with an app that is not Apple-endorsed.

So, in my view it is an OS "security feature", not processor-related, and does not apply to all .srt files -- in fact, 99% of the .srt files I have open in 15.4, but the two files I got two days ago don't.

I found someone stating that changing file extension from .srt to .txt will work. It opens up the file and if need be, I can edit it. There is definitely a glitch somewhere. The files I download come from subtitle depository sites such as subsource and opensubtitles. Earlier versions of Sequoia allowed TextEdit to open them, later ones have not. So... I guess if I must update I will have to change the .srt to .txt, edit if need be, then rename again to .srt and use it with the app I use to embed subs in videos. I fail to understand why a text file is considered an app.

The following article mentions the problem we are all facing and suggests a few permanent solutions:

https://www.fireebok.com/resource/how-to-fix-file-has-malware-warning-after-macos-sequoia-update.html

I do hope this disussion goes somewhere with Apple ears because I have so many files of all kinds that just get flagged up it's making using the MAC a real pain. I just go to bootcamp if I know I am going to have to work with them.

Hans Luijten wrote:

I know reporting may not do a thing, but not reporting for sure doesn't do a thing 😉

While I agree with you in principle, I disagree it's a bug or anything Apple will take a serious interest in addressing.

It has been my experience that, when addressed, legitimate bug reports will generally fall into one of several categories.

They are:

• addressed within a macOS update or two, or
• bounced back to the user with some questions to be answered, or requesting additional data, or
• comprehensively bundled into a feature released in some future product upgrade, or
• identified as "performing as designed / expected" or words to that effect.

That last category is the most frustrating when something so clearly isn't. More on that later.

Again, this is for legitimate, demonstrable and repeatable bugs that can reliably be produced on an unmodified system. If the so-called "bug" is due to some third party product incompatibility, the most Apple will ever do is to forward it to the product developer. Unless that developer is large and influential and represents a significant risk to Apple's customer satisfaction, I doubt they will do even that much. In such cases the developer and Apple have a mutual interest in fixing things. Mutual interest is the only circumstance in which anything ever gets fixed.

Now... for legitimate bug reports indicating something should be working when it isn't, and for which Apple's reply appears to be inexplicably curt, there is a reason for that too. That reason may not become apparent until a future product or service or OS upgrade obviates the complaint, nullifying its relevance. That can take years. I can think of a number of examples for both Macs and iOS. The passage of time and product improvements is what makes that reply sensible in retrospect. Apple's engineers might even take an active interest in your concern, requesting additional data, reports, logs, feedback, etc right up to the moment their project manager tells them to stop. If they should protest, the hapless engineer is told "you don't need to know."

In the case of the OP, the answer to "how do I turn off the whole thing" is you can't. Not if you mean that literally, and certainly not without making compromises I would not recommend to the casual user who represents the overwhelming majority of Apple's customer base.

If you were to file a bug report Apple is nearly certain to say it's "performing as designed / expected" or words to that effect, because it is. The user will need to implement a workaround. But if you are motivated to file feedback or a bug report, go ahead. I won't discourage you. I just wanted to let you know what to expect.

These are movie subtitle files that are UTF-8 (with BOM) text, with CRLF line terminators. The only Finder Open With application that presents itself on my Mac is the VLC player — which is not the correct tool to singularly view these subtitles.

Launching BBEdit and asking it to open one of these *.srt files won't work. However, if one chooses to install the BBEdit Command Line Tools from its application menu, then in the Terminal:

bbedit /path/to/foo.srt

will open the file in a new BBEdit window with line endings translated and normal text entries for timeframe and translation text.

Select one of the .srt files, press command+i, in the Get Info window that opens, choose TextEdit from "Open with:" then press the "Change All…" button. That should sort it out.

I regularly open and manipulate .srt files with no issues. The problem isn't the OS it's the file...

I'd use file to determine the file type. I surmise the file in question is not an ASCII text file.

John Galt wrote:

I'd use file to determine the file type. I surmise the file in question is not an ASCII text file.

I've found one possible cause. But the OP has solved the problem by disabling system security. So I have a suggestion ready for the next time I see this problem reported.

FYI: I'd hate to disable the security, so for now I reported the issue with Apple and use xattr to clear the extended attributes for my source folder;

xattr -c -r /path/to/folder

For me this was -never- a problem until I updated to 15.4. 😞

Could not reproduce the SRT issue either, but then again I do not have any SRT files that I had downloaded.

The problem is most likely two fold;

1) the file was downloaded

2) Gatekeeper ignores the fact that both files are plain ASCII Text.