mas exception

[shpoont]

bundle crashes when trying to install mas packages, below is an example for Aphetamine app:

$ brew bundle --global --verbose
Not signed in
Error: Not signed in
Not signed in to Mac App Store.
==> Signing in to Apple ID:
2018-09-30 07:41:45.129 mas[51954:6450920] -[__NSXPCInterfaceProxy_ISAccountService signInWithContext:replyBlock:]: unrecognized selector sent to instance 0x7fbf3d51dab0
2018-09-30 07:41:45.138 mas[51954:6450920] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSXPCInterfaceProxy_ISAccountService signInWithContext:replyBlock:]: unrecognized selector sent to instance 0x7fbf3d51dab0'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff48c8b43d __exceptionPreprocess + 256
	1   libobjc.A.dylib                     0x00007fff74b98720 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff48d08255 -[NSObject(NSObject) __retain_OA] + 0
	3   CoreFoundation                      0x00007fff48c2aad0 ___forwarding___ + 1486
	4   CoreFoundation                      0x00007fff48c2a478 _CF_forwarding_prep_0 + 120
	5   mas                                 0x000000010f3b7e53 $SSo14ISStoreAccountC3masE6signIn8username8password12systemDialogABSSSg_AHSbtKFZTf4nnnd_n + 947
	6   mas                                 0x000000010f3cdf3a $S3mas13SignInCommandV3runyAA6ResultOyytAA8MASErrorOGAA0bC7OptionsVFTf4nd_n + 410
	7   mas                                 0x000000010f3a8211 $S3mas14CommandWrapperVyACyxGqd__c11ClientErrorQyd__RszAA0B8ProtocolRd__7Options_AEQYd__AFRSlu33_E513F8A29DAA43E418079999EEBED6A7LlfcAA6ResultOyytAA010CommandantE0OyxGGAA14ArgumentParserCcfU_AA8MASErrorO_AA06SignInB0VTg5Tf4nd_n + 465
	8   mas                                 0x000000010f396cbb $S3mas14CommandWrapperVyACyxGqd__c11ClientErrorQyd__RszAA0B8ProtocolRd__7Options_AEQYd__AFRSlu33_E513F8A29DAA43E418079999EEBED6A7LlfcAA6ResultOyytAA010CommandantE0OyxGGAA14ArgumentParserCcfU_AA8MASErrorO_AA07AccountB0VTG5TATm + 11
	9   mas                                 0x000000010f396c40 $S3mas14CommandWrapperVyACyxGqd__c11ClientErrorQyd__RszAA0B8ProtocolRd__7Options_AEQYd__AFRSlu33_E513F8A29DAA43E418079999EEBED6A7LlfcAA6ResultOyytAA010CommandantE0OyxGGAA14ArgumentParserCcfU_AA8MASErrorO_AA06SignInB0VTG5TA + 16
	10  mas                                 0x000000010f3a6def $S3mas15CommandRegistryC4main9arguments11defaultVerb12errorHandlers5NeverOSaySSG_SSyxXEtFAA8MASErrorO_Tg507$S3mas8K43OIgg_ACIegn_TR010$S3masyAA8B6OXEfU_Tf3npf_nTf1nncn_nTf4nxn_n + 703
	11  mas                                 0x000000010f3940ca main + 5946
	12  libdyld.dylib                       0x00007fff75c66085 start + 1
	13  ???                                 0x0000000000000004 0x0 + 4
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Not signed in
Error: Not signed in
Error: Unable to install Amphetamine app. mas not signed in to Mac App Store.

mas works outside bundle:

$ mas install 937984704
Warning: Amphetamine is already installed

[MikeMcQuaid]

What does mas signin output outside brew bundle? What is your macOS version?

[shpoont]

Yep, it crashes. I have macOS 10.14

$ mas signin example@example.com
==> Signing in to Apple ID: example@example.com
Password:
2018-09-30 18:05:44.945 mas[32181:7647401] -[__NSXPCInterfaceProxy_ISAccountService signInWithContext:replyBlock:]: unrecognized selector sent to instance 0x7f8094616350
2018-09-30 18:05:45.000 mas[32181:7647401] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSXPCInterfaceProxy_ISAccountService signInWithContext:replyBlock:]: unrecognized selector sent to instance 0x7f8094616350'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff48c8b43d __exceptionPreprocess + 256
	1   libobjc.A.dylib                     0x00007fff74b98720 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff48d08255 -[NSObject(NSObject) __retain_OA] + 0
	3   CoreFoundation                      0x00007fff48c2aad0 ___forwarding___ + 1486
	4   CoreFoundation                      0x00007fff48c2a478 _CF_forwarding_prep_0 + 120
	5   mas                                 0x0000000103f04e53 $SSo14ISStoreAccountC3masE6signIn8username8password12systemDialogABSSSg_AHSbtKFZTf4nnnd_n + 947
	6   mas                                 0x0000000103f1af3a $S3mas13SignInCommandV3runyAA6ResultOyytAA8MASErrorOGAA0bC7OptionsVFTf4nd_n + 410
	7   mas                                 0x0000000103ef5211 $S3mas14CommandWrapperVyACyxGqd__c11ClientErrorQyd__RszAA0B8ProtocolRd__7Options_AEQYd__AFRSlu33_E513F8A29DAA43E418079999EEBED6A7LlfcAA6ResultOyytAA010CommandantE0OyxGGAA14ArgumentParserCcfU_AA8MASErrorO_AA06SignInB0VTg5Tf4nd_n + 465
	8   mas                                 0x0000000103ee3cbb $S3mas14CommandWrapperVyACyxGqd__c11ClientErrorQyd__RszAA0B8ProtocolRd__7Options_AEQYd__AFRSlu33_E513F8A29DAA43E418079999EEBED6A7LlfcAA6ResultOyytAA010CommandantE0OyxGGAA14ArgumentParserCcfU_AA8MASErrorO_AA07AccountB0VTG5TATm + 11
	9   mas                                 0x0000000103ee3c40 $S3mas14CommandWrapperVyACyxGqd__c11ClientErrorQyd__RszAA0B8ProtocolRd__7Options_AEQYd__AFRSlu33_E513F8A29DAA43E418079999EEBED6A7LlfcAA6ResultOyytAA010CommandantE0OyxGGAA14ArgumentParserCcfU_AA8MASErrorO_AA06SignInB0VTG5TA + 16
	10  mas                                 0x0000000103ef3def $S3mas15CommandRegistryC4main9arguments11defaultVerb12errorHandlers5NeverOSaySSG_SSyxXEtFAA8MASErrorO_Tg507$S3mas8K43OIgg_ACIegn_TR010$S3masyAA8B6OXEfU_Tf3npf_nTf1nncn_nTf4nxn_n + 703
	11  mas                                 0x0000000103ee10ca main + 5946
	12  libdyld.dylib                       0x00007fff75c66085 start + 1
	13  ???                                 0x0000000000000003 0x0 + 3
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6

I am wondering if this is an expected behavior for bundle to try to sign in with mas even though it is already signed in?

[MikeMcQuaid]

@shpoont That's the main bug, then.

I am wondering if this is an expected behavior for bundle to try to sign in with mas even though it is already signed in?

It's not expected behaviour. What's the output of mas account when signed in?

[shpoont]

It shows that I am not signed in. I found that there is an issue opened in mas repo mas-cli/mas#172
If I understand it correctly, when bundle detects that I am not signed in with mas, it will try to do that and will fail due to mentioned bug in mas.

[colindean]

mas-cli/mas#164 details that Apple removed an API in 10.13, but the workaround was to login to the App Store via the GUI. However, that workaround no longer works in 10.14.

@MikeMcQuaid Should we considering disabling mas integration on 10.14 until the bug is fixed? It seems like it would appropriate to put some error handling around that functionality, with a message that points users to this issue?

[colindean]

We could alternatively put in a flag or envvar that skips the signin step as a workaround with a warning that the installation won't work if not already signed in.

It'd skip this step:

homebrew-bundle/lib/bundle/mac_app_store_installer.rb

Lines 21 to 27 in bebdc64

	unless Bundle.mas_signedin?
	puts "Not signed in to Mac App Store." if ARGV.verbose?
	Bundle.system "mas", "signin", "--dialog", ""
	unless Bundle.mas_signedin?
	raise "Unable to install #{name} app. mas not signed in to Mac App Store."
	end
	end

[MikeMcQuaid]

It's not obvious to me what the solution is here. I'm signed in on Mojave but mas doesn't think I am. It seems as-is all you can do on Mojave is tell people to not use mas to install/update applications and just use it to query if applications are installed. This doesn't seem ideal but is probably better than nothing (or the status quo) but I'd welcome thoughts here.

We could alternatively put in a flag or envvar that skips the signin step as a workaround

Why would this be a flag and not the default?

[colindean]

Why would this be a flag and not the default?

In the short term, it probably should be the default.

For the long term, though, does bundle have the instrumentation to determine how often --mas-signin, or whatever the flag may be, is being used? I would think that all but newly set-up systems would be signed into MAS as soon as initialized. I think there's a step during macOS setup that handles MAS signin, but it's skippable – it's been about a year since I set up a new Mac.

Maybe the Bundle.mas_signedin? check could happen after the installation a few lines down and only as an exception: if installation didn't work, check if the user is signed in. If they weren't, recommend that they pass --mas-signin or go use to GUI to sign in if they are on 10.13/10.14 since mas signin is broken on those. It seems that mas account is broken on 10.14, so skip the check there until the bug is fixed.

Thoughts?

[jacobbednarz]

We could also catch the exception being raised from #mas_signedin? and point them towards the GUI (this might be a better longer term solution too).

[colindean]

How quickly should we address this? I could take a look at it in theory only, because I've not yet moved to Mojave and probably won't for another weekend or two.

[jacobbednarz]

I tend to do OS version stuff in a VM which allows isolation and to fix bugs in specific OS versions that you don't run. In terms of timing, I think that comes down to how widespread the mas + mojave usage is. For instance, if mojave is at 10% of the user base but only 0.5% of them are using mas, it might not be worth spending time on this and we can just wait for it to be addressed upstream.

In the same breath though, brew bundle could handle this scenario a bit better.

[colindean]

mojave is at 10% of the user base but only 0.5%

@MikeMcQuaid Can Homebrew's analytics answer this?

[shpoont]

This is a bit more general, but as an end-user, the best solution for me would be that when bundle is running, it would not stop and exit because of specific package installation fails. Exactly like it does with cask packages.

[atipugin]

Totally agree with @shpoont, it would be much better than failing with mas error. At least many setup scripts will continue to work.

[phatblat]

That crash has been happening since High Sierra changed the private API that mas used to authenticate. See mas-cli/mas#164 for details 😞

[phatblat]

FYI, the issue where 'mas account' always returns an error and says not signed in should be resolved in 1.4.3

[colindean]

@phatblat What's the behavior now?

[MikeMcQuaid]

mikebook $ mas signin mkmcqd@me.com
Error: The 'signin' command has been disabled on this macOS version. Please sign into the Mac App Store app manually.
For more info see: https://github.com/mas-cli/mas/issues/164