
A Git Horror Story: Repository Integrity With Signed Commits - primroot
http://mikegerwitz.com/papers/git-horror-story
======
Mithaldu

        > What shall we do, then, if we receive a pull request for a 
        > certain feature or bugfix with, say, 300 commits
        > 1. Request that the user squash all the commits into a
        >    single commit
        > 2. Adopt a security policy that requires signing only the
        >    merge commit (forcing a merge commit to be created with
        >    --no-ff if needed).
        > 3. Sign each commit to be introduced by the merge.
    

Or, tell them to rebase their branch on master, while cleaning up all their
"oops", "revert", "typo", "debug" and whatnot commits; resulting in a sane
history and 20 commits to be signed. I find this oversight especially
sarcastic as he mentions how 2. ruins git bisect, while such uncleaned 300
commit branches ruin it just as effectively, as you can never be quite sure
whether the commit you arrive at isn't reverted by one 20 commits later and
the real issue was introduced another 20 commits later.

~~~
sanderjd
Maybe that feature actually took 300 "real" commits to finish. Squashing good
commits _also_ makes bisect hard because while yes it's easier to find the
right commit, that commit now has conflated functionality which makes tracking
down the issue within it harder.

------
buster
To be honest, i feel like git really needs better wrappers or a better GUI or
better defaults. There shouldn't be a quadrillion command flags to know for
simple tasks like this. And i don't mean the -S but the "use -S instead of -s
but for other things use -asm, oh and then you have command xyz which takes
--<long option> followed by other options, but only use those if your SHA hash
can be divided by 3.141 and it's full moon".

~~~
mschuster91
For Windows there exists TortoiseGIT, sorta fork of TortoiseSVN. Not sure if
anything similar exists on Linux or if it could even be done the easy way
("right-click in explorer"), due to the multitude of file explorers/desktop
environments.

~~~
buster
Linux GUIs are rather poor and usually you just use the CLI.

It's only that i miss sane defaults and a common sense of workflow amongst the
community. Currently it's this huge toolbox that can do everything in thousand
ways, but to be honest, i don't want to be able to "get my copy of the
sourcecode to the server" in a gazillion ways, i would very much prefer one
way and one simple command. If you start googling for "how do i do X in git"
you will find 10 ways to do X and 100 philosphical discussions why you should
do X in a specific way and about "what would Jes^H^H^H Linus do?". For
example, i'd love to have "git init" ask your name, email, if you'd like to
sign with GPG, etc. etc. and then save this in git, so that every git commit
will be signed with GPG without giving that stupid option. The common way a la
"Git" would be to introduce bash aliases, i think. But that doesn't work
across machines, OSs or even on the same machine in a different shell.

~~~
pyre
You can add aliases to ~/.gitconfig (the file created by 'git config
--global'). See mine:

    
    
      [alias]
        lg  = log --graph --decorate
        llg = log --oneline --graph --decorate
        ll  = log --oneline
    
        dc = diff --cached
        st = status --short
        ci = commit
        rb = rebase
        br = branch
        co = checkout
    

Then you can just run (e.g.):

    
    
      $ git llg

------
gry
Previously:
[https://news.ycombinator.com/item?id=4007229](https://news.ycombinator.com/item?id=4007229)

------
ushi
Discussion from 2 years ago:

[https://news.ycombinator.com/item?id=4007229](https://news.ycombinator.com/item?id=4007229)

------
lmm
You're supposed to sign a tag because you've reviewed that tag, not just at
random. A commit is much less meaningful - do you always check the diff before
you commit?

~~~
berdario
I almost always check the diff before committing (I use git diff --cached more
often than plain git diff)

~~~
eridius
`git config alias.staged 'diff --cached'` was the first alias I ever created.

Even for one-line changes I compulsively check `git staged` before committing.

------
jaboutboul
Wasn't this posted a couple months ago?

------
codemac
Any discussion of how projects like monotone defeat this?

------
jrockway
Alternative advice that helps avoid this problem:

Do code reviews.

Write tests.

~~~
kevingadd
Code reviews don't do anything to solve issues where an attacker manipulates
the repository after the commits are already there. To solve that, you'd have
to do reviews of _existing commits_ well after they go in, I think?

I don't see how test cases would fix this either. The attacker can break the
test case just as easily as they can insert a backdoor.

~~~
oneandoneis2
You can't rewrite history in git, that's what the shas are there for. An
attacker who gains access to a repo can add new commits, but not tamper with
the existing ones.

~~~
LoganCale
Yes you absolutely can rewrite history.

~~~
oneandoneis2
No, you can't. You can create a _new_ history, you can't edit an existing one.

To clarify: You can, e.g., use interactive rebase to remove a commit from a
branch. But that creates a new HEAD with a different SHA - this is why
rebasing published branches is such a bad thing.

The parent was implying you could change history without anyone noticing. This
implies modifying a previous commit whilst keeping the current HEAD the same,
which can't be done.

