User cannot re-enter password if wrong password is entered on a specific setup

[DmitryLupich]

Summary

In current state of Sparkle, when new update is available, user is prompted to enter Mac password for update. When user enters wrong password, flow stops and delegate method - (void)updater:(SPUUpdater *)updater didAbortWithError:(NSError *)error; is called with error.

Possible Fix

Please, give possibility to re-enter password, rather then restart flow from the beginning.

Version

Version 2.5.1

[zorgiepoo]

This is wrong, I cannot reproduce this issue with the Sparkle Test App. You are assuming this is universally an issue but this is not true.

Please provide the macOS version you are testing with. If you are seeing an error please actually provide what the NSError description is in this report, or paste any logs about the error in your app if they're present.

The OS brings up the prompt when the user needs to authenticate and enter an administrative password to install the update. The OS does not return back to Sparkle until the user enters a correct password or cancels the prompt themselves. If the user enters a wrong password, that dialog is supposed to remain there, and Sparkle doesn't even know when an incorrect password is entered.

I'm on macOS 14.1.2 (23B92). If I download the Sparkle Test App from the latest GitHub release distribution, move the Sparkle Test App to /Applications/ to get around app translocation, change the ownership on the app so it requires an authenticated install: sudo chown root "/Applications/Sparkle Test App.app", try installing an update and entering a wrong password, I don't reproduce your claimed issue.

[DmitryLupich]

@zorgiepoo Hello! Thanks for response. Here is proof demo: https://github.com/sparkle-project/Sparkle/assets/35382490/71c6317b-3e0b-4103-8f20-4f44af805cd0

[zorgiepoo]

Please provide information I actually asked.

Please provide the macOS version you are testing with. If you are seeing an error please actually provide what the NSError description is in this report, or paste any logs about the error in your app if they're present.

While a demo is not completely useless, it may be better to provide a reproducible test case, which could even be a build of your app.

Also your demo makes me skeptical it's using Sparkle 2 because Autoupdate itself does not ask for a password in Sparkle 2.

[DmitryLupich]

Yes, more details from me:

• macOS Sonoma 14.1.2
• 'Sparkle', '2.5.1'

Here are some NSAlerts:

After entering wrong password, Update Error alert is presented and flow ends. What I want to achieve is let user re-enter password after failure attempt, thanks!

[dsmurfin]

Yes, more details from me:

• macOS Sonoma 14.1.2

• 'Sparkle', '2.5.1'

Here are some NSAlerts:

After entering wrong password, Update Error alert is presented and flow ends. What I want to achieve is let user re-enter password after failure attempt, thanks!

@DmitryLupich I think what @zorgiepoo is asking for rather than screenshots is the actual error that is returned to Sparkle. You should be able to print that when it returns to you. Screenshots of an alert contain very limited context and often only a very simplified illustration of an error.

[zorgiepoo]

@DmitryLupich I think what @zorgiepoo is asking for rather than screenshots is the actual error that is returned to Sparkle. You should be able to print that when it returns to you. Screenshots of an alert contain very limited context and often only a very simplified illustration of an error.

Yes, indeed. These new screenshots are showing Sparkle 2. The previous video demo looked like Sparkle 1 to me to be honest. The authentication code is set up differently in both versions so if this is the case it's interesting the issue exists in both cases. I'm on a similar OS version so it doesn't seem to be Sonoma specific issue either.

If you look in the Console logs for your app (or the Installer XPC Service if the app is sandboxed), you may find a log that starts with Failed copying system domain rights: which may log out the status error code from the Authorization/Security framework (from AuthorizationCopyRights() failing). Or there may be a log starting with Submit error: (from SMJobSubmit() failing) but I don't think it will get that far.

@DmitryLupich Keep in mind that I still cannot reproduce your issue. If you want to increase your chances of the cause of this issue from being understood, you will need to work towards providing me sufficient information towards this. Does it reproduce for you with other apps using Sparkle (like the test app)? Does it reproduce for you with apps using the standard Authorization/Security APIs for use cases other than Sparkle? Does it reproduce for you on other systems or is it specific to the machine you're using? Is there something specific that could have been set up on your machine/network of machines to reject multiple password attempts in the authorization database (this may be potentially configurable on MDM / enterprise setups)? If it is only specific to reproducing with a specific app, you may need to share an app/build that reproduces the issue.

First though, we can start and see if we get any more useful diagnostics from the logs.

[zorgiepoo]

https://github.com/sparkle-project/Sparkle/assets/857267/59a68835-9c0f-4bb8-afc6-78a67de3303b

Proof I cannot reproduce your issue after trying with several apps that use Sparkle.

[DmitryLupich]

Thank @zorgiepoo for that screen recording. I'm wondering how can I reproduce that behavior? Because I don't see enter password alert in Sparkle test application. Is there any flag regarding auth staff in the app?

Version: 2.5.2 macOS: Sonoma 14.1.2

https://github.com/sparkle-project/Sparkle/assets/35382490/1d0e8a88-f3a5-49f2-b02f-a7314f1969bb

[zorgiepoo]

As I said above:

...change the ownership on the app so it requires an authenticated install: sudo chown root "/Applications/Sparkle Test App.app"

Sparkle only requests for authorization when the app has insufficient permission to install the update. The majority of users do not need to enter their password unless developers ship a package (pkg) installation update which always requires executing the installer as root (which is one of the many reasons why developers should avoid shipping pkg installers).

[DmitryLupich]

@zorgiepoo reproduce that bug on my machine, here is it: https://github.com/sparkle-project/Sparkle/assets/35382490/84ff20d2-3d5a-4eac-825f-220203d72550

P.S. Sparkle Version: 2.5.2, macOS: Sonoma 14.1.2

[zorgiepoo]

That narrows down it's not specific to your app when reproducing the issue on your system.

What about any of the other info I asked?

If you look in the Console logs for your app (or the Installer XPC Service if the app is sandboxed), you may find a log that starts with Failed copying system domain rights: which may log out the status error code from the Authorization/Security framework (from AuthorizationCopyRights() failing). Or there may be a log starting with Submit error: (from SMJobSubmit() failing) but I don't think it will get that far.

Does it reproduce for you with apps using the standard Authorization/Security APIs for use cases other than Sparkle? Does it reproduce for you on other systems or is it specific to the machine you're using? Is there something specific that could have been set up on your machine/network of machines to reject multiple password attempts in the authorization database (this may be potentially configurable on MDM / enterprise setups)?

For reproducing with other apps using Authorization/Security Apis for use cases other than Sparkle you can try testing a case for an app that uses LetsMove. For example:

Download Poedit - https://poedit.net/download/ , copy the app to /Applications/ but also leave a copy in ~/Downloads/. Run sudo chown root /Applications/Poedit.app, launch the app from ~/Downloads/Poedit.app and it will ask you to move the application to Applications folder. Try moving it and it should ask for authorization (because it will try replacing the app in /Applications/) which is where you can try entering a wrong password. Note this uses a different authorization API than Sparkle 2 though so if the issue does not reproduce that still doesn't mean it's specific to Sparkle's use case.

Obviously you can also try reproducing on other machines, ideally ones that are not set up the same way as yours (e.g. a customers).

[DmitryLupich]

@zorgiepoo Tested a lot last couple of days, seems the issue is related to managed devices only. On clear or personal devices everything works as expected. Thanks for help, I think we can close this issue!

[zorgiepoo]

Likely managed devices were configured to reject multiple password attempts is my guess then. Let's close. Cheers.