Move towards avoiding sourceforge URLs

[alexchandel]

SourceForge has recently taken to bundling trojans and adware in the downloads of packages they claim are "unmaintained" (regardless of whether this is actually true, as was the case for GIMP).

While I personally think that downloading executables from non-Chocolatey (and non-Microsoft) websites ought to be avoided for security reasons unless a license forbids redistribution, and that those downloads should be MD5-validated, this goes a step further. There's simply no telling whether SourceForge will decide to slip malware into a particular installer, or when this will happen. Nor can we, nor should we rely on package maintainers to constantly monitor their URLs and guarantee they remain malware-free. The only path that provides forward security is to treat all SourceForge URLs as currently hosting malware.

What can we do? I would say that new packages and updates to existing packages that download from SourceForge should not be accepted. It is conceivable that special exemptions might have to be made for packages that are hosted nowhere else and cannot be redistributed, but those should be few and far between.

[ferventcoder]

See the following conversation - https://groups.google.com/forum/#!topic/chocolatey/Skt3DaZ2tjQ

[alexchandel]

@ferventcoder thanks, it's good to hear they don't currently do this on silent installs. But the fact that did with normal installs makes me suspicious of their intentions. Blocking SF URLs from the client is probably too extreme, but I think discouraging them in packages/updates might still be warranted.

On an unrelated note, the problem of future hosts being corrupted (either intentionally or by hacking) could be mitigated by encouraging the direct packaging of MIT and BSD-licensed software, which is freely redistributable as long as the license comes with it. GPL software can also be redistributed, but every GPL package would need a projectSourceUrl key to fulfill the "written request" requirement.

[ferventcoder]

On an unrelated note, the problem of future hosts being corrupted (either intentionally or by hacking) could be mitigated by encouraging the direct packaging of MIT and BSD-licensed software, which is freely redistributable as long as the license comes with it.

:+1:

GPL software can also be redistributed, but every GPL package would need a projectSourceUrl key to fulfill the "written request" requirement.

Yep. :)

[RichiCoder1]

I've always been curious why packaging the installer with the package wasn't the default mode of operation. Very odd that most packages defer to downloading installers separately.

[ferventcoder]

@RichiCoder1 I don't think it started out that way. I think it was more that I packaged a bunch of non-Open software when I started out and folks used those as starting points. It kind of grew that way instead. I'd certainly prefer packages that are self-contained, as long as they are not over 25MB or so.

[alexchandel]

@ferventcoder It occurs to me that direct packaging may require some tweaking for ones that have both x86 and x64 versions. Possibly there would be one package for each architecture, each of which provides the portable package, which itself is a virtual package that provides the main one. What would the naming convention be, e.g. vlc.x86.portable, vlc.x64.portable, vlc.x86_64.portable, vlc.amd64.portable?

[alexchandel]

And presumably shimgen would know to only shim a single version, since practically every exe would collide. I'm not sure you can say they conflict though, since they would unzip to separate sandboxed folders.

[ferventcoder]

@alexchandel if there were two zips in the package and only one is unzipped based on the architecture you choose, then not sure if there is a need for naming like the above. Trying to stay out of the complexity until it is required. And hopefully by then we will have a better answer in the package names

[alexchandel]

@ferventcoder I was hoping more to avoid having to double the user's download time / HD usage, especially if one zip isn't used. For example each VLC zip is ~20MB.

Also, are there any advantages to bundling the archives inside of the nupkg, instead of extracting them beforehand and packing the files directly into the nupkg? I imagine it saves cpu/io time to only unarchive once, but it may save space to have nested archives when the inner one is lzma or something more efficient than nupkg.

[ferventcoder]

The archive checksum can be verified (the one that might be posted to the original distro website) is one big advantage.

[ferventcoder]

This conversation has moved from the original ask - let's move it to a new issue or a conversation thread to determine the requirements of what we want to do.

[aronovgj]

i've read that sourceforge installers behave differently (less crap distributing) when executed in a virtual machine. i wouldn't trust this if it was tested in a vm: https://gist.github.com/ferventcoder/b5945d959cecfbe82141

someone claims this at least. still i'd be careful. https://news.ycombinator.com/item?id=10029897

and probably the source: http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/

In our testing, we’ve found that SourceForge’s downloader behaves more nicely in a virtual machine. If you want to see what it actually does, be sure to test it in a real Windows system on a physical machine, not a virtual machine.

This is the same sort of behavior that malicious applications are increasingly using to avoid detection and analysis.

[github-actions[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue will be closed in 14 days if it continues to be inactive.

[github-actions[bot]]

Dear contributor,

As this issue seems to have been inactive for quite some time now, it has been automatically closed. If you feel this is a valid issue, please feel free to re-open the issue if / when a pull request has been added. Thank you for your contribution.