Re: Sparkle and XQuartz
Re: Sparkle and XQuartz
- Subject: Re: Sparkle and XQuartz
- From: "Joseph B. Gurman" <email@hidden>
- Date: Sun, 14 Feb 2016 11:52:41 -0500
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@hidden> 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@hidden)
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden