Why does Sparkle disallow file:// URLs for update feeds in 2.8.0?

[gao-jx]

Hello Sparkle team,

I noticed that Sparkle enforces a restriction on NSURLRequest in 2.8.0, preventing the use of file:// URLs for update feeds.

 // Prevent any unwanted URL schemes (e.g. file://)
NSString *scheme = request.URL.scheme;
if (scheme == nil) {
    NSString *message = @"The download request scheme must not be nil";
    NSError *error = [NSError errorWithDomain:SUSparkleErrorDomain code:SUDownloadError userInfo:@{ NSLocalizedDescriptionKey: message }];
    [_delegate downloaderDidFailWithError:error];
    return;
}

if ([scheme caseInsensitiveCompare:@"http"] != NSOrderedSame && [scheme caseInsensitiveCompare:@"https"] != NSOrderedSame) {
    NSString *message = [NSString stringWithFormat:@"The download request URL must use http or https (%@)", request.URL];
    NSError *error = [NSError errorWithDomain:SUSparkleErrorDomain code:SUDownloadError userInfo:@{ NSLocalizedDescriptionKey: message }];
    [_delegate downloaderDidFailWithError:error];
    return;
}

In my current integration, due to certain environmental constraints, the update XML can only be provided locally (via a file) instead of being hosted over https or http.

Could you please explain the technical or security reasons behind disallowing file:// URLs?

[zorgiepoo]

It was an entry point to malware abusing the downloader service to download files locally from protected locations. Two of sparkle's reported security vulnerabilities overall have been partly due to allowing file:// in one place or another. Before 2.7.3, file:// was already blocked for release notes files and update download files (so you couldn't have downloaded an update through file:// before in 2.x). It was unintentional that the feed URL was still allowed to be file:// I suppose.

A local web server over http would serve you better if you can't use a real remote https server. The Sparkle Test App works through setting up a local web server.