- Update to latest version of Sparkle framework (1.13.1; http://sparkle-project.org/)
- Serve AppCast update feed (http://xquartz.macosforge.org/downloads/sparkle/release.xml) via HTTPS only to prevent MITM attacks.
There is no vulnerability here. We don't really care if someone MITM's our connection to the update server because if they give an invalid payload, the signature will fail.
Furthermore, github does not support https.
Oh, you're saying the vulnerability isn't in spoofing the update payload but rather the web page itself. Well, there's not much we can do about that unless github starts allowing https traffic. This is the reason we have this exception in our Info.plist:
It's not about GitHub, it's about using https://xquartz.macosforge.org/downloads/sparkle/release.xml for AppCast feeds instead of http and updating to the latest Sparkle framework. That's it.
We're no longer hosted at MacOSForge. We're hosted at GitHub. The update feed is located at http://www.xquartz.org/releases/sparkle/beta.xml, and unless github starts offering us a way to access that via https, we don't have a way of addressing this. This is why we have to add xquartz.org to the whitelist.
Surely there is no reason to not update to the patched 1.13.1 Sparkle Framework version:
As for no vulnerability
1) We can't update to 1.13.1 because we support Snow Leopard clients.
2) The upstream changes simply block http redirect, but we rely on http redirects for current server moves (and that might be needed in the future). Their solution is to use https (which would be great if we could).
3) 1.13.1 doesn't protect against DNS spoofing. You can still MITM 1.13.1 when using http using DNS spoofing attacks. https is the only solution.
4) github does not support https for hosted sites.
Please see my post to x11-users about the issue and why it's not as trivial a fix as you seem to think and reply to that thread.
If you have a viable solution (eg: you know somewhere that will provide free hosting with a dedicated IP address, so we can use https, I'd be happy to use that for the feed.
@Jeremy, you mention that this limitation is because of GitHub not offering HTTPS on hosted sites, but I found this article: https://github.com/blog/2186-https-for-github-pages. Is it possible for you to change to the *.github.io short name for this update feed and utilize the provided HTTPS?
We switched hosting to be able to use https. This was addressed about a year or so ago.