Skip to content

iCloud Password Extension #144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dbrewood opened this issue Jan 26, 2024 · 26 comments
Open

iCloud Password Extension #144

dbrewood opened this issue Jan 26, 2024 · 26 comments

Comments

@dbrewood
Copy link

Install the extension and try to sign it into iCloud via authentication. You are informed you must be using macOS Sonoma and are asked to download it.
I'm running macOS Sonoma :)

@dbrewood
Copy link
Author

I don't have this issue with Brave or Vivaldi.....

@claudiodekker
Copy link

claudiodekker commented Jan 27, 2024

This has to do with that a NativeMessagingHosts file isn't being created for Chromium, but does for those other browsers.

To fix this you can copy the com.apple.passwordmanager.json from Vivaldi/Brave's NativeMessagingHosts folder into Chromium's, or simply run the following command in Terminal:

echo '{
    "name": "com.apple.passwordmanager",
    "description": "PasswordManagerBrowserExtensionHelper",
    "path": "/System/Cryptexes/App/System/Library/CoreServices/PasswordManagerBrowserExtensionHelper.app/Contents/MacOS/PasswordManagerBrowserExtensionHelper",
    "type": "stdio",
    "allowed_origins": [
        "chrome-extension://pejdijmoenmkgeppbflobdenhhabjlaj/",
        "chrome-extension://mfbcdcnpokpoajjciilocoachedjkima/"
    ]
}' > ~/Library/Application\ Support/Chromium/NativeMessagingHosts/com.apple.passwordmanager.json

@dbrewood
Copy link
Author

Thanks that has indeed fixed the issue. Surely though there should not be a need to fix this?

@Cubik65536
Copy link
Member

Cubik65536 commented Jan 27, 2024

Thanks that has indeed fixed the issue. Surely though there should not be a need to fix this?

This is an issue of vanilla Chromium (you may already discovered), as ungoogled-chromium wants to stay as close as possible to vanilla, we might not fix it here. I do recommend you to report this to Chromium dev directly though.

Wrong info due to lack of prior research, check #144 (comment) for more info.

@PF4Public
Copy link
Contributor

Does the proposed solution adequately fix this issue, can we close it?

@dbrewood
Copy link
Author

I can't say as I stopped using the program.

@PF4Public
Copy link
Contributor

Well, let's consider it solved for now then.

@dbrewood
Copy link
Author

To clarify, running the script above did indeed fix the problem, although I still think a permanent fix needs to be incorporated into the program itself. The need for manual fixes like this having to be applied is why I stopped using it.

@Cubik65536
Copy link
Member

To clarify, running the script above did indeed fix the problem, although I still think a permanent fix needs to be incorporated into the program itself. The need for manual fixes like this having to be applied is why I stopped using it.

NativeMessagingHosts should be installed by the extension rather than the browser, there’s absolutely nothing we can do, neither actually Chromium devs, you should report this to Apple if what you want is a permanent fix, otherwise I could only suggest you to use the temporary fix or stop using browsers that Apple haven’t considered at the first place.

@Cubik65536
Copy link
Member

Reference: keeweb/keeweb@e674607 (another password manager that uses NativeMessagingHosts)

@dbrewood
Copy link
Author

Interesting, I can't see that Apple have considered Vivaldi or Brave and they both work.

@Cubik65536
Copy link
Member

Cubik65536 commented Feb 27, 2024

Interesting, I can't see that Apple have considered Vivaldi or Brave and they both work.

Let me correct myself: "absolutely nothing no proper way".

Brave points their location to Chrome (code). Which:

  1. Chromium doesn't, obviously.
  2. They actually shouldn't do that. (I shall remind you this involves permission settings, permission to access passwords, I don't think anyone wants to share these kinds of permissions across different applications, especially when you don't even realize it's shared)

I could assume that Vivaldi do the same.

And I will go strongly against adding this for UGC. For the reason described above.

But, everyone can have a different standard for "proper way", other browser's dev thinks it's okay to share these hosts, it's not how I think, especially considering the nature of UGC.

@dbrewood
Copy link
Author

Fair enough I understand your position.

@xcrap
Copy link

xcrap commented Oct 26, 2024

This is happening to be, i noticed it happened after installing several browsers to try, I already had arc but installed Vivaldi and Chrome Canary, after removing and going back to this extension this happened and the terminal command makes nothing, any ideias ?

@decal
Copy link

decal commented Nov 6, 2024

How's about for the Chromium that's packaged with Burp Suite?

@chefnaphtha
Copy link

chefnaphtha commented Apr 4, 2025

the workaround stopped working in the latest macos update

only difference i can see is that my google chrome (which works) has files in both in /Library/... and ~/Library/..., while chromium is ONLY in ~/Library/..., i.e. google chrome is installed system-wide. the com.apple.passwordmanager.json for google chrome is ONLY the root library dir, not the per-user dir

com.apple.passwordmanager.json exists in both NativeMessagingHosts, same content

@magn2o
Copy link

magn2o commented Apr 5, 2025

As of macOS 15.4, it appears that Apple introduced strict checking of signing-identifier and team-identifier in /System/Cryptexes/App/System/Library/CoreServices/PasswordManagerBrowserExtensionHelper.app/Contents/MacOS/PasswordManagerBrowserExtensionHelper (which you can verify through hex editing). There are a list of specific whitelisted identifiers, which, unfortunately ungoogled-chromium is not part of.

As far as I can tell, the list of whitelisted browsers are:

signing-identifier team-identifier
com.google.Chrome EQHXZ8M8AV0U
com.google.Chrome.beta EQHXZ8M8AV0W
com.google.Chrome.canary EQHXZ8M8AV0T
com.microsoft.edgemac UBF8T346G90Y
com.microsoft.edgemac.Beta UBF8T346G90X
com.microsoft.edgemac.Dev UBF8T346G90
com.microsoft.edgemac.Canary UBF8T346G90R
org.mozilla.firefox 43AQ936H960b
org.mozilla.firefoxdeveloperedition 43AQ936H960R
org.mozilla.nightly 43AQ936H960Y
company.thebrowser.Browser S6N382Y83G0P
com.brave.Browser KL8N8XSYF40R
com.vivaldi.Vivaldi 4XF3XNRN6Y0V
com.operasoftware.Opera A2P9LX4JPN0X
com.operasoftware.OperaGX A2P9LX4JPN0

@Cubik65536
Copy link
Member

As of macOS 15.4, it appears that Apple introduced strict checking of signing-identifier and team-identifier in /System/Cryptexes/App/System/Library/CoreServices/PasswordManagerBrowserExtensionHelper.app/Contents/MacOS/PasswordManagerBrowserExtensionHelper (which you can verify through hex editing). There are a list of specific whitelisted identifiers, which, unfortunately ungoogled-chromium is not part of.

As far as I can tell, the list of whitelisted browsers are:
signing-identifier team-identifier
com.google.Chrome EQHXZ8M8AV0U
com.google.Chrome.beta EQHXZ8M8AV0W
com.google.Chrome.canary EQHXZ8M8AV0T
com.microsoft.edgemac UBF8T346G90Y
com.microsoft.edgemac.Beta UBF8T346G90X
com.microsoft.edgemac.Dev UBF8T346G90
com.microsoft.edgemac.Canary UBF8T346G90R
org.mozilla.firefox 43AQ936H960b
org.mozilla.firefoxdeveloperedition 43AQ936H960R
org.mozilla.nightly 43AQ936H960Y
company.thebrowser.Browser S6N382Y83G0P
com.brave.Browser KL8N8XSYF40R
com.vivaldi.Vivaldi 4XF3XNRN6Y0V
com.operasoftware.Opera A2P9LX4JPN0X
com.operasoftware.OperaGX A2P9LX4JPN0

Unfortunately, it will probably impossible for us to get on that white list since ungoogled-chromium is literally signed with my personal account, and the chance of Apple trusting "me" is... let's say 0 :(

@chefnaphtha
Copy link

sad. if anyone's looking for an alternative i switched to bitwarden (vaultwarden) and while it's not as pretty and integrated it works fine

@Cubik65536
Copy link
Member

Yeah it is sad, and other browsers (like Zen) also has this problem, we all hope that we'll come to a solution at some point.

@CaptainWynn
Copy link

this is annoying to whitelist browser choice instead of letting the users decide the access of our own passwords if security is really the concern.

bitwarden it is then. sigh. we do not deserve good things i feel like sometimes. there is always something up to ruin the experience.

@pedromarvarez
Copy link

As of macOS 15.4, it appears that Apple introduced strict checking of signing-identifier and team-identifier in /System/Cryptexes/App/System/Library/CoreServices/PasswordManagerBrowserExtensionHelper.app/Contents/MacOS/PasswordManagerBrowserExtensionHelper (which you can verify through hex editing). There are a list of specific whitelisted identifiers, which, unfortunately ungoogled-chromium is not part of.

As far as I can tell, the list of whitelisted browsers are:

signing-identifier team-identifier
com.google.Chrome EQHXZ8M8AV0U
com.google.Chrome.beta EQHXZ8M8AV0W
com.google.Chrome.canary EQHXZ8M8AV0T
com.microsoft.edgemac UBF8T346G90Y
com.microsoft.edgemac.Beta UBF8T346G90X
com.microsoft.edgemac.Dev UBF8T346G90
com.microsoft.edgemac.Canary UBF8T346G90R
org.mozilla.firefox 43AQ936H960b
org.mozilla.firefoxdeveloperedition 43AQ936H960R
org.mozilla.nightly 43AQ936H960Y
company.thebrowser.Browser S6N382Y83G0P
com.brave.Browser KL8N8XSYF40R
com.vivaldi.Vivaldi 4XF3XNRN6Y0V
com.operasoftware.Opera A2P9LX4JPN0X
com.operasoftware.OperaGX A2P9LX4JPN0

If I have Arc and i'm having the same problem, then why that is? It's happening since two months ago :( Is something on my end then?

@Cubik65536
Copy link
Member

As of macOS 15.4, it appears that Apple introduced strict checking of signing-identifier and team-identifier in /System/Cryptexes/App/System/Library/CoreServices/PasswordManagerBrowserExtensionHelper.app/Contents/MacOS/PasswordManagerBrowserExtensionHelper (which you can verify through hex editing). There are a list of specific whitelisted identifiers, which, unfortunately ungoogled-chromium is not part of.
As far as I can tell, the list of whitelisted browsers are:
signing-identifier team-identifier
com.google.Chrome EQHXZ8M8AV0U
com.google.Chrome.beta EQHXZ8M8AV0W
com.google.Chrome.canary EQHXZ8M8AV0T
com.microsoft.edgemac UBF8T346G90Y
com.microsoft.edgemac.Beta UBF8T346G90X
com.microsoft.edgemac.Dev UBF8T346G90
com.microsoft.edgemac.Canary UBF8T346G90R
org.mozilla.firefox 43AQ936H960b
org.mozilla.firefoxdeveloperedition 43AQ936H960R
org.mozilla.nightly 43AQ936H960Y
company.thebrowser.Browser S6N382Y83G0P
com.brave.Browser KL8N8XSYF40R
com.vivaldi.Vivaldi 4XF3XNRN6Y0V
com.operasoftware.Opera A2P9LX4JPN0X
com.operasoftware.OperaGX A2P9LX4JPN0

If I have Arc and i'm having the same problem, then why that is? It's happening since two months ago :( Is something on my end then?

Well, company.thebrowser.Browser is Arc, so I can't tell if it is your issue or the list is not accurate...

@magn2o
Copy link

magn2o commented Apr 19, 2025

As of macOS 15.4, it appears that Apple introduced strict checking of signing-identifier and team-identifier in /System/Cryptexes/App/System/Library/CoreServices/PasswordManagerBrowserExtensionHelper.app/Contents/MacOS/PasswordManagerBrowserExtensionHelper (which you can verify through hex editing). There are a list of specific whitelisted identifiers, which, unfortunately ungoogled-chromium is not part of.
As far as I can tell, the list of whitelisted browsers are:
signing-identifier team-identifier
com.google.Chrome EQHXZ8M8AV0U
com.google.Chrome.beta EQHXZ8M8AV0W
com.google.Chrome.canary EQHXZ8M8AV0T
com.microsoft.edgemac UBF8T346G90Y
com.microsoft.edgemac.Beta UBF8T346G90X
com.microsoft.edgemac.Dev UBF8T346G90
com.microsoft.edgemac.Canary UBF8T346G90R
org.mozilla.firefox 43AQ936H960b
org.mozilla.firefoxdeveloperedition 43AQ936H960R
org.mozilla.nightly 43AQ936H960Y
company.thebrowser.Browser S6N382Y83G0P
com.brave.Browser KL8N8XSYF40R
com.vivaldi.Vivaldi 4XF3XNRN6Y0V
com.operasoftware.Opera A2P9LX4JPN0X
com.operasoftware.OperaGX A2P9LX4JPN0

If I have Arc and i'm having the same problem, then why that is? It's happening since two months ago :( Is something on my end then?

Confirm the bundle and team identifier of your installed app with codesign -dv [path to app]

Also, this particular issue would’ve appeared with macOS 15.4, so unless you were running betas, it should’ve only appeared a couple weeks ago.

@pedromarvarez
Copy link

Thank you for replying! @magn2o @Cubik65536 I already checked the bundle and team identifier and this is what i got from terminal:

Identifier=company.thebrowser.Browser
TeamIdentifier=S6N382Y83G

Executable=/Applications/Arc.app/Contents/MacOS/Arc
Identifier=company.thebrowser.Browser
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=597158 flags=0x10000(runtime) hashes=18650+7 location=embedded
VersionPlatform=1
VersionMin=851968
VersionSDK=983040
Hash type=sha256 size=32
CandidateCDHash sha256=0a84fcc6b89a95de3b2eda8beefcec3aafbc301b
CandidateCDHashFull sha256=0a84fcc6b89a95de3b2eda8beefcec3aafbc301b12a7e0fbde2b23f93a677ebe
Hash choices=sha256
CMSDigest=0a84fcc6b89a95de3b2eda8beefcec3aafbc301b12a7e0fbde2b23f93a677ebe
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=65994752
Executable Segment flags=0x1
Page size=4096
CDHash=0a84fcc6b89a95de3b2eda8beefcec3aafbc301b
Signature size=9023
Authority=Developer ID Application: The Browser Company of New York Inc. (S6N382Y83G)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Apr 16, 2025 at 10:37:12
Info.plist entries=56
TeamIdentifier=S6N382Y83G
Runtime Version=15.0.0
Sealed Resources version=2 rules=13 files=836
Internal requirements count=1 size=220
pedromarvarez@Pedros-Mac-mini ~ % 

As well i have Sonoma 14.7.4 but i updated to Sequoia two months ago, i had to downgrade right away due a compatibility problem with my canon camera and since then i have this problem even though i'm in Sonoma 14.7.4.

I checked the passwords options and the Autofill and iCloud keychain is on, as well I toggled off and on just in case.
Image

But i'm still having the same message when I try to use the extension in my Arc:
Image

@magn2o
Copy link

magn2o commented Apr 20, 2025

As well i have Sonoma 14.7.4 but i updated to Sequoia two months ago, i had to downgrade right away due a compatibility problem with my canon camera and since then i have this problem even though i'm in Sonoma 14.7.4.

Wait, you're on 14.7? That being the case, this particular restriction does not apply to you. My guess is this will address your issue (you'll need to adapt it to the proper Arc application path).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants