[TxMt] Vetting and security policies (was: Bundle Management improvements?)

[Claudia Pellegrino]

Hi Josh,


(I apologize for my replies to be attached to the wrong places in the thread. I have just figured out how to turn off the digest format. Please bear with me until the changes take effect.)


> Thanks for pointing this out! I agree that in 2017 we should
> be taking security seriously. I'd love to learn though, what
> are some good ways to set up vetting and security policies?

Off the top of my head:

1. Create an organization on GitHub, and move the repo there. Or maybe get another GitHub organization (TextMate?) to adopt it. This ensures that in the long run, more than one single person has the power to grant or revoke _Owner_ and _Maintainer_ privileges.

2. You have already mentioned a very effective measure: make it a policy to not allow `sha256 :no_check` without good reason. For TextMate bundles, this means in practice: always pin your Cask to a release; in cases where upstream does not issue releases or tags, pin the Cask to the latest commit instead; do not point to nightlies, or to upstream `head`; in case users really want it, create a separate tap for nightlies within the same GitHub organization.

3. On GitHub, enable forced reviews for any commit on the master branch; also, tick the box that says this actually covers anyone’s commits, including the owner’s. Configure the GitHub repo so any single maintainer has veto rights against merging. Make regular audits to ensure these setting are still in place.

4. Have two maintainers at the very least, and grant them the _Maintainer_ privilege to make #3 technically possible.

5. In the `url` stanza, do not allow domains where the maintainer can’t reliably determine who has control over the domain. For example, if the author of `Foomatic.tmbundle` offers their releases only via a Dropbox link, maintainers will not be able to keep track of authenticity as updates get released.

6. Do not be afraid to refuse a Cask if it fails to meet those standards for whatever reason.

7. On the GitHub organization level, grant the _Owner_ privilege to at least one more maintainer. Not only does this help keep the organization alive in case the original owner fails to be responsive, or fails to fulfill their duties, it also allows for quick reaction in case another owner’s account be ever compromised.

8. Speaking of compromised: enforce that anyone with _Maintainer_ or _Owner_ status have two-factor authentication enabled for their GitHub accounts. Make regular audits to ensure everyone continues to comply.

9. Check the contributions of anyone before you grant them _Maintainer_ status on the GitHub organization. Ensure that a person is trustworthy before you grant them _Owner_ status on the GitHub organization.

10. When creating or reviewing a Cask, make sure it contains a line that says e. g.,

# downloads.example.com was verified to be a canonical download
# site at the time it was first introduced to this Cask

On each update, double-check whether the `url` stanza still points to the same domain name as the one in the comment.

11. On each update, download the payload from the given source, and verify the updated SHA256 matches the downloaded file. (It’s OK to automate this.) When generating the hash, never use plain HTTP to download the file if it’s also available via HTTPS from the same source.

12. Use common sense before you grant anyone commit access or other privileges.



Regards!
Claudia