nightpool

The numbers were in the post when I clicked through and when I made the comment. It looks like the HN moderators have since changed the link for the post to go to the CVE entry. However, my comment was about the reddit thread, not the CVE entry.

Definitely agree—that's why I hoped the openclaw maintainer would have been able to speak to those numbers and whether or not they were accurate.

I agree—it looks like the OP didn't provide any sources for these numbers either. That's why I would have hoped that the original maintainer had a better set of metrics to dispute them. It doesn't seem like he does though :(

Can you speak a little bit more to the stats in the OP?

* 135k+ OpenClaw instances are publicly exposed

* 63% of those run zero authentication. Meaning the "low privilege required" in the CVE = literally anyone on the internet can request pairing access and start the exploit chain

Is this accurate? This is definitely a very different picture then the one you paint

Surely "the commits are attributed to the user who creates them" is a pretty basic feature of the git CLI, and not something that you can add in as a fix later after posting your project to Github and writing a blog post about how much faster than git it is.

It's very easy to be faster than git's CLI if you don't have to do any of the things that git's CLI does!

Seems like they actually sped bun up ~1x:

    When evaluating the complete bun install improvements, it came out speed-wise to about the same as the existing git usage (due to networking being the big bottleneck time-wise despite more cases being slightly faster with ziggit over multiple benchmarks). Except, it's done in 100% zig and those internal improvements pile up as projects consist of more git dependencies. All in all, it seems like a sensible upstream contribution.

So you have to maintain a completely separate git implementation and keep that up to date with upstream git, all for the benefit of being indistinguishable on benchmarks. Oh well!

> I think most people would interpret “scanning your computer” as breaking out of the confines the browser and gathering information from the computer itself.

Yes, but I also think that most people would interpret "Getting a full list of all the Chrome extensions you have installed" as a meaningful escape/violation of the browser's privacy sandbox. The fact that there's no getAllExtensions API is deliberate. The fact that you can work around this with scanning for extension IDs is not something most people know about, and the Chrome developers patched it when it became common. So I don't think describing it as something everybody would expect is totally fine and normal for browsers to allow is correct.

No, they propose just concatenating it with the data received from the network

> it makes a concatenation of the domain separator (@0x92880d38b74de9fb) and the serialization of the object, and then feeds the byte stream into the signing primitive. Similarly, verification of an object verifies this same reconstructed concatenation against the supplied signature.

> Note that the domain separator does not appear in the eventual serialization (which would waste bytes), since both signer and receiver agree on it via this shared protocol specification. Encrypt, HMAC, and hash work the same way

No, I think a lot of humans can explain why they're adding a new button to the checkout page, or why they're removing a line from the revenue reconciliation job. There's always a reason a change gets made, or else nobody would be working on it at all :)

Yes, this is a trend I've noticed strongly with Claude code—it really struggles to explain why. Especially in PR descriptions, it has a strong bias to just summarize the commits and not explain at all why the PR exists.

The minute between December 31, 2016 23:59 and January 1st 2017 is 61 seconds, not 60 seconds. The hour that contains that minute is 3601 seconds, the day that contains that hour is 43201 seconds, etc. If you assume a fixed duration and simply multiply by 43200, your math will be wrong compared to the rest of the world.

Daylight savings time makes a day take 23 hours or 25 hours. That makes a week take 7254000 seconds or 7261200 seconds. Etc.

That wasn't my experience, when I resized the window and new text showed up, it was completely out of order

Presumably because the DOM order of the elements is not the actual order of the lines (you can see this with e.g. the blockquotes), so it would be confusing if the user tried to copy the text and saw that all the lines were jumbled up

No idea how I'm supposed to read the end of this. But it seems kinda interesting? Not that like, require('fontmetrics') doesn't exist, but it's definitely true that most JS needs more font rendering then the browser seems capable of giving us these days.

Yes, everyone in the WebPKI community is pushing for shorter validity lifetime. But as you can see in the parent thread here ("Which is yet another chore. And it doesn’t add any security"), everybody is mad that browsers are pushing for shorter certificate lifetimes.

Sure, happy to. The average revocation ticket is something like https://bugzilla.mozilla.org/show_bug.cgi?id=1892419 or https://bugzilla.mozilla.org/show_bug.cgi?id=1624527. The CA shipped some kind of bug leading to noncompliance with baseline requirements. This could be anything from e.g. not validating the email address properly, inappropriately using a third-party resolver to fetch DNS names, or including some kind of extra flag set that they weren't supposed to have set. The CA doesn't want to revoke these certificates, because that would cause customers to complain:

    In response to this incident of mistaken issuance, the verification targets are all government units and government agency websites. We have assessed that the cause of this mis-issuance does not involve a key issue, but only a certificate field issue, which will not affect the customer's information security. In addition, in accordance with the administrative efficiency of government agencies, from notification to the start of processing, it requires agency supervisors at all levels. Signing and approval, and some public agencies need to find information vendors for processing, so it is difficult to complete the replacement within 5 days. Therefore, the certificate is postponed and revoked within a time limit so that the certificates of all websites can be updated smoothly.

[...]

    In this project we plan to initially issue new certificates using the same keys for users to install, and then revoke the old certificates. As these are official government websites, and considering the pressure from government agencies and public opinion, we cannot immediately revoke all certificates without compromising security. Doing so would quickly become news, and we would face further censure from government authorities.

The browsers want them to revoke the certificates immediately, because they rely on CAs to agree to the written requirements of the policy. If you issue certificates, you must validate them in precisely this way, and you must generate certificates with precisely these requirements. The CAs agree in their policies to revoke within 24 hours (serious) or 120 hours (less serious) any certificates issued that violate policy.

And yet when push comes to shove, certificates don't actually get revoked. Everybody has critical clients who pay them $$$$$ and no CAs actually want to make those clients mad. Browsers very rarely revoke certificates themselves, and realistically their only lever is to trust or distrust a CA—they need to rely on the CA to be truthful and manage their own certificates properly. They don't know exactly all of which certificates would be subject to an incident, they don't want to punish CAs for disclosing info publicly, etc. So instead, they push for systematic changes that will make it easier for CAs to revoke certificates in the future, including ACME ARI and shorter certificate lifetimes.

I agree with you that the root problem is that the library author's design over-uses exception. But when the library in question is the standard library and the operation is as basic as Integer.parseInt, then I think it's fair to criticize that as a language issue, because the standard library sets the standard for what is idiomatic + performant for a language.

I've never had to log in to Github as part of my daily flow. Only once to set up a new computer. Are you logging in using an incognito window or something?

I've never had that issue with Github—I think their account mixing setup reduces the amount of work I have to do to sign in 100x compared to other SSO systems I use.

No, they're not useless at all. The point of shortening certificate periods is that companies complain when they have to put customers on revocation lists, because their customers need ~2 years to update a certificate. If CRLs were useless, nobody would complain about being put on them. If you follow the revocation tickets in ca-compliance bugzilla, this is the norm—not the exception. Nobody wants to revoke certificates because it will break all of their customers. Shortening the validity period means that CAs and users are more prepared for revocation events.

Okay, but this contradicts your original statement that "Java doesn't steer anyone to use these [footguns]". Every language has a way to parse integers, and most developers do not need a custom parser. Only in Java does that suddenly become a performance footgun.

How would you handle validating numeric input in a hot path then? All of the solutions proposed in #5 are incomplete or broken, and it stems from the fact that Java's language design over-uses exceptions for error handling in places where an optional value would be much safer and faster.

Yes, ADB disables the 1-day period.

You're thinking of the New Yorker, not the New York Times.

I would hope that most people who are technically competent enough to be on HN are technically competent enough to quit orgs with coding standards that bad. Or, they're masochists who have taken on the chamllenge of working to fix them

it works for any gist, public or private. it doesn't need to follow a certain format. it's just based on how the secret itself is formatted—it works for secrets that have a predictable pattern, like the AWSK prefix for Amazon keys.

if algolia keys have this predictable pattern, then they can enroll in secret scanning. If they don't then they probably can't

? Yes? Toomuchtodo is reminding the author (and other commenters), that github gists are one way to make sure secrets are secured / remediated before making a public post like this. Maybe not the most responsible whitehat action, but I can see it being useful in some cases where outreach is impractical / has failed.

Unfortunately, it doesn't look like Algolia has implemented this

when your startup is three employees and only one technical? this person created their AWS root account, I think it's fair to assume that he's their first engineer and probably first employee

Board members of a nonprofit are subject to external supervision, including auditing, regulators and—in extreme cases—lawsuits. The Supreme Court is unique because it is the court of last resort for the entire United States—even a state supreme court justice would be able to have their recusal decisions reviewed by a higher court, much less a random board member of a nonprofit.

What government programs in the US are stably funding open-source developers? I think most government-funded open source projects are very gunshy about looking for new funding because of the Trump administration completely politicizing grants and funding. I would not want to have to sign an anti-BDS pledge to get my open source project funded, and I would imagine that goes for many people in the community. Also, what "dismissive comments" are you referring to? The only one I saw was "Government support won't work for OSS at scale — it's too globally decentralized". Which is a fair criticism—open source projects are incredibly globalized, and getting e.g. New York State to fund an open source project that has contributors from Ukraine, India and China is a headache I don't think anyone would want to try and go through. There's just no benefit to the state administrators to fund that kind of project—they want to support parochial, home-grown projects with local ties.