rtyley / bfg-repo-cleaner

Removes large or troublesome blobs like git-filter-branch does, but faster. And written in Scala
https://rtyley.github.io/bfg-repo-cleaner/
GNU General Public License v3.0
10.95k stars 540 forks source link

is the homebrew version safe? #312

Closed mesqueeb closed 5 years ago

mesqueeb commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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:

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:

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:

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.