Replies: 1 comment
-
Moving to discussions for now as it's not quite clear what can and should be done here. There could be a bug somewhere or a bad actor somewhere, and this may be getting kind of technical to report. Perhaps a first step is just logging extra error information. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have users reporting that downloaded archives sometimes fail to verify (files are too short by 1 byte, or the signature doesn't match), even though the archives are served as static files via HTTPS.
I wonder if this could be caused by MITM proxies that intercept HTTPS by adding their own CA-cert to the trust store (e.g. corporate proxies, antivirus software).
I think it'd be very useful if Sparkle could detect HTTPS MITM and report it to the user. If a download signature is broken, and the cert is signed by a custom CA added to the trust store, report that the file may have been changed by the MITM. Or read which cert the origin has responded with, and include hash and/or issuer of the cert in the error reported to the user, so that I can check if it was my cert when I get the report.
Unfortunately, these seem difficult, since I haven't seen anything TLS-cert related on
NSURLSessionConfiguration
.Beta Was this translation helpful? Give feedback.
All reactions