XScreenSaver 5.42


XScreenSaver 5.41 5.42 is out now, including iOS and Android.

  • 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.xscreensaver to org.jwz.android.xscreensaver). This means that to upgrade to the new one, you will probably have to manually delete the old one first, just this one time.
Tags: , , , , , , ,

31 Responses:

  1. Shauber says:

    Those 18 month rewrite rituals are most of why I don’t really miss iOS development all that much.

  2. ff says:

    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

    • jwz says:

      Well, shit.

      I think I see the problem.

    • jwz says:

      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...

      • ff says:

        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/XScreenSaverUpdater still references @rpath/Sparkle.framework/Versions/A/Sparkle so the path was right all along, I guess?

  3. Wilhelm Fitzpatrick says:

    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.

    • jwz says:

      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.

      • Wilhelm Fitzpatrick says:

        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.

  4. ff says:

    Another minor nitpick - the files in /Library/Screen Savers from xscreensaver on a mac are mostly owned by 503:_appleevents or 503:staff. Shouldn't they be owned by root:wheel? Is your uid on your development mac 503 by any chance :P

    • jwz says:

      Huh. 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?

  5. Joss says:

    The macOS DMG doesn't seem to be code-signed, just fyi.

    https://i.imgur.com/UHitEDf.jpg

    • Joss says:

      Standalones are good (signed & notarized).

      https://i.imgur.com/1Boei6i.jpg

    • jwz says:

      The DMG has never been signed, but the PKG inside of it is:

      /Volumes/XScreenSaver 5.42/Install Everything.pkg: accepted
      source=Notarized Developer ID

      However the DMG is Notarized and Stapled:

      xcrun stapler validate xscreensaver-5.42.dmg
      Processing: xscreensaver-5.42.dmg
      The validate action worked!

    • jwz says:

      Has signing a DMG ever actually done anything?

      If so, does Stapling it make whatever-that-did obsolete?

      • Nate says:

        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

        • jwz says:

          Signing a dmg prevents its contents from being modified after you create it.

          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?

          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).

          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.

          • Nate says:

            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

            • jwz says:

              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:

              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.

              • Nate says:

                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.

  6. Steve Jones says:

    I guess you could get UnknownPleasures to show histograms from the image capture side of xscreensaver. Or WebCollage.

  7. Tom says:

    Handsy is so good, I've set it as my phone wallpaper and it's given me a few laughs - nice work.

  8. db48x says:

    Handsy is great, but sometimes the transitions between poses are annoyingly unphysical. I guess that might be a hardish problem to solve though.

  9. Pavel says:

    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)

  10. Paul says:

    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...

  11. option12 says:

    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.

    • jwz says:

      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...