- New hack, Handsy. I modeled and animated it by "hand", heyyo. I tried considered using the Leap Motion Controller API to snapshot real hands, but that device is crap at detecting poses with any precision.
- I rewrote Unknown Pleasures: it's a true waterfall graph now. I eagerly await someone figuring out some interesting real data to feed into it.
- BSOD Solaris is far more accurate. DVD added.
- Dali Clock works again, both the screen saver and the Mac app. Also rotation works again in the iOS app. (It is a longstanding Apple tradition that you have to rewrite the mobile rotation code from scratch every 18 months.)
(Oh, wait, apparently while Apple accepted my submission of Dali Clock to the Mac App Store, they rejected the bug-fix update to the iOS App Store, because the anonymous $1/day contractor in some third-world call center hellhole has decided that it has "minimal functionality". Awesome. Appeal in progress.)
- Fonts are better on X11. I fixed them in 5.39 but then broke them again in 5.40, oops.
- Saver settings work again on macOS 10.14.
- Plugged many memory leaks on Android and iOS. On the mobile platforms, freeing memory at exit matters, since the savers all run in the same address space. It's not an issue on the desktops, because the process goes away at exit.
- If you're on Linux, and the xscreensaver daemon is setuid, then we can implore the kernel's out-of-memory killer to pretty please not unlock the screen. It might work, maybe.
- MacOS has an upgraded Sparkle (the "Check for Updates" library). Let me know if the auto-update works.Update: It did not work in 5.41. I have released 5.42 to hopefully fix this...
- The DMG is now "notarized" and "stapled" by Apple, which I think means that on 10.14 you should be able to open it without getting the "unknown developer" dialog. (It is a longstanding Apple tradition that you must re-learn how to do codesigning every 18 months.) Again, let me know if it works.
- The Android version is back in the Google Play store. I had stopped updating that because somehow I lost the signing key. To get it back in the store I had to change the Application ID (from org.
jwz. to org.xscreensaver jwz. ). This means that to upgrade to the new one, you will probably have to manually delete the old one first, just this one time.android. xscreensaver
XScreenSaver 5.42
Tags: computers, firstperson, linux, mac, mpegs, phones, robots, xscreensaver
31 Responses:
Those 18 month rewrite rituals are most of why I don’t really miss iOS development all that much.
After updating to 5.41 using the built-in updater from my previous version on macOS 10.14, every time I click on an xscreensaver in the settings.app, I get a popup with "XScreenSaverUpdater cannot be opened because of a problem" and:
Termination Reason: DYLD, [0x1] Library missing
Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
Library not loaded: @rpath/Sparkle.framework/Versions/A/Sparkle
Referenced from: /Library/Screen Savers/XScreenSaverUpdater.app/Contents/MacOS/XScreenSaverUpdater
Reason: image not found
Not sure what's going on, there is a sparkle binary here:
% file /Library/Screen\ Savers/XScreenSaverUpdater.app/Contents/Frameworks/Sparkle.framework/Versions/A/Sparkle
/Library/Screen Savers/XScreenSaverUpdater.app/Contents/Frameworks/Sparkle.framework/Versions/A/Sparkle: Mach-O 64-bit dynamically linked shared library x86_64
Well, shit.
I think I see the problem.
Ok, I just pushed out 5.42. I suppose that if you have already installed 5.41, you'll have to install 5.42 manually...
Yup, 5.42 works fine and no crashes, and the updater binary launches without complaint even in a terminal What was the problem/fix?
otool -L Contents/MacOS/XScreenSaverUpdaterstill references@rpath/Sparkle.framework/Versions/A/Sparkleso the path was right all along, I guess?Missing LD_RUNPATH_SEARCH_PATHS = "@loader_path/../Frameworks"
If you've changed the application ID on Android, then from Android's point of view it's a whole new app, unrelated to the old app, and will happily install alongside the old one.
I thought I had seen the Android emulator tell me "two apps can't have the same name", but maybe something else was going on.
Two apps can't have the same application ID and different signing keys.
If for some reason you are using a sharedUserId in the manifest, then that might create a conflict with the old app if the sharedUserId's are the same, but the signing keys are different.
Another minor nitpick - the files in /Library/Screen Savers from xscreensaver on a mac are mostly owned by
503:_appleeventsor503:staff. Shouldn't they be owned byroot:wheel? Is your uid on your development mac 503 by any chance :PHuh. Anyone know if there's a way to tell hdiutil makehybrid to pretend to have chowned everything before building the DMG? Or is doing my builds as root the only way to do that?
The macOS DMG doesn't seem to be code-signed, just fyi.
https://i.imgur.com/UHitEDf.jpg
Standalones are good (signed & notarized).
https://i.imgur.com/1Boei6i.jpg
The DMG has never been signed, but the PKG inside of it is:
However the DMG is Notarized and Stapled:
Ah, thank you. Didn't know the xcrun command. Nice.
Has signing a DMG ever actually done anything?
If so, does Stapling it make whatever-that-did obsolete?
Signing a dmg prevents its contents from being modified after you create it. If you ship a few different apps, plugins, etc. together, it is a good way to wrap them. If you don't sign a dmg, the apps in it are "translocated" on launch (relocated to a random folder) so that an attacker can't get you to run their plugins just by dropping them nearby the app.
Stapling attaches a ticket to the dmg, and the ticket lists recursively all the contents of the dmg. It's a receipt that shows Apple has seen/scanned all that code, and Gatekeeper checks it on launch. You need to sign all code you intend to notarize, though you don't have to sign dmgs (not code).
There's a lot more, including custom build script examples, at this page and its sub-pages: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
But the DMG is already a UDBZ read-only file system and can't be modified. What's the attack here?
Do any of Apple's various warning dialogs go away or change if the DMG is signed versus unsigned?
Right, and I've done that. Everything inside the DMG is properly signed, or else the stapling wouldn't have worked.
In what way does the Gatekeeper warning dialog change for notarized versus un-notarized DMGs? I haven't been able to find a clear explanation of that.
An attacker could bypass Gatekeeper by getting a trusted binary to load their code for them. Here's some history of the set of attacks that led to translocation being introduced:
https://www.synack.com/2016/12/16/untranslocating-apps/
No dialogs change when you sign dmgs. Either you sign it or it gets translocated on launch, but whichever one happens is invisible to the user.
The page I linked to shows the change in the Gatekeeper dialog for notarized apps. It's currently rather small (one additional sentence stating the app has been scanned by Apple), but it was a bigger difference in the 10.14 betas (the app's icon was highlighted in green instead of the grey "lock house" icon it normally has).
Based on a recent article, Apple seems to be planning bigger changes: "Starting spring of 2019, macOS Mojave will more prominently highlight notarization status. In an upcoming macOS release, Gatekeeper will require Developer ID–signed software to be notarized by Apple."
https://developer.apple.com/news/?id=11302018a
I get that, but now that they do translocation, it doesn't matter, right? Apple would translocate any (signed) apps inside the (unsigned) DMG, and it's all fine.
I mean, I might as well sign it anyway, it's easy, but you seem to be saying that doing so solves a real-world problem and I don't get what that is.
If you need an app within your dmg to reference external frameworks or other resources within the dmg, then translocation will break it. Your best option is to sign the dmg in this case as it keeps the app and other resources together.
If your app is standalone, there’s no difference.
I guess you could get UnknownPleasures to show histograms from the image capture side of xscreensaver. Or WebCollage.
Or perhaps from a microphone input, as a compliment to the camera input?
Handsy is so good, I've set it as my phone wallpaper and it's given me a few laughs - nice work.
Feature request: Furr Division
https://www.threadless.com/designs/furr-division
Handsy is great, but sometimes the transitions between poses are annoyingly unphysical. I guess that might be a hardish problem to solve though.
Found a bug on Android; it seems that if I click on "Open Daydream list" to open the "screensaver" menu, clicking on "Open live wallpaper list" afterwards will only take me to the "screen saver" again and again. Restarting the app fixes this, and takes me to to the "Live Wallpapers" menu.
(Pixel 2, Android 9)
Handsy is a cool addition, but I run xscreensaver at work. Can you add an option to exclude NSFW gestures?
Or maybe all the gestures are NSFW and I don't understand half of them? Could be...
I run xscreensaver at work too and my boss says it's fine.
is Webcollage in the Android version? I can't seem to find it in either daydream or live wall papers.
Pixel3, Android 9
additional: the live wallpaper bit is awesome. handsey is currently insulting me, etc.
No, since WebCollage is primarily written in Perl, it's basically impossible to make it work on mobile.
There are quite a few others that are not included in the Android build because they don't work right. They are listed and explained in xscreensaver/android/README if any of you want to help...