> ort (short for “ostensibly recursive‘s twin”) Continuing Git's famously clear naming I see!
Can't mention git command naming without linking to the parody Git Man Page Generator[0].
Highlights from Git 2.34
31–40 of 100 posts
Re: Highlights from Git 2.34
#32Earlier quoted context omitted.
> 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 com…
[deleted]
Re: Highlights from Git 2.34
#33It'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…
All of this signing is only useful if someone is actually checking or enforcing those signatures, otherwise it's just LARPing. Being able to sign commits with your SSH keys makes signing actually useful, because it enables a new workflow that developers will use: - You give every dev on your team a Yubikey - They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the…
> They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the box with both openssh and GitHub
How does this work? Can you like me a ressource?
Re: Highlights from Git 2.34
#34Earlier quoted context omitted.
All of this signing is only useful if someone is actually checking or enforcing those signatures, otherwise it's just LARPing. Being able to sign commits with your SSH keys makes signing actually useful, because it enables a new workflow that developers will use: - You give every dev on your team a Yubikey - They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the…
> They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the box with both openssh and GitHub How does this work? Can you like me a ressource?
You run `ssh-keygen -t ed25519-sk -O resident`, and that's it, no additional software required as of OpenSSH 8.2. If you have an older model Yubikey you can try ecdsa-sk instead.
For more details, see:
https://github.blog/2021-05-10-security-keys-supported-ssh-g...
https://www.yubico.com/blog/github-now-supports-ssh-security...
Re: Highlights from Git 2.34
#35Earlier quoted context omitted.
Has git published their own release announcement like this for people to read?
It's in the repo: https://raw.githubusercontent.com/git/git/master/Documentati... [edit: in fact it's linked from GitHub's blog post, at the bottom, and it's included in the announcement email: https://lore.kernel.org/git/xmqq8rxpgwki.fsf@gitster.g/ ]
The official release announcement from the git project is also in the very first sentence of the very first paragraph of the github post.
Re: Highlights from Git 2.34
#36Earlier quoted context omitted.
> 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 com…
Given Juniper released basically nothing about their investigation, I'm not convinced this is a valid example.
Notably, I'm not just asking if there ever was a bad commit that was investigated - but that the commit came from someone who later claimed she/he didn't do it.
Re: Highlights from Git 2.34
#37It'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…
All of this signing is only useful if someone is actually checking or enforcing those signatures, otherwise it's just LARPing. Being able to sign commits with your SSH keys makes signing actually useful, because it enables a new workflow that developers will use: - You give every dev on your team a Yubikey - They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the…
- No private keys on developers machines, rendering all types of supply chain attacks like NPM stealing your .ssh files ineffective
Would it be able to get the key from the usb device? Or does the hashing happen on the device itself with the private key never exposed? If that's how it works, that would be awesome, but would a malicious program be able to sign something as you, instead of stealing the keys?
I'm going to look into this more and maybe recommend it at work.
Re: Highlights from Git 2.34
#38Earlier quoted context omitted.
And repeatedly trying to trick or force us to use Edge and probably a few others.
Are these decisions we don't agree with? Sure. Evil? No. At least not 1999 Microsoft evil. I can find just as many bad decisions from every other major tech company. For the record, I actually did give Edge Chromium a spin and I was a bit impressed. The Deals feature creeps me out, but I can browse the reddit homepage without an ad blocker and it's actually a smooth experience.
Not being cartoonishly evil should be a low bar to pass?
Edge is probably nice, forcing users to use it is not.
One should think they'd learned after being forced to advertise other browsers for a couple of years?
Re: Highlights from Git 2.34
#39Earlier quoted context omitted.
All of this signing is only useful if someone is actually checking or enforcing those signatures, otherwise it's just LARPing. Being able to sign commits with your SSH keys makes signing actually useful, because it enables a new workflow that developers will use: - You give every dev on your team a Yubikey - They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the…
- No private keys on developers machines, rendering all types of supply chain attacks like NPM stealing your .ssh files ineffective Would it be able to get the key from the usb device? Or does the hashing happen on the device itself with the private key never exposed? If that's how it works, that would be awesome, but would a malicious program be able to sign something as you, instead of stealing the keys? I'm going…
>Would it be able to get the key from the usb device? Or does the hashing happen on the device itself with the private key never exposed?
If you could extract the key, you probably have access to the intelligence resources of a very large nation. With hardware security dongles, the key remains on the dongle; you pass your data in and it passes the signature (or encrypted data) back out.
Re: Highlights from Git 2.34
#40> ort (short for “ostensibly recursive‘s twin”) Continuing Git's famously clear naming I see!
Can't mention git command naming without linking to the parody Git Man Page Generator[0]. [0]: https://git-man-page-generator.lokaltog.net/
> git-chase-submodule chases remote submodules using downstream shells, while remoting fitting patches to impale the given submodules.
> When COMMIT_ID_DEFINE_LOCAL_CACHE is not patched, the most recent counted grafts chased by submodules in a subtree, but that are not in other-bundle, may be chased by an active head ref. Using sub-recursed or pre-massaged flags only cautiously grips the tag, except when otherwise noted.