HN user

robomc

374 karma
Posts1
Comments138
View on HN

"I have a vague concern, so I'm now using a shittier toolchain. You shouldn't do it though." is a weird post format.

Yeah the really misleading part of the screenshots in this article is that it doesn't show the "resize cursor", which basically makes this a non issue.

Also, for anyone reading this who hates the general aesthetic, go into Accessibility and hit "reduce transparency". This has been a desirable setting for last few OSX versions.

If the cloud service you’re using doesn’t support OIDC or any other ephemeral access keys, then you should store them encrypted. There’s numerous ways you can do this, from password managers to just using PGP/GPG directly. Just make sure you aren’t pasting them into your shell otherwise you’ll then have those keys in plain text in your .history file.

This doesn't really help though, for a supply chain attack, because you're still going to need to decrypt those keys for your code to read at some point, and the attacker has visibility on that, right?

Like the shell isn't the only thing the attacker has access to, they also have access to variables set in your code.

Ortega hypothesis 10 months ago

To me this kind of sounds like the other side of the same thing. Lunchpail scientists accumulate data within an area of research made interesting by a landmark work by a big name. Future big names make breakthroughs by drawing together a lot of the lunchpail work. etc etc

I found out recently that I've been paying for Prime Video since 2020. I think I did legitimately sign up for it. That's not my complaint.

But it's fairly scummy how it doesn't seem to send you any email, the payments have a very vague generic coding like "AMZ2318971239", and the actual subscription management is super buried. I only noticed it, after years of using Amazon a fair bit, when I went deep into my account panes looking for something else.

because researchers from Kudelski Security most likely tried different static analysis tools and they didn't work the way Rubocop did.

Yes but that's kind of the point - they say this issue that takes you directly from code execution to owning these high value credentials was only present on rubocop runnners but isn't it a bit coincidental that the package with (perhaps, since they chose it) the easiest route to code injection also happens to be the one where they "oops forgot" to improve the credentials management?

It just seems very convenient.

From the CEO's response:

On January 24, 2025, security researchers from Kudelski Security disclosed a vulnerability to us through our Vulnerability Disclosure Program (VDP). The researchers identified that Rubocop, one of our tools, was running outside our secure sandbox environment—a configuration that deviated from our standard security protocols.

Honestly, that last part sounds like a lie. Why would one task run in a drastically different architectural situation, and it happen to be the one exploited?

It’s all part of the sharp decline in vocational education — shop class — in this nation that began in the 1980s as blue collars became unfashionable and the emphasis shifted to a college education.

Yeah that's what happened. They became "unfashionable", rather than hopelessly precarious due to structural economic changes.

Maybe this is misguided, but it feels a bit to me (comparing the ruby and js versions for example) that this is using the same code examples in both, and neither are really typical of the sorts of code people in either language community would actually write?

I have a silly question I guess... why does it print everything out twice?

~ doggo google.com

NAME TYPE CLASS TTL ADDRESS NAMESERVER

google.com. A IN 296s 142.250.67.14 127.0.2.2:53

google.com. A IN 296s 142.250.67.14 127.0.2.3:53

~ doggo news.ycombinator.com

NAME TYPE CLASS TTL ADDRESS NAMESERVER

news.ycombinator.com. A IN 1s 209.216.230.207 127.0.2.2:53

news.ycombinator.com. A IN 1s 209.216.230.207 127.0.2.3:53

yeah the way he described it it's like... well who would ever do that. but foreign keying to emails or usernames is much easier to "accidentally" do and is a classic source of long-term headaches.

I mean, in codespaces you have scripts that run as the codespace is built. So we basically have s3 buckets with appropriately-sanitized (hopefully) data dumps that the repos copy down and then import into the database.

You can tell codespaces to include the AWS commandline tooling automatically via the devcontainer "features" attributes. And you can tell it to run a script once the codespace has initially been created using the postCreateCommand (which imo is a lot easier to debug than beforeCreate...

For us the s3 credentials live in the github repo as codespace secrets (although I think you could set up a much better auth approach via the vscode aws plugins possibly).

We are an agency where you might flip between working on several completely different projects in a week, and for us it's extremely useful.

We'd had all our sites set up to run fairly easily via docker compose prior, but I'd still find myself debugging people's setups fairly frequently. And giving developers data and secrets was often either insecure or complicated, depending on the codebase.

With codespaces, people can just jump straight into a working project, without pulling any client code or secrets or data onto their machine. It still requires maintenance sometimes but at least when I fix the codespace config I know everyone will definitely benefit from the changes.

The main downside is it's pretty expensive (if you have, say, 10 devs using it all day every day) compared to "free".

If you work on just a few projects, and/or you have very sophisticated systems across the board (like every site has an on-rails setup script with useful sanitized dev data, and secure SSO'd secrets management), I doubt it's worth it.

But in our case, a relatively junior dev being able to spin up a working dev version of a site they've never worked on in 5 minutes with no issues, so they can knock out a 3 hour change and maybe never work on it again, is a big money saver.

It's also meant that we can more easily standardize everyone's laptops without having to consider how well they work as bare metal dev machines (which has meant we can move everyone to fairly cheap macbook airs without people moaning about their tooling or storage size etc.)

I also like that access to a lot of stuff becomes directly mediated moment to moment by someone's github access (which for us also runs through our sso, cloudflare zt etc).

We're doing it in a slightly clunky way though - we use docker compose still, inside the codespace. I like this approach personally bc it feels like we're less locked in to the platform. For us it also made the initial migration easier. I think it also makes debugging the environment a bit easier because you don't need to keep rebuilding constantly on changes, you can just dcb dcup...

And the radio signals are a pretty unhelpful indicator because you could have looked at earth with life on it at any point within the last three billion years and there have only been radio emissions for the last 30-millionth of that time. And they might become pretty rare or completely gone in another 30-millionth.

For mammals, the radio-emitting time is still only a 2-millionth of the total.