This largely automates the process of importing developer keys,
much like `import-dev-keys.sh`, but also takes the additional, sadly
manual step of signing the key with your default key, and uploading
those keys to https://sks-keyservers.net.
In effect, you are stating that you trust keys published on keybase.io
and are listed as such on the official Metasploit-Framework development
wiki.
If your own default key either has no passphrase, or has a passphrase
cached in a keymanager, the process merely requires you hit `y` for
every key, and `y` again for keys with multiple IDs. Otherwise, you
will need to provide your passphrase for each signing. Temporarily
removing the passphrase alleviates this pain.
Of course, this assumes you actually trust the development wiki
and keybase to do the right thing. The tradition is to individually
verify each key through some personally invented means, such as in
person with a government ID check.
Note that `import-dev-keys.sh` currently lists a number of keys
not on Keybase, and that functionality has not been carried over
to this script.
This script allows you to find the release notes of a:
* Pull request number for a bug fix, or a notable change.
* A module name (preferably just use the short name)
This merely makes it easy and fun to import all developer keys used over
the past year to your local GPG keychain. This will make the task of
reviewing merge commits for signedness much easier, especially if you
use a nicelog alias such as this one:
https://github.com/todb-r7/junkdrawer/blob/master/dotfiles/git-repos/gitconfig#L40
This does not handle automating checking for signatures as part of
Travis-CI -- for that, see PR #5337, a work in progress.
It's possible someone still wants the Webscarab stand-alone importer,
but I cannot imagine that after years of bitrot that is even viable in
its current state.
The rest of them are all older development tools that are no longer
needed (normal vim/rubymine auto-formatting will do the trick).
See the complaint on #4039. This doesn't fix that particular
issue (it's somewhat unrelated), but does solve around
a file parsing problem reported by @void-in