search

blueboxd / chromium-legacy

Latest Chromium (≒Chrome Canary/Stable) for Mac OS X 10.7+
BSD 3-Clause "New" or "Revised" License
306 stars 17 forks source link

macOS location permission for Chromium Legacy in Settings is reverted after restart #93

Closed AlixSPQR closed 1 year ago

AlixSPQR commented 2 years ago

Describe the bug When Chromium Legacy is restarted, the given location permission in macOS Settings is reverted, and has to be given/checked again.

To Reproduce Steps to reproduce the behavior:

  1. Give Chromium Legacy location permission in macOS Settings.
  2. Test that location works in Chromium Legacy.
  3. Restart Chromium Legacy and open Settings.
  4. Location permission is reverted/unchecked.

Expected behavior Location permission should be given only once, until manually recalled.

Desktop (please complete the following information):

pjpreilly commented 2 years ago

On Lion it doesn't work...it asks to allow & when allowed it says location services is not enabled on this computer. Works fine on Supported Hardware with current Google Chrome Canary as tested on where-am-i.net

Wowfunhappy commented 2 years ago

it asks to allow & when allowed it says location services is not enabled on this computer.

Just confirming, have you gone into System Preferences and then unchecked and rechecked location permissions for Chromium? (Assuming the option exists in Lion?)

Anyway, I wonder if this is a code signing issue?

pjpreilly commented 2 years ago

Just confirming, have you gone into System Preferences and then unchecked and rechecked location permissions for Chromium? (Assuming the option exists in Lion?)

Yep, nothing works....

pjpreilly commented 2 years ago

2022-09-21 11 33 28 pm

blueboxd commented 2 years ago

This is the code-signing issue. Unsigning official Chrome replicates this issue and signing Chromium-legacy fixes. Unfortunately, I have no valid code-signing certificate for distribution. Sorry for the inconvenience.

AlixSPQR commented 1 year ago

Thank you, @blueboxd, for looking into this. I've tested to turn off Gatekeeper and SIP, but that didn't do any difference. I didn't think it would, but now we know. It is an inconvinience, but since we have a working Chromium on older macs, thanks to you all, I am happy still. 👍🏻

AlixSPQR commented 1 year ago

Woolyss Chromium haven't signing either, but doesn't display the same behaviour (Monterey 12.6.2). How come?

https://chromium.woolyss.com/ https://github.com/macchrome/macstable/releases/download/v109.5414.65-M109.0.5414.65-r1070088-macOS/Chromium.app.sync-109.0.5414.65.zip

Wowfunhappy commented 1 year ago

While I can't say exactly what's different, modern macOS has a much more robust implementation of TCC, so it doesn't surprise me that Monterey handles this better.

blueboxd commented 1 year ago

@AlixSPQR Ah, got it! Thank you! That Chromium is actually signed with entitlements using adhoc signature (without valid certificate). We only need embedded entitlements to fix this issue, no valid certificate is needed.

I'll integrate the signing process to build steps, so please wait a while.

AlixSPQR commented 1 year ago

Great! Thank you for looking into it again, it's an important feature for me.

blueboxd commented 1 year ago

Please try manually signed experimental release (r1091468).

Wowfunhappy commented 1 year ago

@blueboxd Would it be possible to sign the Chromium binary but leave Chromium Framework unsigned, or will the issue still appear if you do that? It's fine either way, but leaving the framework unsigned makes code injection easier.

AlixSPQR commented 1 year ago

Sorry, but Gatekeeper gets stuck checking with the experimental release on El Capitan 10.11.6.

blueboxd commented 1 year ago

@Wowfunhappy Oh, I didn't notice. Signing only *.app seems to address the issue. I'll avoid sigining framework.

@AlixSPQR Sorry, I usually launch from CLI, which skips Gatekeeper. I'll investigate further.

AlixSPQR commented 1 year ago

Thanks. I'll try that next time.

blueboxd commented 1 year ago

@AlixSPQR Please try adhoc_1107698. Gatekeeper took several minutes (~10min?) for verification but finished without a problem. (just in case, xattr -dr com.apple.quarantine ~/Downloads/1107698/Chromium.app from Terminal.app will skip verification) And permission for Location Services is retained after restarting Chromium.

AlixSPQR commented 1 year ago

@blueboxd I can confirm that permission for Location Services is retained after restarting Chromium. Thank you. Great work!

blueboxd commented 1 year ago

@AlixSPQR Thank you for the confirmation! I'll add the signing process to the build pipeline.

scrutinizer11 commented 1 year ago

I started having this issue today as purportedly related to https://github.com/blueboxd/chromium-legacy/issues/96#issue-1376625245. Chromium was extremely sluggish to connect to the point of complete loss of connectivity. I trashed Chromium's support folder, then quit it and put the original support folder back. That brought it round but now I have to honour the Keychain Access and Location permission prompts every time I start Chromium.

scrutinizer11 commented 1 year ago

The issue still is unresolved and keeps popping up at every launch unless the ad-hoc deep code-signing is applied manually.

AlixSPQR commented 1 year ago

The issue still is unresolved and keeps popping up at every launch unless the ad-hoc deep code-signing is applied manually.

It works for me, still does as of today, as I've stated above. I suppose it's only the linked special version that works until 112 has reached stable?

AlixSPQR commented 1 year ago

MacOS location permission works fine now with the latest stable version 112.0.5615.121.1, from yesterday, so this issue can be closed.

scrutinizer11 commented 1 year ago

I managed to tame the repeated Chromium's prompts on Lion such as this one, aggravated by forced sign-outs from my Google account on every launch, only by deep-code-signing the bundle on Mavericks and copying it to Lion (and deleting "Chromium Safe Storage" from Keychain Access beforehand).