Bfg-repo-cleaner: is the homebrew version safe?

[mesqueeb]

So nowhere in the readme or the website it talks about if we can install it with homebrew like so:

brew install bfg

this makes me wonder, is the current version of bfg on homebrew SAFE? How can we know if this repo on there is not some malware that actually sends files you try to delete to some malicious coder?

[javabrett]

Here's the bfg formula - then folks can decide for themselves whether it is safe or not. Looks equivalent to trusting https://search.maven.org/remotecontent?filepath=com/madgag/bfg/1.13.0/bfg-1.13.0.jar, which I understand is under control of the project owner/author.

[mesqueeb]

@javabrett you are very smart!

@rtyley Shall I make a PR on the Readme to add this install method for macOS?

brew install bfg

[rtyley]

Thanks @javabrett for helping out once again - it's much appreciated.

I can't police all packaging systems...

There are _lots_ of packaging systems out there, and many of them have packages for the BFG:

• Homebrew
• Chocolatey
• pip
• npm
• Gentoo
• ...the list goes on...!

As an Ubuntu Linux user, I don't use any of these, and didn't set any of them up (though occasionally I've updated the Homebrew recipe). It's not really possible for me to police all the different package-management systems over time and check that they _always_ return the right package - and so I can't really vouch for any of them (as an aside, I happen to think that the way some of these package managers typically get installed - by curling a script and then running it as sudo - is itself not a good security practice).

How much value do packaging systems add for the BFG install process?

I do recognise that they are more convenient for the growing audience of users who aren't familiar with Java. These packaging systems are effectively replacing this process:

1. Install Java
2. Download the BFG from it's recommended download location (ie https://search.maven.org/classic/remote_content?g=com.madgag&a=bfg&v=LATEST, or the static link like https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar
3. Verifying the jar (package-managers do this to varying extents) - see below
4. Run java -jar bfg-1.13.0.jar

It's certainly true that brew install bfg is easier than the above - but the above installation list is not massive.

Given that rewriting Git repository history is itself not a trivial operation for a user to undertake (ideally, a user needs to have a fairly good understanding of Git to undertake it, even if they do use the BFG), I'm not sure how much easier the installation process _should_ be...!

Verifying the BFG jar - a.k.a understandable paranoia to which there is no good answer

I have sole control of the com.madgag namespace in Maven Central, so downloading something from there over HTTPS should notionally be good enough. But it _is_ a good idea to verify artifacts when you download them, and the 'best' way to do this with Maven Central artifacts is probably to check the PGP signature (it _might_ be nice to also pin to a specific SHA-256, but I don't publish those at this time).

In the case of the BFG, you can do that by downloading these 3 files:

• https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar - _the BFG itself_
• https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar.asc - _the signature file_
• https://rtyley.github.io/bfg-repo-cleaner/rtyley.gpg <- _my public key (aka 7305AE1B6772AA1C2D3B4E5DB21602FA2D5CC13C), currently valid up to 2021-03-19 - there's a download link on the BFG's documentation page:_

Then executing these steps with GPG:

$ gpg --import rtyley.gpg
$ gpg --verify bfg-1.13.0.jar.asc bfg-1.13.0.jar

...once that verifies, you're basically fine, so long as you trust:

• Me, the author of this software
• The security of the hardware, operating system and software tools I use to create the BFG
• My infosec practices to keep my private PGP key secure & private
• GitHub to distribute my key without modification
• HTTPS and certificate authorities to deliver my key intact
• Your own hardware and operating system to be secure
• GPG's cryptographic security

You have to take a hell of a lot of things on trust, to be honest. If you wanted to try to further narrow your circle of trust, you could probably run the BFG in a container or virtual machine, assuming you trust virtualisation technology - so long as you're able to independently verify the modified Git repository produced by the BFG, you're probably ok.