theteapot · HackerTrans

9 giorni fadiscuss

Or better, sleeper agents. Anthropic released a study on this in 2024 "Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training" -- https://www.anthropic.com/research/sleeper-agents-training-d..., https://www.youtube.com/watch?v=_y9j2BoHg2c

theteapot

12 giorni fadiscuss

The difference is watches and corvettes typically appreciate in value, where as computer hardware typically drops like a rock.

theteapot

13 giorni fadiscuss

> Constant: the IDOR dataset (the same real, open-source applications we've used in prior research) ...

What we're they? Also, wouldn't one expect a more recently released coding agent (with a more recent knowledge cut off) to perform better because they have access to more knowledge about vulns in these OSS projects, and even possibly have knowledge of your own "prior research"?

theteapot

17 giorni fadiscuss

What's an eval?

theteapot

mese scorsodiscuss

Agree. From the article:

> Here's my favorite part, though. Digging into the data, one of the first things that jumped out at me with blinding clarity was that the worst release, by far, in rsync history was entirely prior to the introduction of Claude ... And yet nobody noticed.

Language really does suggest the article's author does have a dog in this fight and is cloaking opinion in fancy statistics jargon. "Blinding clarity"? All you have to do is draw a plot. And anyway, v3.4.1 was 2025-01-16, technically well within the AI assisted coding era and before attribution was becoming standard practice.

theteapot

mese scorsodiscuss

I spend $0/month.

theteapot

2 mesi fadiscuss

> having more engineers around was beneficial to the stock price ... When banks hiked interest rates ... It was just no longer profitable to keep a bloated engineering staff around to boost the stock price.

Erm, what's known of the mechanism coupling software engineer head count and stock price? Or is it just an empirically observed phenomena?

theteapot

2 mesi fadiscuss

> I could talk fancy and bullshit ... I became a developer and data engineer, and I became really good at it

That's a formidable combination.

> I found myself becoming an executive at long last on the strength of my technical abilities, and it turns out executives don't actually need to do much of anything and really ...

You probably think that because talking fancy and bullshitting come naturally to you.

theteapot

2 mesi fadiscuss

I think he means template-injection -- https://woodruffw.github.io/zizmor/audits/#template-injectio...

theteapot

2 mesi fadiscuss

Completely agree. Had me until the very last point. WTF. Communicate.

theteapot

2 mesi fadiscuss

Nurse Practitioner? I would say SOLID [1] is a good start, but then I watched this [2] and now I'm in crisis and can't code anymore.

[1]: https://en.wikipedia.org/wiki/SOLID [2]: https://www.youtube.com/watch?v=wo84LFzx5nI

theteapot

2 mesi fadiscuss

> Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise.

Good. Then we are on the same page.

theteapot

2 mesi fadiscuss

This rings true for me too, but I don't think it counts if your just using AI to aid maintenance. The basic argument in the article is around how many hours of maintenance you have to do for each hour of "value-add" feature development. So A. your only measuring maintenance costs not the ratio and B. The "old code" whp wasn't written with AI in the first place.

theteapot

2 mesi fadiscuss

Your wrong. It was both. The payload was embedded in the binary blob test file. The mechanism to pull it into the build was added to the release tarball only.

Here's the quote from the guy that discovered it in the initial public disclosure [1]:

  After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) I figured out the answer. The upstream xz repository and the xz tarballs have been backdoored. At first I thought this was a compromise of debian's package, but it turns out to be upstream. One portion of the backdoor is *solely in the distributed tarballs* and debian's import of the tarball ... it is also present in the tarballs for 5.6.0 and 5.6.1.

[1]: https://www.openwall.com/lists/oss-security/2024/03/29/4

theteapot

2 mesi fadiscuss

In xz-utils hack the attacker slipped changes into the Github release tarball that were not present in the Github version / git commit history. The Debian maintainer built from the release tarball instead of just pulling from the git repo directly. Shouldn't have been doing that but good luck convincing him not to use the workflow he's been using for the last X years (I tried). With repro builds we can clone the git directly confirm we get the same build.

theteapot

2 mesi fadiscuss

> The technique appears to be new: I haven't found a proper write-up of this, nor of any other provider-independent solution.

Maybe I'm missing something but SSH already has a built-in solution for this, key-certs. Just sign the server key with a private CA key you trust.

theteapot

2 mesi fadiscuss

Congratulations. It made me remember how proud I was when I became a Senior, and then earned my Super Engineer shortly after. Just recently I've earned my Extreme Engineer title. Good luck on your journey.

theteapot

2 mesi fadiscuss

False dichotomy. There was a series of blatant process failures from Github maintainer through Debian package maintainers. IFUNC also bad.

theteapot

2 mesi fadiscuss

Mmmm, fresh people.

theteapot

2 mesi fadiscuss

the obscure IETF? Which standard is that exactly? Who cares guess - Claude do that stuff.

comments