I think it should be possible to use the newer Sparkle with a 10.7 deployment target and weak-link it (coupled with checks for functionality before we call into it). This should cause dyld on Snow Leopard to load XQuartz but not the Sparkle.fw.
However, even if we updated to 1.13.1, that doesn't solve the entire vulnerability when using http. 1.13.1 is still vulnerable to DNS spoofing attacks when not using https. The only really good way to address this is by being able to make use of https, but we don't have that as an option on our current host. I would like to see an option in Sparkle that would allow us to ensure our appcast isn't spoofed (and thus guarantee that the DNS record of the domain that is hosting it isn't being spoofed). Sparkle's appcast format could be updated to include a URL to a signature of the appcast (signed with the same cert that we sign the installer payloads). Whenever the appcast is updated, we'd need to also update that signature file. Doing this and also ensuring that all ChangeLog content is on the same host would allow us to guarantee our content isn't being spoofed. Additionally, updating to 1.13.1 would mean that we'd be unable to make use of HTTP redirects in the future to automatically redirect users to new locations of Sparkle streams. As I mentioned earlier, this is actually something we're doing now to redirect users on older streams from xquartz.macosforge.org to xquartz-dl.macosforge.org, and we should soon have redirection to xquartz.org. I don't think that loosing this functionality is terribly bad. We could instead host a stream at the old location which has a final version that gets users onto the new stream. --Jeremy > On Feb 14, 2016, at 08:52, Joseph B. Gurman <[email protected]> wrote: > > It’s great that Jeremy is providing support to 10.6.8 users; there appear > to be plenty of machines still running it in the wild. We just upgraded our > last ones to 10.11 per corporate policy. > > Would it be possible to incorporate Sparkle 1.13.1 or later in the > framework for newer systems, and keep the existing, vulnerable > installer/framework in a version to continue supporting older ones, with the > appropriate warning? Or simply require folks with pre-Lion versions of the OS > to download by hand from the website? I know that means extra work for you > in basically forking the development or for the users of 10.6.8, but unless > the Sparkle devs do the work for you, it really appears that you’re stuck. > > You’re not alone: a quick survey of my third-party, non-App Store apps shows > that only 2 of 22 use a version of Sparkle newer than 1.5 beta 6. > > Joe Gurman > >> On Feb 10, 2016, at 12:32 PM, Jeremy Huddleston Sequoia >> <[email protected]> wrote: >> >> As many of you are aware, there is a MITM vulnerability in Sparkle which can >> be exploited to either deliver an incorrect appcast or ChangeLog. It is NOT >> possible for someone to take advantage of this vulnerability to install an >> invalid update of XQuartz. >> >> Sparkle developers have provided a workaround for the issue, but an >> appropriate fix for this vulnerability is not quite obvious: >> Considerations: >> 1) We support Snow Leopard which requires us to use the older Sparkle 1.6 >> series. >> 2) The patches available don't trivially cherry-pick back to 1.6 (I haven't >> looked into it more deeply than that at this time). >> 3) Even if we backported them, the changes prevent following http redirects. >> 4) We actually *use* http redirects. It is how we relocated from >> xquartz.macosforge.org/downloads/... to xquartz-dl.macosforge.org, and it is >> how we intend to redirect requests to our new host at github. >> 5) Github does not (AFAIK) support https for hosted sites. And if it did, >> it would likely cost money to pay for the dedicated IP address. >> >> In order to address part of this problem, the appcast schema could be >> updated to include a URL to a signature file. That signature file would >> contain the signature to validate the entire feed. This still allows for >> DNS spoofing of the ChangeLog data, but it looks like the upstream fixes >> don't really address that problem either (other than their recommendation to >> use https which is not feasible in cases like ours). >> >> I'm open to your thoughts. >> >> --Jeremy >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> X11-users mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/x11-users/joseph.gurman%40nasa.gov >> >> This email sent to [email protected] > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > X11-users mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/x11-users/jeremyhu%40freedesktop.org > > This email sent to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. X11-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/x11-users/archive%40mail-archive.com This email sent to [email protected]
