Please give concrete examples of threat Git without GPG about itpol

[josephbleroy]

@henrich Signing commits with GPG has several purposes. I'll give you some scenarios to help you understand the benefits.

Say for example you are in charge of building software, configuring it, and installing it on your company's servers.

Bob, a software developer at your company, signs every commit with his GPG private key. He's shared his public key with you, so that you can check that each commit he's made has indeed been made by him. This generates trust between you and Bob, so that you know when you build the software from his repository that it isn't malicious or anything of that nature.

Alice, another software developer at your company, creates binaries from her code and signs them with her GPG private key. She's shared her public key with you as well. Before installing or downloading the software you make sure that you verify the binary matches her GPG public key, which would mean that she was the person who created the binary file.

In both cases, if the GPG verification does not match, that means that the file you downloaded was either not signed or was signed by someone else.

In a nutshell, signing a file or commit with a GPG private key generates trust between two or more parties, which in turn reduces overall risk to some degree.

Hopefully this answers your questions.

[henrich]

Thanks for your comment, and some questions.

• If I just pull from certain famous GitHub repo, do I still need GPG signed commit/tags? Because I think some famous repos can be trusted enough without GPG sign - is it wrong?
• Some people (including Linus Torvals) think sign to every commit is not good idea, what do you think of it?

[josephbleroy]

@henrich

I'll do my best to answer your questions.

If I just pull from certain famous GitHub repo, do I still need GPG signed commit/tags? Because I think some famous repos can be trusted enough without GPG sign - is it wrong?

It depends on the repository on whether or not they require commits to be signed or not. Usually someone will verify your code and merge it on behalf of you. That somebody will take responsibility for the security and accuracy of your code using their GPG key.

Some people (including Linus Torvals) think sign to every commit is not good idea, what do you think of it?

I don't think there's any wrong or right answer here. Signing code with a GPG key doesn't necessarily make it more secure, it only acts as a type of signature of authenticity. If someone has made 1,000 commits with their GPG key and has never introduced any bad code into the mix, you can typically have more confidence over someone else who has also signed the code and made 10 commits with their GPG key.

It all comes down to personal responsibility and source code verification. You should know how the code works inside and out if installing it on corporate systems. Unfortunately, your questions for me are difficult to give a yes or no answer. They're highly subjective toward the environment you're working in and any requirements that come along with it.

[mricon]

@henrich I am adding a small section on why a developer would consider using PGP with their git repositories. To address your specific question:

If I just pull from certain famous GitHub repo, do I still need GPG signed commit/tags? Because I think some famous repos can be trusted enough without GPG sign - is it wrong?

Mainly, signing tags and commits is useful for forensics and code provenance reasons. Anyone can spoof the "Author" line in a git commit, so if malicious code is found in a repository and git blame says "Jane Doe" did it -- how does Jane prove that it's not her commit? If Jane signs all her commits, but the fake one doesn't have her signature, then it's easy proof that she's not at fault.

See: https://github.com/jayphelps/git-blame-someone-else

For tags, signing them is useful when working with distributed mirrors. For example, the Linux Kernel repository is mirrored to hundreds of servers worldwide in order to make it easier for developers from places like China or Australia to participate in kernel development. Signed tags make it easy for them to verify that none of the mirroring servers have tried to modify the repository in order to sneak in malicious code.

Lastly, there is no such thing as "trusted repository locations." Ever since the 2011 hacking of kernel.org, the rule of thumb has has been: "trust the developers, not the infrastructure." Software code is being reviewed all the time, while infrastructure is a black box where only a handful of administrators (and, maybe, a handful of hackers?) have access. I am sure that github is an equally tasty target for malicious actors, and using PGP with git helps ensure that sneaking bad code into public repositories remains a difficult attack.