Rename 'background item' for better clarity in macOS 'Login Items' list

[nxg]

With the release of macOS 13, the ‘General > Login Items’ display has changed, and now encourages the user to review the list of applications which they should ‘Allow in the background’, prompting them with a pop-up notification.

One of the items is listed as ‘Adam Maxwell’, and I'm assuming (after a little bit of googling) that this is in fact a tlutility-related task, and thus legitimate. Presuming, Adam, that you're not actually sending your spirit guide to haunt my computer, it may be that there is some slightly different bit of metadata that could be made available, to appear helpfully in this list.

Also, I notice that one or two of the items in this list have a circled-i next to the switch, which links to the binary in question. This is useful, as well.

[amaxwell]

Oh, wonderful. Is there an icon or anything that helps identify which binary it's pointing at? The only place they'd get my name (that I can think of) is the certificate used in the code signing process. It's probably the scheduled update checker, but could also be the TLUNotifier. Thanks for letting me know.

[nxg]

I've attached an image of the ‘Login items’ preferences^W settings panel, and one of the notification window that pops up.

• Login items window:
• Associated notification:

The icon besides Adam Maxwell appears to be a generic one (and ‘Adobe Creative Cloud’ has the same (not 100% sure what that latter one is doing there...)). The ‘info’ icon beside dbus-daemon opens up a Finder window with the relevant binary highlighted (and no other information).

For reference, there appear to be 17 items in this list on my machine, one other of which has a mysterious name (ie, one which isn't obviously linked to an application), and the majority of the others do have an icon associated with them. The dbus-daemon are the only ones which have the info icon.

The other items appear to be application names, apart from one Joshua Root, which a bit of digging suggests is associated with MacPorts, and... yup, Joshua Root has contributed some MacPorts software, so this is presumably coming from a personal certificate.

So yes, it does appear as if this string is indeed coming from a certificate, but presumably there's some different bit of application metadata which would be used as a display name, falling back to a certificate principal.

This is macOS 13.1. Thanks for your work on this.

[flipphillips]

If you leave your machine idle for a while, you get an infinite number -

[amaxwell]

Well, this is embarrassing. I may have to push out an update that just kills the automated update check feature on Ventura, because I have no idea how to control any of this crap that Apple is doing.

[flipphillips]

I recall a search a while back saying that this was supposed to be fixed in 13.1. A colleague just found some evidence to the contrary (and my screen shot above, of course). So it's probably not 'you', it's 'Apple'. But honestly, trying to track anything down specifically on developer.apple.com has been a bit of an exercise in futility.

[amaxwell]

Yeah, I think what you're seeing is a bug, Flip. It's maddening that this is a problem at all, though, since they could have eliminated it by adding something like "texliveupdatecheck," which is (probably) the binary in question, or given you the ability to see what was being added. Using the developer's name is about as useless as I'd expect from Apple's security theater department, though.

Agree on futility. All of my code is pretty ancient (the update checking dates back to 2010), because a) Apple's documentation is now useless, b) I hate all Xcode versions after 3.x, and c) I support the oldest hardware/software possible. Ironically, I rewrote the update check binary itself last February when Apple removed Python after releasing Monterey. Glad to see that massive emergency effort lasted all of 9 months before Apple broke things again.

[flipphillips]

I'm 100% with you. There are a bunch of things in the Launch Daemon preferences panel that just reference 'open' and 'bash'. You click on the (i) (if there is one) and it either takes you to the bash executable or nowhere. It is pretty f'n opaque right now. 9:10 times I wrongly/unfairly blame our IT / Jamf / MDM for installing some harebrained monitor dictated by our institute's legal department. I owe them a beer.

I'd like to go back to THINK C / Lightspeed I think. Megamax. Metrowerks...

Honestly, I just do everything in Mathematica for the past few decades. And - I love that you support the oldest stuff possible. I had a grad student who, out of insanity/boredom, bought a Mac SE off of eBay and did his dissertation in OzTeX (just like me, but on a PowerMac and a few decades before :)

[nxg]

+1 from me.

I've written very little on macOS above the unix layer. My one experiment in NSFoo-land gave me the strong impression that Apple documentation was one of those cases where the documentation is comprehensive (or at least voluminous, which isn't quite the same thing) and apparently correct, but also constantly changing and hard to keep track of: a maze of twisty little passages, all alike. Less fun than I anticipated...

The point to this comment is: rather you than me; and thank you!

[flipphillips]

Yes - none of this makes me particularly angry, in that @amaxwell is doing this out of the goodness of his heart, as many of all of us open source / whatever people do. I have a development system and environment that I don't have to pay for, etc etc etc. But still :)

[amaxwell]

Reminder to myself to STFW for AssociatedBundleIdentifiers, which may fix this issue.

[mhooreman]

Workaround

You can avoid this system popup message by disabling TexLive utility's auto updated (e.g. setting it to never). See screenshots below (in french, sorry).

• That way, the Adam Maxwell service disappears from the ‘General > Login Items’ elements
• But, obviously, you'll have to update LaTeX by yourself

[amaxwell]

Hopefully the latest beta works around this. If not, I'm kind of hosed until I move to a newer development platform (which probably means dropping an older OS version or two). It will probably require logout/login or possibly a restart, but hopefully this gets my name out of your System Preferences.

https://github.com/amaxwell/tlutility/releases/download/1.54b6/TeX.Live.Utility.app-1.54b6.zip

[nxg]

This works for me: I see 'TeX Live Utility' and a nice logo in the 'Login Items' list. I haven't yet done a restart to see if the warning that pops up is better phrased, but when I do, I'll report back here if not.

One possible glitchette: when I move the new TeX Live Utility from ~/Downloads into /Applications/TeX and start it, I get a warning from Little Snitch, as in this screenshot:

I don't know if that's Little Snitch being over-fussy, or TLU not saying 'no, I'm supposed to be in /Applications/TeX, honest'.

For what it's worth, I'm broadly pro Apple's recent shift towards paranoia, even if some elements of it are potentially tending towards theatre. I quite like being warned about this sort of stuff, and though I've shared my grumbles (and sympathy) about Apple documentation above, as a user I get something of a warm glow here.

[amaxwell]

First, thanks for the check, and I'm glad to hear this should fix the major problem.

To your other question, TLU does not care where it's run from, and I find it annoying that Apple and Little Snitch are suggesting otherwise: I'm old enough to believe a good Mac application will run anywhere, without needing an installer. I call it security theater because it's fragile and silly, and depends on extended attributes and how the application was launched. According to https://lapcatsoftware.com/articles/app-translocation.html, if you just move it somewhere (any folder, not just /Applications), the translocation bit gets flipped off.