brasic

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

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”?

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 :)

What do you mean? WhatsApp rolled out E2E encryption between 2014 and 2016.

It’s by far the largest messaging service that is e2e encrypted by default. I think it’s more than fair to call it ahead of the curve for a service of its size.

https://www.wired.com/2014/11/whatsapp-encrypted-messaging/ https://blog.whatsapp.com/end-to-end-encryption

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.)

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.

How would this even be mitigated while preserving the (wacky) existing support for runtime-selected PKCS#11 provider libraries? It strikes me that the most compatible way might be to double down on the wackiness and try to perform the required feature detection in some more indirect way like parsing the named lib with readelf(1) or the platform equivalent.

The sensible thing would be to force users to register available provider shared libraries in an ssh-agent config file, but that feels like a pretty big breaking change.

Edit: Didn’t realize a patch was already available. I see that they did in fact fix this with a breaking change, by simply disabling the functionality by default, and recommending that users allowlist their specific libraries:

  Potentially-incompatible changes
  --------------------------------
  
   * ssh-agent(8): the agent will now refuse requests to load PKCS#11
     modules issued by remote clients by default. A flag has been added
     to restore the previous behaviour "-Oallow-remote-pkcs11"

Pre-acquisition WhatsApp was built using Erlang and had an impressively large user-to-server ratio IIRC. I expect that since then things have mostly been rebuilt to use existing meta shared infrastructure which might not be as stable or efficient.

Glad to see a custom merge driver being used here - they’re one of the most powerful of git’s obscure features. Large teams working on a monorepo inevitably start noticing that particular files are magnets for conflicts (or other times, in cases like this, some files are a huge pain to resolve whenever they conflict).

This happens especially frequently if your team uses a lot of CIGARs (checked in generated artifacts)

In most cases writing a simple driver to automatically handle the conflict resolution is pretty straightforward (especially if the resolution is usually just to regenerate a generated file) and well worth the up front effort to eliminate ongoing conflict headaches.

https://git-scm.com/docs/gitattributes#_defining_a_custom_me...

The main hassle is that for security reasons all developers need to opt in by registering the merge driver , which you can put in a project bootstrap script if you have one. Would be great if GitHub (disclaimer: where I used to work) would integrate custom merge drivers in their internal conflict resolution flow.

From OP:

  > Now with all those aptitude training [...] that require you to turn on your webcam

The conflation of “spyware” ie tracking for monetization purposes with telemetry used by developers to ensure the health of production systems is foolish and harmful.

Homebrew is a complex system that can break in lots of ways, and it’s being developed on an entirely open source basis, with no company behind it.

Having some visibility into the operation of a running system is table stakes. You’re asking the developers donating their time to this very useful project to tie a hand behind their back because you are paranoid.

More often than not, if people like you got their way OSS software just wouldn’t be built, or would be taken over by a for profit entity that has much less benign ideas about spyware.

This is literally a story about the homebrew project listening to the community and migrating to privacy-preserving self-hosted analytics. People like you will never be happy, so they should be entirely ignored.

I assume OP was referring to “source available” schemes where the source is published or sometimes selectively disclosed but not licensed for anything other than review, ie you lack the right to run or copy it.

Needless to say, it’s not accurate to call that “open source”.

I’ve done nothing of the sort.

As I said throughout this thread, the injunction prohibits any communications based on a vague and subjective content or motive between a group of approx. 500,000 citizens who are US government employees and several million individuals worldwide who are employed by any of the named social media companies, nonprofits, or similar organizations.

This is not ok. If restrictions on speech are ever justified they have to be narrowly tailored in terms of content and substance, neither of which is true here.

The actual letter is here: https://twitter.com/Dexerto/status/1677027980940398599

edit: It looks like this was already submitted and I missed it: https://news.ycombinator.com/item?id=36621741. Looks like it’s too late to delete this submission. Apologies.

Adding a list of carve outs doesn’t make the ban ok.

Thank you. The real issue here is a small number of companies have become the defacto gatekeepers of a large amount of public discourse. That’s a major problem that this debate is just a symptom of.

A narrowly tailored prohibition on specific speech aimed at specific government officials may be permissable in some cases. This injunction is carelessly worded to apply to millions of people and to preclude essentially all communications related to "protected free speech". The breadth and vagueness is specifically what I'm objecting to.

The targets of the injunction are the following agencies. The wording makes clear that all members of said agencies are in scope of the injunction:

HHS: 80,000

NIAID: 18,000

CDC: 11,000

Census Bureau: 5,000

FBI: 40,000 (double counted under DOJ)

DOJ: 115,000

CISA: 3000

DHS: 260,000

State Department: 14,000

Among the actions prohibited are communicating with "social media companies", defined in the injunction as including:

"Facebook/Meta, Twitter, YouTube/Google, WhatsApp, Instagram, WeChat,TikTok, Sina Weibo, QQ, Telegram, Snapchat, Kuaishou, Qzone, Pinterest, Reddit, LinkedIn, Quora, Discord, Twitch, Tumblr, Mastodon, and like companies."

That list, especially given the "like companies" part, includes easily several million people.

Also "Election Integrity Partnership, the Virality Project, the Stanford Internet Observatory, or any like project or group".

What makes a group "like" those orgs?

The prohibited topics and purposes of communication are incredibly vague, basically anything contrary to "protected free speech", which has no definition in the injunction and is famously tricky to define in US law.

This amounts to a blanket ban from where I'm sitting.

If I were a low level staffer at DHS this would arguably prohibit me from expressing opinions on this matter to a friend or spouse working at a social media company, for fear of, for example, "encouraging reduction of content posted with social-media companies containing protected free speech". The fact that that example is silly is precisely my point. Injunctions must be narrowly tailored to address the specific conduct at issue. This is so broad as to make a joke of the process and in doing so harms the free speech and rule of law that are at issue in this case.

I linked that in my original comment in this thread: https://news.ycombinator.com/item?id=36616058

I know very well what an injunction is and does. You seem to be mistaken on what “law” is. It is by no means limited to statutory text or even final judicial opinions.

The fact that contempt of court is the only real penalty available for violating this injunction is exactly why it’s harmful. Making ludicrously broad and unenforceable injunctions like this inevitably corrodes the rule of law and damages the overall system.

It’s a blatantly illegal prior restraint on speech, completely at odds with the values the plaintiffs and judge claim to hold.

Free speech cuts both ways. If you’re pleased when a judge bans any and all communication among millions of citizens, you don’t actually value the first amendment, you’re just cheering a partisan victory.

Read the entire injunction. It’s only seven pages. Then tell me with a straight face that you think it’s a good thing for free speech.

https://storage.courtlistener.com/recap/gov.uscourts.lawd.18...

It amounts to “no one from these 8 government agencies may communicate with anyone working at these three non profits, 20 social media companies or any similar organization”

I’m not defending the behavior alleged here but this judge is not the sort of person you want adjudicating serious issues. You don’t fight censorship with blanket bans on speech.

A supporter of free speech should be horrified by this ruling. If you’re not, imagine an injunction of similar scope where the political sides were reversed.

The plaintiffs have not demanded a jury, so yes, this judge will make the final ruling, although it will certainly be appealed. Docket:

https://www.courtlistener.com/docket/63290154/missouri-v-bid...

To a first approximation, the appellate system is the only real mechanism for oversight of federal judges not engaging in outright misconduct. This is why packing the federal judiciary with intemperate partisans is so dangerous.

Are you sure that Perl took it from ruby and not the other way around?

(edit: a subsequent correction has obsoleted this comment)

People inevitably convince themselves that DDOS-levels of traffic are unrealistic until they’ve actually been attacked a few times.