71–80 of 121 posts
16 used, here are more
https://keybase.io/inv/b24a826ad7
https://keybase.io/inv/6875c4bf5aAnybody here got invitation codes for keybase ?
You don't need keybase to sign your commits. Any standard and key-exchange compatible pgp/gpg client will do. By using keybase you're just adding more work for everyone. https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
Here are some invites if you are interested. (added more, replaced some used ones) 16 used, here are more https://keybase.io/inv/b24a826ad7 https://keybase.io/inv/6875c4bf5a
I'm not sure keybase does this by default, but make sure to upload your key to a keyserver such as MIT's ( https://pgp.mit.edu ). Otherwise, git will complain that the signature is invalid when doing `git log --show-signature`.
Github doesn't complain for me, so I can only assume that it does this itself. What I did was grab my key from keybase and inserted that into my local keyring, then uploaded that to my github.
If anyone wants in, here are 5 invite links. [Edit: all used up.] Each works for only one signup, so hurry up :-) By the way, most users get around 20 free invites shortly after signing up. If one of the links above opened your account, why not share five of your own invites afterwards?
https://keybase.io/inv/d1439a90ad
https://keybase.io/inv/19ff7aba7d
https://keybase.io/inv/214f008a4f
https://keybase.io/inv/19949fe9a1
https://keybase.io/inv/8c0d7ab033
https://keybase.io/inv/6e0e648a78
https://keybase.io/inv/02bfae461c
https://keybase.io/inv/b643f5505
Note that you don't need keybase.io to sign your commits: https://help.github.com/articles/signing-commits-using-gpg/
Linus Torvalds, the creator of Git, says that signing every commit is stupid. http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
Consider: You've just written 20 lines of code, and you're creating a commit. Can you validate that all 20 lines were created by you before you commit?
Now, consider that you're looking to create a tag for version 2.0, coming from 1.4, with a net 4,000 new lines of code. Can you quickly and confidently validate that all 4,000 lines of code are as expected?
Clearly, the frequent, small validations are much simpler than infrequently signing huge releases. When integrity matters and humans are involved, small batches win.
Linus Torvalds, the creator of Git, says that signing every commit is stupid. http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
This raises the question, though; how do you know when you reach that golden commit? Is the signer responsible for auditing every commit since the last signature, every line of code? If he doesn't, what does the signature prove?
That's what Linus has wrong; The signatures aren't about proof, they're about audit trail. For Linus and the kernel.org use case, this isn't necessary. They've already built tooling, and most importantly structure around the code auditing. Every commit that goes into the mainline is somewhat audited by Linus himself. There's a whole layer of competent release engineers in front of him. Code doesn't make it onto the kernel.org repos without having been trusted by a very select group, and doesn't get pulled to master without the word of God.
I suggest, for the average developer, having two keys. One online, to verify that the commit was developed on your computer. One offline, that is only used for releases. One for audit trail, one for golden.
If anyone wants in, here are 5 invite links. [Edit: all used up.] Each works for only one signup, so hurry up :-) By the way, most users get around 20 free invites shortly after signing up. If one of the links above opened your account, why not share five of your own invites afterwards?