Bundle archives/installers directly with packages

[alexchandel]

Continuing the tangent from #382, packages should directly bundle archives in their nupkg instead of downloading it from the internet when possible. This avoids the risk of a remote download site getting hacked/hosting malware, which is especially relevant since most packages currently don't verify checksums. It also means that chocolatey packages are self-contained, and will continue to work even if a project has intermittent hosting.

This applies to both .portable and .install packages, as long as they aren't too large (~25MB was suggested).

It's also necessary for self-contained packages to be redistributable. For CC/public domain software there are no other caveats. For BSD/MIT/Apache licensed packages, the license (and any NOTICE file) should be included in the package. For GPL packages, the projectSourceUrl key in the package's nupkg should satisfy the "written request" requirement (in addition to including the license/NOTICE files). Etc. Most archives probably contain all these files already.

Archives could be either extracted and repacked into the nupkg, or stored directly within. The latter has the advantage that the chocolateyInstall.ps1 script can prove and verify the archive's checksum at installation.

The issue of multiple zipfiles for different architectures taking up space on the user's hard drive was also mentioned; I think the resolution might be simply to delete the archives after installation.

[alexchandel]

I could be wrong, but I don't think Install-ChocolateyZipPackage currently supports installing local archives, although it can do checksums.

[ferventcoder]

For GPL packages, the projectSourceUrl key in the package's nupkg should satisfy the "written request" requirement (in addition to including the license/NOTICE files).

I believe either of these could satisfy that request.

[ferventcoder]

For the local files, it is Install-ChocolateyInstallPackage and Get-ChocolateyUnzip

[ferventcoder]

Granted we could probably make the others a local path and try to determine that and use it instead of downloading.

[ferventcoder]

As an FYI, once they are in the package, the checksum is what we'll see on https://chocolatey.org under files. For example, check out https://chocolatey.org/packages/chocolatey/0.9.10-alpha-20150725#files and click on the show for choco.exe.

[ferventcoder]

The same will need to be done for zip/7z files.

[ferventcoder]

I created that issue for chocolatey.org here: https://github.com/chocolatey/chocolatey.org/issues/207

[aronovgj]

i don't quite see how this is more secure to download from chocolatey.org than from the developers website. both could be hacked. i see this only as a possibility if there is no more official source to get the software from (and if the license allows it).

bundled archives would increase traffic on chocolatey.org. even more and in a really unnecessary way if you always have to download both 32 and 64 bit.

also downloading from original sources was the special thing about chocolatey.

[ferventcoder]

i don't quite see how this is more secure to download from chocolatey.org than from the developers website. both could be hacked. i see this only as a possibility if there is no more official source to get the software from (and if the license allows it).

Both can be hacked now. Arguably downloading it as part of the package (which the hash is verified with choco dot org) allows for only one source to be hacked. Not sure which is better though.

bundled archives would increase traffic on chocolatey.org. even more and in a really unnecessary way if you always have to download both 32 and 64 bit.

This area needs more thought. I think we'll want to have architecture specific packages before this.

downloading from original sources was the special thing about chocolatey.

Yes, it's a good thing! But also a pain point when those archives are removed or changed.

[aronovgj]

Both can be hacked now. Arguably downloading it as part of the package (which the hash is verified with choco dot org) allows for only one source to be hacked. Not sure which is better though.

so there is no way someone can get access to chocolatey.org and manipulate all packages and their hashes into always downloading the same malware? i'm very skeptical about that...

[ferventcoder]

so there is no way someone can get access to chocolatey.org and manipulate all packages and their hashes into always downloading the same malware? i'm very skeptical about that...

No, I'm not stating that. I'm stating that the attack surface is different. But actually as I think about it, it's really no different than what we have now, b/c once someone compromises chocolatey.org, they can point the packages to where ever they want. Which means they can deliver a package that has malware or worse.

[aronovgj]

once someone compromises chocolatey.org, they can point the packages to where ever they want.

my point.

[ferventcoder]

@aronovgj but that could happen currently. So we'd be no worse off bundling.

Of course, if you trust TLS and certificates, it's the same as compromising any site. Not the easiest thing to do, technically possible though.

[aronovgj]

hm still doesn't feel right. if i want to install a package i can look at the link and i know that it comes from the original developers site. i know i can trust this package (as it is unlikely that the dev site was hacked).

if this is packaged and i am a new user you first have to explain to me that there is moderation and checksums and all that stuff so that i can trust you. and who tells me that chocolatey won't start doing the same thing that sourceforge does, including modified installers into packages (again, as a new user)?

also what will happen to trusted packages? say a trusted package maintainer goes berserk and starts including modified installers into the packages or he decides to get the setups from a site like sourceforge instead of the original site, for whatever reason. i have no chance verifying that what is included is what i want. i would at least have a way to know if i could see the download link. the checksums would be useless since they would match the modified package.

[ferventcoder]

@aronovgj All good points. :)

[alexchandel]

Chocolatey vets packages, whereas sourceforge/oracle/whoever are free to bundle junkware. The Windows software ecosystem is sick, and this happens disturbingly often. Someone running chocolatey as Administrator has to trust chocolatey, but they needn't be forced to trust every website chocolatey downloads from too. Compare to Linux package managers, and to Homebrew, which all host their own packages.

[aronovgj]

chocolatey downloads mostly from the developers websites. if i don't trust them, i probably don't trust the software either. so why should i trust chocolatey more than those original sites? and although cocolatey has guidelines for moderation, chocolatey is free to change them to whatever it wants to.

sure people shouldn't be forced to trust every site that chocolatey downloads from right now but i think you can expect people to trust original sources. and for cases like sourceforge including software into packages is still a better option in my opinion

[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.