It is frustrating that you are being so opaque and dismissive. You still haven't answered my earlier question if the Homebrew project has published a summary of the results of these security reviews (I understand not posting the entire review publicly). A quick Google search did not turn up anything, which is why I am asking.
For contrast: I can find out the build process for a Debian package from their website[1]. While they do have some private operation documentation, they also publish the process by which packages get pulled into their system, built, and pushed to the mirrors[2][3]. They have documentation for how to replicate their build environment and build packages on my own[4]. This documentation is open, and I can verify packages with it as they move toward reproducible builds[5]. I understand that Debian is a much larger operation with a much longer history. I understand that it takes time to develop these things. This is not an attack on the Homebrew project or the work they do.
[1] https://www.debian.org/devel/buildd/
[2] https://www.debian.org/devel/buildd/operation
[3] https://wiki.debian.org/Teams/FTPMaster
I have looked at the Homebrew docs page. There is a document linked that describes how bottles are built[1], but it's not clear who has access to it and what safeguards are in place to prevent a malicious maintainer from spreading malware through it (such as who reviews the commits) and it doesn't list the precautions taken by bintray to prevent and detect tampering with packages (and a user has to trust that they as in place, sufficient, and trust bintray to not tamper with them). Another page says that most formula pull requests need to be reviewer but does not go over what this entails[2].
This alarming text, however, does appear in your maintainer guidelines [3]:
>Verify the formula works if possible. If you can’t tell (e.g. if it’s a library) trust the original contributor, it worked for them, so chances are it is fine. If you aren’t an expert in the tool in question, you can’t really gauge if the formula installed the program correctly. _At some point an expert will come along, cry blue murder that it doesn’t work, and fix it. This is how open source works._ Ideally, request a test do block to test that functionality is consistently available.
Is there a set of maintainers who handle security sensitive formula, like openssl, gnupg, and tor?
[1] https://docs.brew.sh/Brew-Test-Bot
[2] https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request
I had an experience years ago where I discovered the lack of quality control: a typo (presumably) caused a package to regress back a couple of years. My issue used wording like "Are you serious?" which was taken as offensive and I was banned, unable to even apologize or defend myself from resulting attacks.
brew is convenient and I still use it, but I have a much higher degree of trust in packages shipping with OS distributions.
You can put your money where your mouth is and consider submitting one to our HackerOne. Otherwise: perhaps it's not "quite easy" after all.
Here you go:
> Do you have published security reviews of your infrastructure?
Beyond https://hackerone.com/homebrew/hacktivity, https://brew.sh/2018/08/05/security-incident-disclosure/: no.
> Otherwise you're asking us to just trust you.
Yes.
> it's not clear who has access to it
A subset of the documented Homebrew maintainers who manage our ops/infrastructure.
> such as who reviews the commits
The maintainers and additional trusted users.
> the precautions taken by bintray to prevent and detect tampering with packages
packages require a manual publishing step, are checksummed and frozen on their CDN a while after publishing.
> most formula pull requests need to be reviewer but does not go over what this entails
This is part of the on boarding and training of new maintainers.
> Is there a set of maintainers who handle security sensitive formula, like openssl, gnupg, and tor?
Not a specific set but they receive extra time, review and attention to their source URLs.
---
I expect some of that will not be good enough for you in which case: please either get involved to help us make it better (we are unpaid volunteers) or use another tool. This is how open source works.