Daniel Stenberg:

Mythos finds a curl vulnerability

Yes, as in singular one.

[…]

My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing. I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos. Maybe this model is a little bit better, but even if it is, it is not better to a degree that seems to make a significant dent in code analyzing.

This corroborates my own experience that I reported over on the fediverse:

Having now seen Mythos vulnerability scan reports, I can say first-hand that the “OMG the sky is falling” narrative was hype. I'm not saying there’s nothing there, it does find things, even things here and there that humans have overlooked, and some fraction of its findings may be scary ones – but the only way in which Mythos is a step change over previous models is the signal-to-noise ratio of its results.

So far the only people who seem to remotely corroborate Anthropic’s own claims are the Firefox folk, who had 271 vulnerabilities identified during initial evaluation. A whole bunch of vulnerabilities, to be sure – but even they conclude as follows:

Encouragingly, we also haven’t seen any bugs that couldn’t have been found by an elite human researcher. Some commentators predict that future AI models will unearth entirely new forms of vulnerabilities that defy our current comprehension, but we don’t think so.

Neither do I. And their article’s central premise is that rather than unearthing some inexhaustible subterranean ocean of insecurity, the models are merely surfacing more from a limited well of vulnerabilities which will simply dry up faster as a consequence:

The defects are finite, and we are entering a world where we can finally find them all.

Say you want to write script that will set up the next Git commit for you without creating it – just stage some content and prepare a commit message. The next bare git commit should automatically populate the editor with that message, without any flags passed to it, nor any Git configuration changes, and without affecting any subsequent invocations of git commit. The staging part is obvious… but where do you put the commit message?

The answer, which appears to be undocumented, turns out to be .git/MERGE_MSG:

echo 'there we go' > .git/MERGE_MSG

If you now run git commit, your editor will open with the “there we go” commit message already entered.

Update: originally in this entry I suggested using .git/SQUASH_MSG, which probably seems more eccentric than .git/MERGE_MSG. Because I could not remember how to trigger this behaviour in Git outside of a merge or rebase, I was reduced to reading the code of git commit, where the related logic is somewhat convoluted, and the .git/SQUASH_MSG case is the easiest to discover. I finally remembered that it is git cherry-pick --no-commit where I saw this behaviour first, which allowed me to discover what it does by just running the command and examining the .git directory. I am writing this down because that should remain an easy route to figuring out whatever the new mechanism is, should it ever change.

This is another one of those small-lightbulb moments like this one was. The setup for this one is that I run some X programs on my home server for remote use from the machine I actually work on – but via VNC, where I never got clipboard integration working.¹ I only rarely need to paste in X, so I’ve just been living with this… until the obvious recently occcured to me:

The low-brow but perfectly serviceable solution is to just use the clipboard commands of both systems, strung together with a pipe over a SSH connection, to transfer the clipboard contents. Of course this needs to be invoked manually every single time I want to copy something on one side and paste it on the other – the low-brow bit. But that still is far more convenient than pasting into terminals (like I was doing before), to the point that I won’t feel the lack any more.

Only… it didn’t quite work right.

I searched the web for a fix and unsurprisingly found that plenty of people have had the same idea:

# perform a copy in X, then run this, then paste locally
ssh server.home xclip -selection clipboard -out | pbcopy

(If you’re not using a Mac locally, just replace pbcopy (and pbpaste) with your system’s equivalent.)

The trouble is, I was looking for the other direction – and far from novel though the idea may be, I didn’t find a command written up anywhere. There turns out to be a minor trick to it (and maybe that’s why my searches were coming up empty), which ultimately I had to figure out for myself:

# perform a copy locally, then run this, then paste in X
pbpaste | exec ssh server.home 'exec xclip -selection clipboard &> /dev/null'

Namely, this won’t work as desired without the “&> /dev/null” bit.

It will work, except without returning to the prompt. It just hangs. This comes down to the way that selections work in X: the program in which content was selected registers itself to answer requests to paste that selection and must then answer them – so no running program, no paste. So the only way xclip can work is to stick around as a background process after taking control the clipboard – until something else is copied, at which point it can exit. And because xclip doesn’t close stdout and stderr, ssh won’t know to quit any sooner than that, and so it sits there waiting. To create a compound command that immediately returns to the prompt after shipping the local clipboard contents over, it is therefore necessary to close stdout and stderr on xclip explicitly.

With that, I have a solution I can happily live with.²

---

1. This is after trying all the usual suggestions (like running vncconfig on the server). Presumably they didn’t work because I am using the Screen Sharing app that comes with MacOS, which apparently is not actually a VNC client but just uses that protocol for most of its functionality.

   The backstory to that is that I used to use Xpra for remote X because it makes that rather neat: individual windows on the server are displayed remotely as individual windows on the client, complete with native local windowing UI, so there is none of the ungainly window-in-window hassle and no need for an X window manager. The catch is that Xpra requires reasonably matching versions on server and client, and I have at times fallen well behind running the latest OS version on either side, which on a few occasions has made them tricky to align. A while ago I failed to find any working constellation at all, at which point I decided I was tired of doing that and would switch to something less bespoke. Now I no longer need to install anything on the Mac and have multiple highly compatible options on the server. ↩

2. Or maybe I’ll go back to Xpra, who knows… ↩