Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Highlights from Git 2.34

github.blog

Post reply on HN
Print view View original

11–20 of 100 posts

Re: Highlights from Git 2.34

#11

Post by bennyp101 »

teddyh wrote: post #6
judge2020 wrote: post #4

Earlier quoted context omitted.

IMO GitHub posting these is fine since they're headlined "Highlights from Git 2.3x", but the last discussion incorrectly just said "Git 2.33", which is likely where the confusion came from. Hopefully this post will keep the distinction front-and-center.

If your name is GitHub and you announce a new release of Git, which your product GitHub uses extentively, and you do not explicitly and clearly mention that you do not have any role in making Git itself, then you are lying by omission; deliberately misinforming people who will naturally assume, given no information to the contrary, that GitHub are the makers of Git. I think that most people are already under the misa…

Do you really think that most people that use git and GitHub are under the misapprehension that Git and GitHub are the same thing?

Really? This seems just very much an anti Microsoft view, especially with that final sentence.

Re: Highlights from Git 2.34

#12

Post by eropple »

er4hn wrote: post #5

It's really neat that ssh keys can be used for signing commits, but I'm not a big fan of this. When auditing a source repository you want to see how commits are signed over time. In other words you have a key X which is valid at time Y. As Y changes, key X will change as well. To audit a repo, you need to know the history of what key X was valid at time Y. With GPG you can set up a hierarchy of commit signing keys wh…

This is a totally valid criticism IMO, and I think platforms should allow for disallowing signatures based on origin, but there's something that, for the majority of users, really holds true:

> With GPG you can set up a hierarchy of commit signing keys which have defined lifetimes and are all subordinate to a master key which you do not use for signing (and hopefully keep somewhere secure).

Within epsilon of nobody is going to do this, but they all have an SSH key. Heck, I don't do this, and I even actually know how to make GPG do it. It's a huge hassle for what, at this point, is really only useful to me for...signing Git commits? I don't need to sign anything else with it, and GPG mail is nonexistent.

(Also, fwiw, if you aren't using a managed service provider, I hope you have a directory service where you can have those keys. If you aren't using a managed service provider and you don't have a directory service, I'm gonna go out on a limb and say that I'm guessing security isn't that important to you.)

Re: Highlights from Git 2.34

#13

Post by smegsicle »

tomnipotent wrote: post #8
teddyh wrote: post #3

They did it again. GitHub “stealing” the Git release announcement, contributing to the Git/GitHub confusion. Comments from the last time: https://news.ycombinator.com/item?id=28207168 For those who don’t know: GitHub is owned by Microsoft, a historical (and current) adversary of all things not Microsoft, particularly Linux¹. Git, the tool, is not made by GitHub; GitHub is a web service which is using Git. Git, the to…

Oh look, the obligatory "Micro$oft is evil" rhetoric based on decades old grievances and very little new evidence. So useful. It's perfectly reasonable for a company, that uses the tool in its name, to have a blog post going over new features. I'm never amazed the distances people will go to distort a boring blog post into some issue or another based on splitting hairs.

> very little new evidence

Off topic, but there was that dotnetfederation overreach shenanigans

Re: Highlights from Git 2.34

#14

Post by morelisp »

bennyp101 wrote: post #11
teddyh wrote: post #6

Earlier quoted context omitted.

If your name is GitHub and you announce a new release of Git, which your product GitHub uses extentively, and you do not explicitly and clearly mention that you do not have any role in making Git itself, then you are lying by omission; deliberately misinforming people who will naturally assume, given no information to the contrary, that GitHub are the makers of Git. I think that most people are already under the misa…

Do you really think that most people that use git and GitHub are under the misapprehension that Git and GitHub are the same thing? Really? This seems just very much an anti Microsoft view, especially with that final sentence.

> Do you really think that most people that use git and GitHub are under the misapprehension that Git and GitHub are the same thing?

Yeah actually, a lot are. There are also a lot of GitHub users who don't know what git is at all.

I don't think this blog post is going to further misinform them though, they also don't read technical blog posts.

Re: Highlights from Git 2.34

#15

Post by agwa »

er4hn wrote: post #5

It's really neat that ssh keys can be used for signing commits, but I'm not a big fan of this. When auditing a source repository you want to see how commits are signed over time. In other words you have a key X which is valid at time Y. As Y changes, key X will change as well. To audit a repo, you need to know the history of what key X was valid at time Y. With GPG you can set up a hierarchy of commit signing keys wh…

It's possible to set "valid-before" and "valid-after" timestamps on SSH keys in the allowed signers file:

https://man.openbsd.org/ssh-keygen#ALLOWED_SIGNERS

When validating the SSH signature, Git can set the verify-time option to the commit timestamp and the signature will be rejected if the key is not valid at that time. Git doesn't yet do this, but will in a future version.

This is considerably simpler than the rigamarole of GPG subkeys.

Re: Highlights from Git 2.34

#16

Post by Aicy »

teddyh wrote: post #3

They did it again. GitHub “stealing” the Git release announcement, contributing to the Git/GitHub confusion. Comments from the last time: https://news.ycombinator.com/item?id=28207168 For those who don’t know: GitHub is owned by Microsoft, a historical (and current) adversary of all things not Microsoft, particularly Linux¹. Git, the tool, is not made by GitHub; GitHub is a web service which is using Git. Git, the to…

Has git published their own release announcement like this for people to read?

Re: Highlights from Git 2.34

#17

Post by vlovich123 »

hannob wrote: post #10
teddyh wrote: post #3

They did it again. GitHub “stealing” the Git release announcement, contributing to the Git/GitHub confusion. Comments from the last time: https://news.ycombinator.com/item?id=28207168 For those who don’t know: GitHub is owned by Microsoft, a historical (and current) adversary of all things not Microsoft, particularly Linux¹. Git, the tool, is not made by GitHub; GitHub is a web service which is using Git. Git, the to…

I don't like Microsoft, but you can't blame microsoft for the fact that apparently the git project never made a proper webpage. Obviously that means people will try to find information about git elsewhere.

Isn’t [1] the official git home page? I don’t follow your comment.

[1] https://git-scm.com/

Re: Highlights from Git 2.34

#19

Post by [deleted] »

hannob wrote: post #10
teddyh wrote: post #3

They did it again. GitHub “stealing” the Git release announcement, contributing to the Git/GitHub confusion. Comments from the last time: https://news.ycombinator.com/item?id=28207168 For those who don’t know: GitHub is owned by Microsoft, a historical (and current) adversary of all things not Microsoft, particularly Linux¹. Git, the tool, is not made by GitHub; GitHub is a web service which is using Git. Git, the to…

I don't like Microsoft, but you can't blame microsoft for the fact that apparently the git project never made a proper webpage. Obviously that means people will try to find information about git elsewhere.

[deleted]

Re: Highlights from Git 2.34

#20

Post by er4hn »

hannob wrote: post #9
er4hn wrote: post #5

It's really neat that ssh keys can be used for signing commits, but I'm not a big fan of this. When auditing a source repository you want to see how commits are signed over time. In other words you have a key X which is valid at time Y. As Y changes, key X will change as well. To audit a repo, you need to know the history of what key X was valid at time Y. With GPG you can set up a hierarchy of commit signing keys wh…

> When auditing a source repository you want to see how commits are signed over time. I understand your reasoning and the idea behind GPG and everything, but here's my challenge to all of this: Has this ever happened? Like, the scenario we're talking about is that at some point some bad code, maybe a backdoor, got introduced into a code repo, and it later is discovered and someone launches an investigation. And they…

> Has this ever happened?

Unfortunately this has: https://www.wired.com/2015/12/researchers-solve-the-juniper-...

While the full results were not released, it was pretty clear that a rogue commit happened to the VCS. This is the highest profile example that has occurred in my corner of the tech world.

The broader category of this attack is "insider threat" and it is a real thing. Even googling for "malicious code commit" turns up this other example for me as one of the first results: https://www.theregister.com/2021/03/29/php_repository_infect...

Post reply on HN