brasic

Someone needs to option this for a book or movie. I’d read it!

It’s hard to overstate the reputation of the author of this post. Everything good about GitHub’s internal systems seemed to have his name all over it (I realize that today this statement hits different than a few years ago). Our times at GH didn’t overlap much but hearing the fact that he’s working at cursor increases my estimation of their engineering org by leaps and bounds.

The web-flow signing system is for users’ convenience in places where it’s not feasible to sign the commit with their own private key: commits made in the web interface or on an ephemeral GH-provisioned VM (codespace). For the latter, you are free to send your own private key to your codespace so you can sign your own commits but GitHub cannot because they don’t have your private key and don’t want to have it. Defaults matter and signed commits are important.

As a sibling notes, this use case and similar ones is the reason the committer field exists as distinct from the author field. I think a $10K bounty for this bug speaks to how seriously they stand behind the fact that they will only sign and mark as verified commits whose author field matches an authenticated user.

(Disclaimer: former GH employee)

The research you do in that scenario would just tell you the prices which shares had actually changed hands at. A decentralized market-based price discovery mechanism cannot be considered collusion or price fixing, since it’s exactly the opposite.

  > but you still need a Personal Access Token to integrate pull requests and issues with your Git client

(Nitpick from a former GH employee) PATs really are almost exclusively intended for personal testing with curl and such. The strongly preferred way for apps like you describe to work is a pseudo-OAuth flow (“GitHub Apps”) which yields a token that is not a Personal Access Token. Better in just about every way: more ergonomic, more secure (revocable, shorter duration, predictable fine grain scope with a mechanism for requesting additional permissions as apps change, etc), and requests are attributable to the application which generated them instead of just the user. If you use an app that actually requires generating and pasting a PAT, it’s either extremely old or made by someone who is not prioritizing security and user experience. It even works well in CLI apps, cf. the `gh` command line utility.

Thanks for the links! I guess I shouldn’t be surprised that “E2E” doesn’t mean much for a meta service.

Yep, to be clear I was agreeing with lolinder. I would have posted top level but they had already expressed almost exactly my objection to the article so I replied to avoid redundancy.

It sounds almost exactly like the mechanics of a session cookie as implemented on nearly every website on earth. Exchange a password for a bearer credential that is randomly chosen and revocable. There are only so many basic ideas in security.

“Please read my rant about how this useless hair-shirt I wear to clear first party cookies too often breaks the web (for me)”

  > the web has no notion of a “device”, and this is a very intentional design choice made for privacy purposes [...] why do web developers persist in believing in this fiction of a “device”?

Cookies are a core part of the web which enable the construction of stateful applications on top of a stateless protocol. “Remembered device” is usually just an extra cookie set on login, or a row in a backend database. It’s no more fictional than the web itself, which is after all just a series of electrical impulses over wires.

Whether a device (however you build that abstraction) has previously logged in is a high-signal data point that meaningfully increases account security at login time and all serious web security teams use it to protect their users.

Mr. President, we must not allow a mutant AI super soldier gap!

It doesn’t show as flagged for me. Time heals all wounds, if your comment is not objectionable it will usually be vouched for eventually. Which is one of the reasons it’s a rule here that you don’t complain about voting. Such comments also rarely age like wine :)

Process separation was already in place. The PKCS#11 library is loaded by a long lived helper process, not ssh-agent itself.

  > (Note to the curious readers: for security reasons, and as explained in
  > the "Background" section below, ssh-agent does not actually load such a
  > shared library in its own address space (where private keys are stored),
  > but in a separate, dedicated process, ssh-pkcs11-helper.)

That didn’t help because the long lived nature of the helper process exposed it to the shared lib side effects such that they could be chained into a gadget. If I understand correctly, the long life is important for interacting with many smart cards and HSMs because of their APIs.

If you are suggesting that there should be an IPC API for this process and vendors ship a full program that speaks it, that seems reasonable at a glance, but not really something the OpenSSH project can dictate.