mikecole/gist:3b4c81222f0312ee1868848d64e85ccc

## gistfile1.txt
Chocolatey Community Package Maintainers Update - August 2016
Welcome to the inaugural email update for Chocolatey community package maintainers. We need a way to provide important information to the community maintainers, so we created this list. If you are no longer maintaining packages on Chocolatey.org, simply unsubscribe from future emails at the bottom of this list. Also, you can respond directly to the email if you have questions or concerns.

Checksums Required For All Future Package Approvals
tl;dr - Moving forward packages will not be approved without checksums if they download remote resources (exact date to be determined). This includes trusted packages.

In July 2014 Chocolatey added the ability for package maintainers to provide checksums for downloads. Over the last two years many of you have added checksums to your packages to provide an additional layer of protection for the community, thank you so much for that! We've been planning a move to requiring checksums and were hoping for a gradual and smooth migration on that requirement. However many of you are aware of a recent incident related to FossHub being hacked. Audacity issued a pretty comprehensive report.

We responded:
03 AUG 2016 @ 10:24 AM CDT - We learned of FossHub breach
Started gathering information of extent of possible issues for community repository.
There were 8 (of 4,000+) packages on the community repository that were using FossHub but not using checksum protection. There are more than 8 packages using FossHub, but those packages have checksum protection (users were protected).
11:54 AM CDT - Issued a customer advisory. Followed up to provide that notice to the community at large.
As a security precaution, we took swift action to remove those packages and contact the maintainers.
1:14 PM CDT - Issued a customer advisory update.
The community was protected in a matter of less than 3 hours after learning of this breach.
Based on the reports from FossHub's timeline, they had already taken action to remove/limit the damage and had replaced the malicious software binaries prior to our response. Most of our actions were to notify folks who could have possibly been at risk and to take additional actions to limit potential issues for our community as we waited to find out the complete scope of the damage.

Even with the actions we took to protect the community, we feel that it is not enough for packages that download remote resources from other sites. Even though folks using licensed versions take advantage of both a private CDN (so they would not have even downloaded the affected binaries) and a runtime VirusTotal verification of binaries that are downloaded, we feel there is more that we need to do to ensure the protection of the entire community.

Imagine a security breach at a more prominent site with something more malicious. We want to ensure the amount of work to contain a security incident for the Chocolatey community is to notify all of our customers that there was an issue and they are protected.

Due to the recent events, we no longer feel it is safe to attempt a gradual transition and instead need to provide a quicker transition to protect the community (and yes, a bit rougher for all of us who maintain packages on the feed currently). We understand this may be a bit rougher, so we are providing a little bit of time for you to get your packages updated before moderation sets the requirement flag.

Even though we are providing you more time before the moderation requirement, we still need to take action to protect the community. This week we will release Chocolatey v0.10.0 that will require checksums when downloading over HTTP/FTP and fail otherwise by default (although users can allow empty checksums in packages with an option or feature). Following soon after, likely in 0.10.1 or 0.10.2, choco will fail all packages without checksums, including HTTPS downloads. See #112 and #895 for more details.

Here it is in action (the wording is subject to change a bit to advise against allowing empty checksums):

Choco install of a package that downloads from HTTP without a checksum
Note: This package is getting converted to HTTPS and will add checksums through auto packaging.

Why checksum protection?
Checksums are an integrity check to ensure that the binary downloaded is the same binary that the maintainer intended. Further, it validates that users receive the same binaries that passed moderation, and that were validated against VirusTotal and its 50+ scanners. Every package has a comprehensive check against VirusTotal (and we will are hoping to make VT scans part of the automated review process at some point).

You can consider checksums as a 3rd party verification for downloaded software. It doesn't necessarily need to be the same checksums that may be provided by the origin site, you can provide a higher level checksum like SHA256. It's a level of protection that is a necessity for HTTP as MITM (man in the middle) attacks are pretty easy to implement (DNS poisoning is also a concern), and it becomes a necessity even for HTTPS as a remote site could get hacked (which could be exploited in a similar way to what we saw recently with FossHub).

How can I calculate checksums?
Install checksum - `choco install checksum`
Download the binaries you want to use with the package.
Call `checksum -t sha256 -f path\to\file`. Add that to your function arguments. See PowerShell Function Reference to learn how to pass those to the function you are using (another method is to use `choco new pkgname` from newest version of choco and using output to update your package).
NOTE: Checksums should be calculated during package build time where the result of the checksum is added to the package, not calculated at runtime. Calculating at runtime defeats the purpose of checksumming as a measure of protection.

Do I have alternatives that don't require checksums?
If you have distribution rights (or the software license allows distribution), and the package size stays under 50MB compiled, you can include the binaries in the package itself. Checksum verification is then done as part of moderation review. If you choose to go this route, please ensure you are on the latest version of Chocolatey and run `choco new pkgname` and see what additional things you will need to add to your existing packages, such as LICENSE.txt and VERIFICATION.txt, to ensure that those packages are approved quickly.

What about distributions that always use the same download url?
That is where we suggest using automatic packaging to keep the package up to date.

How do I calculate checksums with automatic packaging?
That's a great question. One of our community maintainers and moderators maintains over 900 packages using automatic packaging and does exactly this. He has provided examples and the code for hooking into the auto updating is at @dtgm's Chocolatey Packages - Ketarin Checksum Settings.

Another tool up and coming for automatic packaging is AU, https://github.com/majkinetor/au. AU uses a PowerShell module to run and doesn't require any templating. When used with packaging, it uses an Update.ps1 file to determine what to replace in the package files. Miodrag, the author of AU, just added automatic checksumming to AU this week so it will pull down x86/x64 urls and provide sha256 checksums automatically to be used for replacement in packages.

We will be adding better instructions on how to do this in the Automatic Packaging documentation.

Actions Moving Forward
Choco tools default to safety - the next version of Chocolatey due out early next week won't allow empty checksums by default. They will have switches and a feature to adjust this behavior. See #112 and #895.
Choco tools will include a consumer override for checksums (consumer provides checksum instead of using package checksum).
The validator will require checksums when downloading from the internet.
choco pack will include validation (subset of the package validator used on the community repository).
VirusTotal checks will become part of automated moderation and findings will flag a package for human review.
Some validator findings may flag a package for human review. This will hold a trusted package for some additional safety checks.

Trusted Packages Will Soon Be Held On Automated Checks
Up until this point the warnings coming out of the community repository have stated that trusted packages are going to be held on failures found by automated checks. This will be turned on soon. Please read the emails when things fail so you understand how to request an exemption from the verifier (the package install tests) and fix other things related to failures in moderation review checks. If you have specific email filters set up, you may want to adjust them so that you can see when you need to take action on failures.

Discount on Chocolatey Pro for Active Package Maintainers
If you are actively maintaining packages on the community repository, the Chocolatey team has agreed to providing Chocolatey Pro for a fantastic discount as a way of saying thank you!! Please reply to this message and tell us you are interested.
	Chocolatey Community Package Maintainers Update - August 2016
	Welcome to the inaugural email update for Chocolatey community package maintainers. We need a way to provide important information to the community maintainers, so we created this list. If you are no longer maintaining packages on Chocolatey.org, simply unsubscribe from future emails at the bottom of this list. Also, you can respond directly to the email if you have questions or concerns.

	Checksums Required For All Future Package Approvals
	tl;dr - Moving forward packages will not be approved without checksums if they download remote resources (exact date to be determined). This includes trusted packages.

	In July 2014 Chocolatey added the ability for package maintainers to provide checksums for downloads. Over the last two years many of you have added checksums to your packages to provide an additional layer of protection for the community, thank you so much for that! We've been planning a move to requiring checksums and were hoping for a gradual and smooth migration on that requirement. However many of you are aware of a recent incident related to FossHub being hacked. Audacity issued a pretty comprehensive report.

	We responded:
	03 AUG 2016 @ 10:24 AM CDT - We learned of FossHub breach
	Started gathering information of extent of possible issues for community repository.
	There were 8 (of 4,000+) packages on the community repository that were using FossHub but not using checksum protection. There are more than 8 packages using FossHub, but those packages have checksum protection (users were protected).
	11:54 AM CDT - Issued a customer advisory. Followed up to provide that notice to the community at large.
	As a security precaution, we took swift action to remove those packages and contact the maintainers.
	1:14 PM CDT - Issued a customer advisory update.
	The community was protected in a matter of less than 3 hours after learning of this breach.
	Based on the reports from FossHub's timeline, they had already taken action to remove/limit the damage and had replaced the malicious software binaries prior to our response. Most of our actions were to notify folks who could have possibly been at risk and to take additional actions to limit potential issues for our community as we waited to find out the complete scope of the damage.

	Even with the actions we took to protect the community, we feel that it is not enough for packages that download remote resources from other sites. Even though folks using licensed versions take advantage of both a private CDN (so they would not have even downloaded the affected binaries) and a runtime VirusTotal verification of binaries that are downloaded, we feel there is more that we need to do to ensure the protection of the entire community.

	Imagine a security breach at a more prominent site with something more malicious. We want to ensure the amount of work to contain a security incident for the Chocolatey community is to notify all of our customers that there was an issue and they are protected.

	Due to the recent events, we no longer feel it is safe to attempt a gradual transition and instead need to provide a quicker transition to protect the community (and yes, a bit rougher for all of us who maintain packages on the feed currently). We understand this may be a bit rougher, so we are providing a little bit of time for you to get your packages updated before moderation sets the requirement flag.

	Even though we are providing you more time before the moderation requirement, we still need to take action to protect the community. This week we will release Chocolatey v0.10.0 that will require checksums when downloading over HTTP/FTP and fail otherwise by default (although users can allow empty checksums in packages with an option or feature). Following soon after, likely in 0.10.1 or 0.10.2, choco will fail all packages without checksums, including HTTPS downloads. See #112 and #895 for more details.

	Here it is in action (the wording is subject to change a bit to advise against allowing empty checksums):

	Choco install of a package that downloads from HTTP without a checksum
	Note: This package is getting converted to HTTPS and will add checksums through auto packaging.

	Why checksum protection?
	Checksums are an integrity check to ensure that the binary downloaded is the same binary that the maintainer intended. Further, it validates that users receive the same binaries that passed moderation, and that were validated against VirusTotal and its 50+ scanners. Every package has a comprehensive check against VirusTotal (and we will are hoping to make VT scans part of the automated review process at some point).

	You can consider checksums as a 3rd party verification for downloaded software. It doesn't necessarily need to be the same checksums that may be provided by the origin site, you can provide a higher level checksum like SHA256. It's a level of protection that is a necessity for HTTP as MITM (man in the middle) attacks are pretty easy to implement (DNS poisoning is also a concern), and it becomes a necessity even for HTTPS as a remote site could get hacked (which could be exploited in a similar way to what we saw recently with FossHub).

	How can I calculate checksums?
	Install checksum - `choco install checksum`
	Download the binaries you want to use with the package.
	Call `checksum -t sha256 -f path\to\file`. Add that to your function arguments. See PowerShell Function Reference to learn how to pass those to the function you are using (another method is to use `choco new pkgname` from newest version of choco and using output to update your package).
	NOTE: Checksums should be calculated during package build time where the result of the checksum is added to the package, not calculated at runtime. Calculating at runtime defeats the purpose of checksumming as a measure of protection.

	Do I have alternatives that don't require checksums?
	If you have distribution rights (or the software license allows distribution), and the package size stays under 50MB compiled, you can include the binaries in the package itself. Checksum verification is then done as part of moderation review. If you choose to go this route, please ensure you are on the latest version of Chocolatey and run `choco new pkgname` and see what additional things you will need to add to your existing packages, such as LICENSE.txt and VERIFICATION.txt, to ensure that those packages are approved quickly.

	What about distributions that always use the same download url?
	That is where we suggest using automatic packaging to keep the package up to date.

	How do I calculate checksums with automatic packaging?
	That's a great question. One of our community maintainers and moderators maintains over 900 packages using automatic packaging and does exactly this. He has provided examples and the code for hooking into the auto updating is at @dtgm's Chocolatey Packages - Ketarin Checksum Settings.

	Another tool up and coming for automatic packaging is AU, https://github.com/majkinetor/au. AU uses a PowerShell module to run and doesn't require any templating. When used with packaging, it uses an Update.ps1 file to determine what to replace in the package files. Miodrag, the author of AU, just added automatic checksumming to AU this week so it will pull down x86/x64 urls and provide sha256 checksums automatically to be used for replacement in packages.

	We will be adding better instructions on how to do this in the Automatic Packaging documentation.

	Actions Moving Forward
	Choco tools default to safety - the next version of Chocolatey due out early next week won't allow empty checksums by default. They will have switches and a feature to adjust this behavior. See #112 and #895.
	Choco tools will include a consumer override for checksums (consumer provides checksum instead of using package checksum).
	The validator will require checksums when downloading from the internet.
	choco pack will include validation (subset of the package validator used on the community repository).
	VirusTotal checks will become part of automated moderation and findings will flag a package for human review.
	Some validator findings may flag a package for human review. This will hold a trusted package for some additional safety checks.

	Trusted Packages Will Soon Be Held On Automated Checks
	Up until this point the warnings coming out of the community repository have stated that trusted packages are going to be held on failures found by automated checks. This will be turned on soon. Please read the emails when things fail so you understand how to request an exemption from the verifier (the package install tests) and fix other things related to failures in moderation review checks. If you have specific email filters set up, you may want to adjust them so that you can see when you need to take action on failures.

	Discount on Chocolatey Pro for Active Package Maintainers
	If you are actively maintaining packages on the community repository, the Chocolatey team has agreed to providing Chocolatey Pro for a fantastic discount as a way of saying thank you!! Please reply to this message and tell us you are interested.