#451: mac gatekeeper quarantine removal by shodiBoy1 · Pull Request #1794 · devonfw/IDEasy

shodiBoy1 · 2026-04-01T14:49:28Z

This PR fixes #451

Implemented changes:

On modern macOS (15.1+, Apple Silicon), just removing com.apple.quarantine didn't work - unsigned apps still showed the "is damaged" popup. Tested this on a real M1 Pro with IntelliJ CE and Android Studio.

The fix does two things after extraction:

xattr -cr to clear all extended attributes (quarantine, resource forks, etc.)
codesign --force --deep --sign - to ad-hoc sign the .app bundle - but only if it's not already properly signed (so we don't break notarized apps like Eclipse)

Other changes:

Version file (.ide.software.version) stays at rootDir instead of being copied inside the .app, because codesigning seals the bundle and any writes after that break it
linkDir now correctly points inside the .app bundle (e.g. Contents/MacOS) where the binary lives. The symlink target changed, so getInstalledVersion() was updated to resolve the symlink back to rootDir via getValidInstalledSoftwareRepoPath to find the version file
Added ProcessErrorHandling to codesign calls - NONE for the verification step (failure is expected for unsigned apps) and LOG_WARNING for the signing step
Removed findBinDir() from MacOsHelper and the getToolBinPath() macOS workaround - both were redundant after fixing the linkDir assignment
Updated tests to use getInstalledVersion() instead of checking the version file through the symlink

Checklist for this PR

When running mvn clean test locally all tests pass and build is successful
PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only.
PR top-level comment summarizes what has been done and contains link to addressed issue(s)
PR and issue(s) have suitable labels
Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
You followed all coding conventions
You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
with internal

…ntine-removal' into feature/451-mac-gatekeeper-quarantine-removal

coveralls · 2026-04-01T15:04:56Z

Coverage Report for CI Build 24485428778

Coverage increased (+0.02%) to 70.474%

Details

Coverage increased (+0.02%) from the base build.
Patch coverage: No coverable lines changed in this PR.
86 coverage regressions across 3 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

86 previously-covered lines in 3 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/tool/ToolCommandlet.java	47	73.45%
com/devonfw/tools/ide/tool/LocalToolCommandlet.java	22	80.36%
com/devonfw/tools/ide/os/MacOsHelper.java	17	76.92%

Coverage Stats


Relevant Lines:	15098
Covered Lines:	11089
Line Coverage:	73.45%
Relevant Branches:	6700
Covered Branches:	4273
Branch Coverage:	63.78%
Branches in Coverage %:	Yes
Coverage Strength:	3.1 hits per line

💛 - Coveralls

hohwille

@shodiBoy1 thanks for your PR. Great that you are working on this nasty problem that is currently blocking Mac users and renders the UX of IDEasy on Mac void. 👍
Currently, I do not see the difference in the xattr compared to PR #453. Can you explain why this should fix the problem now? Have you tested this approach on MacOS and it worked for unsigned apps like e.g. IntelliJ?

FYI: Did you also see this comment? #451 (comment)
When we remove the quarantine attribute, MacOS protected the app directory and we cannot make any modifications to it after that. This IMHO implies that we cannot keep the current solution with the .ide.software.version file that we simply copy to the linkDir as a workaround. Maybe it could work if we do that before we remove the quarantine attribute?
Further, in PR #453 @jan-vcapgemini made a review comment that this xattr execution should be moved to MacOsHelper what makes sense to me and should be followed.

hohwille · 2026-04-02T06:54:11Z

    postExtractHook(postExtractHook, properInstallDir);
    move(properInstallDir, targetDir);
    delete(tmpDir);
+    removeQuarantineAttribute(targetDir);


This should only happen for an application. The extract function is generic and can also be used to extract a ZIP file with pure data or config that is not an application. Please note that the executed xattr command will typically trigger a popup with password request so this should only appear for applications (ideally only if they are not signed).
Please check PR #453 where this was already done in the right place.

hohwille · 2026-04-02T06:56:40Z

+      ProcessResult result = this.context.newProcess().executable("xattr")
+          .addArgs("-r", "-d", "com.apple.quarantine", path).run(ProcessMode.DEFAULT_SILENT);


This looks exactly like what I did in PR #453. However, I tested my solution and it did not work.
Am I missing something or why should it work now?

shodiBoy1 · 2026-04-12T21:09:28Z

previous fix was wrong just doing xattr -r -d com.apple.quarantine isn't enough on macOS 15.1+ with Apple Silicon. Unsigned apps still get blocked even without the quarantine attribute.

new fix xattr -cr to clear all extended attributes, then codesign --force --deep --sign - to ad-hoc sign the .app bundle. The codesign part is what actually makes it work. I skip signing if codesign -v passes so we don't break already notarized apps like Eclipse.

Moved the logic into MacOsHelper.removeQuarantineAttribute() and it's called from LocalToolCommandlet.installTool() now, not from extract.

.ide.software.version stays at rootDir can't write inside the .app after codesigning or you get "Operation not permitted". Version file is written before signing so no issue there.

Tested with IntelliJ CE and Android Studio on M1 Pro, works fine.

hohwille

@shodiBoy1 thanks for your update. Now this looks way more promising. 👍
However, there are still things to clarify before we can merge.

hohwille · 2026-04-13T11:06:55Z

+          }
+        }
+      } catch (Exception e) {
+        LOG.trace("Codesign not available for {}: {}", appDir, e.getMessage());


same here? Raise to info or warn, always include the exception itself so stracktrace can be seen.
BTW: If I am not mistaken, we only print stacktraces if log-level is error or otherwise if debug or trace is activated.

yep, changed both to LOG.warn with the exception included so it shows the exception info at warn level and full stacktrace when running in debug mode.

hohwille · 2026-04-13T11:12:28Z

-    if (linkDir != rootDir) {
-      assert (!linkDir.equals(rootDir));
-      Path toolVersionFile = rootDir.resolve(IdeContext.FILE_SOFTWARE_VERSION);
-      if (Files.exists(toolVersionFile)) {
-        this.context.getFileAccess().copy(toolVersionFile, linkDir, FileCopyMode.COPY_FILE_OVERRIDE);
-      }
-    }


This might be problematic on macos, but if you remove it, you also need to fix the code to determine the tool version that you broke by just removing this code-block.

version detection still works just a different approach. before, linkDir pointed inside the .app bundle so the symlink landed there, and the version file had to be copied from rootDir into linkDir.
in my fix linkDir == rootDir, so the symlink points to the top level directory where the version file is already written no copy needed.
also copying into the .app bundle would break after codesigning since macOS seals it. binaries are still found correctly through findBinDir() in getToolBinPath() which navigates into the .app bundle to find executables.

@hohwille you were right, I didn't fully understand how linkDir and rootDir work together. i broke the linkDir assignment by collapsing two lines into one. I restored it so linkDir points inside the
.app bundle again. instead of copying the version file into the bundle (which would break codesigning), I changed getInstalledVersion to follow the symlink back to rootDir where the version file already lives.

Co-authored-by: Jörg Hohwiller <hohwille@users.noreply.github.com>

hohwille · 2026-04-13T14:52:20Z

 * https://github.com/devonfw/IDEasy/issues/1702[#1702]: UI Buttons do not scale properly with window resize
 * https://github.com/devonfw/IDEasy/issues/1751[#1751]: Add go commandlet (go-lang support)
 * https://github.com/devonfw/IDEasy/issues/1732[#1732]: Add stash support for git-pull
+* https://github.com/devonfw/IDEasy/issues/451[#451]: Automatically remove macOS quarantine attribute after tool extraction


I resolved the merge conflict.
But this line still needs to be moved up.
Maybe even to 2026.05.001 that is not yet added to the CHANGELOG.

moved changelog entry up to 2026.04.002

Co-authored-by: Jörg Hohwiller <hohwille@users.noreply.github.com>

…ntine-removal' into feature/451-mac-gatekeeper-quarantine-removal

…n file through symlink

shodiBoy1 added 2 commits March 31, 2026 20:13

removing macOS quarantine attribute after extraction

9eb8de3

upd for issue 451

aa0d7bd

github-project-automation bot added this to IDEasy board Apr 1, 2026

github-project-automation bot moved this to 🆕 New in IDEasy board Apr 1, 2026

Merge branch 'main' into feature/451-mac-gatekeeper-quarantine-removal

45e0706

shodiBoy1 self-assigned this Apr 1, 2026

shodiBoy1 added 2 commits April 1, 2026 16:59

fixed xattr crash when not available

4379492

Merge remote-tracking branch 'origin/feature/451-mac-gatekeeper-quara…

08110a4

…ntine-removal' into feature/451-mac-gatekeeper-quarantine-removal

shodiBoy1 marked this pull request as ready for review April 1, 2026 15:05

shodiBoy1 requested a review from hohwille April 1, 2026 15:06

shodiBoy1 moved this from 🆕 New to Team Review in IDEasy board Apr 1, 2026

hohwille changed the title ~~Feature/451 mac gatekeeper quarantine removal~~ #451: mac gatekeeper quarantine removal Apr 2, 2026

hohwille requested changes Apr 2, 2026

View reviewed changes

revert fix

a8a69d7

hohwille marked this pull request as draft April 9, 2026 07:22

shodiBoy1 and others added 2 commits April 10, 2026 01:16

devonfw#451: fixed macOS Gatekeeper blocking for unsigned .app bundles

b309a76

Merge branch 'main' into feature/451-mac-gatekeeper-quarantine-removal

7b08d0e

Merge branch 'main' into feature/451-mac-gatekeeper-quarantine-removal

f14ebcc

shodiBoy1 marked this pull request as ready for review April 12, 2026 21:13

hohwille approved these changes Apr 13, 2026

View reviewed changes

github-project-automation bot moved this from Team Review to 👀 In review in IDEasy board Apr 13, 2026

Apply suggestions from code review

6f960df

Co-authored-by: Jörg Hohwiller <hohwille@users.noreply.github.com>

hohwille reviewed Apr 13, 2026

View reviewed changes

shodiBoy1 and others added 5 commits April 13, 2026 20:32

Update cli/src/main/java/com/devonfw/tools/ide/os/MacOsHelper.java

293e980

Co-authored-by: Jörg Hohwiller <hohwille@users.noreply.github.com>

Update MacOsHelper.java

6661463

changelog upd

fd33153

changelog upd

84857cb

Update MacOsHelper.java

a5a9b1b

hohwille assigned MarvMa Apr 14, 2026

shodiBoy1 added 3 commits April 16, 2026 02:12

fixed linkDir assignment and version file lookup for macOS .app bundles

02277ff

Merge remote-tracking branch 'origin/feature/451-mac-gatekeeper-quara…

236fe2d

…ntine-removal' into feature/451-mac-gatekeeper-quarantine-removal

updated tests to use getInstalledVersion() instead of checking versio…

d4fb30e

…n file through symlink

MarvMa self-requested a review April 17, 2026 07:47

		ProcessResult result = this.context.newProcess().executable("xattr")
		.addArgs("-r", "-d", "com.apple.quarantine", path).run(ProcessMode.DEFAULT_SILENT);

Conversation

shodiBoy1 commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This PR fixes #451

Implemented changes:

Checklist for this PR

Uh oh!

coveralls commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage Report for CI Build 24485428778

Coverage increased (+0.02%) to 70.474%

Details

Uncovered Changes

Coverage Regressions

Coverage Stats

💛 - Coveralls

Uh oh!

hohwille left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shodiBoy1 commented Apr 12, 2026

Uh oh!

hohwille left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

shodiBoy1 commented Apr 1, 2026 •

edited

Loading

coveralls commented Apr 1, 2026 •

edited

Loading