Fix file proviver extension to ONLY write to its own cached secret in keychain.

[stuckj]

Resolves

#9865 (partially). This bug covers many things, but the topic diverged a bit. I can create a new bug for the specific item this fixed, if desired.

Summary

Use a namespaced service string based on server URL to reliably scope the keychain entry to OUR entry instead of another applications. 😬 Without this, we sometimes are updating a different applications keychain entry since it's basically only matching based on username (the account name).

From what I can tell, the credentials in the file provider are for cache purposes only. In my test, I ran an unpatched version I built first. I had to authenticate since it was sandboxed with my personal credentials. I verified that reproduced the bad behavior. I then re-built with the patched version and killed/restarted the app. That then did NOT exhibit the behavior and the filesystem was still accessible. So, credentials appear unaffected after the change.

AI was used to help identify the problem, draft a patch, and help with build setup (since I haven't worked in this project before). I verified the patch makes sense (it's only a few lines) and that it works by building/testing locally. I'm a developer with 30 years experience so I appreciate the easier onboarding it provides, but don't trust it to do stuff on its own.

TODO

Nothing

Checklist

• Sign-off message is added to all commits.
• The commit messages are following The Conventional Commits specification.
• The commit history is clean with no merge commits.
  • How to rebase your commits
  • How to squash commits with rebase
• Uploaded screenshots from before and after for UI changes. - N/A
• Test(s) added to branch, with before/after results included in PR description, for performance improvements where applicable. - N/A
• Documentation has been updated or is not required. - N/A
• Backports requested where applicable (critical bugfixes).
• Labels added where applicable (bug/enhancement).
• Milestone added for target version.

AI (if applicable)

• The content of this PR was partly or fully generated using AI
  • I have read the guidelines for AI-assisted contributions.
  • I have read Nextcloud's AI Contribution Policy.

[i2h3]

From what I can tell, the credentials in the file provider are for cache purposes only.

It actually was a workaround to avoid users receiving errors in Finder that they are not signed in. The run-time provisioning of the file provider extension process by the main app process through UNIX sockets (meanwhile migrated to pure XPC) did not work reliably in the past.

The best would be a keychain sharing group entitlement but for historical reasons (it would render all these measures obsolete), this is impossible for our used identifiers right now.

[i2h3]

…so I tried to amend my comment two dozen times since I wrote it but then German train Wi-Fi struck again and I had to wait until now for proper conference Wi-Fi. 🤪 I was not aware that apps can query all items. This then looks like a serious oversight, indeed. Then I asked myself why there even is the keychain group access entitlement but I assume to avoid the access authorization prompts.

[i2h3]

/backport to stable-34.0

[i2h3]

This needs amendment. Our desktop client is a customizable project. The bundle identifier used as the prefix must be looked up during runtime and not be a compile time constant. I will look for more details on how to do this best here and follow up.

[i2h3]

Alternatively, the keychain item could also include the raw file provider domain identifier which is a life time UUID. Then server address and bundle identifiers become unnecessary because ownership and uniqueness are already achieved.

[stuckj]

@i2h3, it sounds like you're taking care of modifications here. But, if you need any additional input or changes from me, please just ping me directly.

[i2h3]

Okay, I thought my request for changes and the input I commented was clear enough. 😅 I think I finally understood the matter thanks to your comment and pull request. I try to work on this ASAP.

[stuckj]

I'll take a stab at the changes. :)

[i2h3]

@stuckj I did not see your comment yet in the flood of notifications, sorry. I opened #10981 meanwhile which is ought to replace this PR. I gave you credit for discovering and starting this fix.

[stuckj]

Sounds good.

[phk1918]

I can confirm this bug on Nextcloud desktop 34.0.4, macOS 27.0.1 (arm64).

The login keychain item Claude Code-credentials (Anthropic's Claude Code, account = my macOS username = my Nextcloud login name) is modified about 2 seconds after every Nextcloud start. Its partition list is reset to teamid:NKUJUXUJ3B, so the owning app triggers a "security wants to access key" prompt on every access, and "Always Allow" does not persist.

Observed timings:

• Nextcloud started 13:54:04 → item mdat 13:54:06
• Nextcloud started 13:40:18 → item mdat 13:40:41

It would be great to get this merged.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[i2h3]

Closed because replaced with #10981.