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/archive%40mail-archive.com
This email sent to [email protected]
