Notices by Simon Tatham (simontatham@hachyderm.io)

@dalias on the part of "can get force-pushed between starting to review and merging it": I guess that might mean you like to review patches by pointing a browser at the remote site?

I can see that if someone points me at a clone of my repo on Github, and I look at the patch in a browser and like it, then there's a risk that the version I 'git fetch' and merge into my repo might not the the same one.

But that's not how I do it. I 'git fetch' _before_ the review, downloading a copy of the candidate branch to a checkout on my own machine. Then I review the patch in gitk, probably compile and test it too (after at least one eyeball review pass), and if I'm happy, merge it. And all three of those steps refer to the same version of the patch, because I only ran 'git fetch' once (unless the submitter notified me to go and check back for more changes).

@dalias hmm. I think there are really two separate questions there: (a) the risk of the linked-to repo vanishing _while_ you're still reviewing and considering the contribution, and (b) the risk of it vanishing long afterward so that the long-term record goes away.

I've never considered (b) particularly important, although I'm open to being persuaded otherwise. To my way of thinking, once I've accepted a patch, the _final_ version of the patch is important to preserve, because it reflects the history of how my actual code evolved. But all the review drafts are just scaffolding – important during construction, but after you're done you can safely take them down and throw them away. I apply this equally to other people's patches sent to me, and my own patches I send to other people.

I've never yet had the problem of the repo containing the PR branch vanishing in mid-review. I would have guessed that it wouldn't be common because it's in the submitter's interest to keep it running! But I suppose I'm thinking on the timescale of weeks at most, however long it takes me to either accept or reject.

If PRs were public, then it seems more plausible you'd want to keep even the rejected ones forever. A patch I didn't think was worthy of getting into _my_ version of the code might still be useful to someone else to apply downstream of me.

@dalias indeed, Unicode does carefully specify its own rule for translating between upper and lower case, which will tell you when there's no such mapping available, and also work correctly when there is one but it doesn't follow the 'xor with 0x20' rule.

(Fun fact: the 'xor with 0x20' rule works for half the Greek alphabet but not the other half, because the two cases of Greek are separated by 0x20 but offset by 0x10. E.g. the xor rule maps Γ to γ as you'd like, but Σ and σ each map to an unrelated thing.)

But if I'd used the proper Unicode case mapping rules then the joke wouldn't have worked :-)

@inthehands conversely, there's a case where people expect code to behave like law. Namely, the people who want encryption systems to have backdoors accessible via govt paperwork like a court order.

The point they (perhaps deliberately) never understand is: you can't make the _cryptosystem_ verify a court order is legit. A human has to check that. And then they do something to the code. Which the code would obey whether or not the human had checked the court order, or even had one to check.

@bascule that reminds me of the time I noticed in a web server log that occasionally clients would get a 404 after requesting a bizarre URL of the form

https://[hostname]/0.000000E+00username/

which, after some headscratching, I realised was because they had started with

https://[hostname]/~username/

and then %-escaped the tilde

https://[hostname]/%7Eusername/

and then accidentally used that as a printf format string, which took %7E to be a floating-point format directive!

If you put the same pipe on a process's stdout and stderr, you get all its output interleaved in the order it wrote it (after stdio buffering).

If you use two pipes, you can tell which output went where.

But what if you want separation _and_ ordering?

You can _almost_ do it by making two AF_UNIX datagram sockets connected to the same peer. Then recvfrom() gives you a chunk of data _and_ tells you which socket it was written to.

But you lose the ability to detect EOF, which is a show-stopper!

'mkdir -p' lets you make a deeply nested subdirectory like a/b/c/d, making all the intermediate directories on the way to it. So if even 'a' doesn't exist, it'll make that, then a/b, etc.

But you can also get it to make multiple _non_-nested directories, because it accepts '..' in the path and doesn't treat it specially:

$ mkdir -p alpha/../beta/../gamma
$ ls
alpha beta gamma
$

[Edit: to be clear, I'm pointing out an amusing edge case, not giving advice!]

Centuries after Sauron's defeat, Middle-Earth developed motor racing, and Gandalf found his new dream job: driving the safety car.

Unfortunately, he didn't think of applying for that job until he needed a career change, having been fired from the prestigious position of Head of Examinations at the University of Gondor.

In bash, writing ${var?} instead of just ${var} or $var means if var isn't defined then bash will throw an error and _not_ execute your command, instead of expanding it to "" and carrying on.

mv file1 file2 $subdir # oops, I overwrote file2
mv file1 file2 ${subdir?} # error message instead of disaster

My favourite use of this is for example commands in documentation, with placeholders for the user to fill in. Then it's OK if a user accidentally copy-pastes it _without_ filling them in!

The Dragon Book orthodoxy for handling source code is a regex-based lexer and an LR parser, in series, with no feedback between them and no weird edge cases.

What widely used languages can _really_ be parsed this way? So many major languages can't: type name ambiguity, context-sensitive lexing of >>, offside rule, conditionally significant newlines, …

(Not counting really simple things like Lisp: something with a grammar the size of C, suitable as a full-scale example for a parser generator.)

We've released #PuTTY version 0.81. This is a SECURITY UPDATE, fixing a #vulnerability in ECDSA signing for #SSH.

If you've used a 521-bit ECDSA key (ecdsa-sha2-nistp521) with any previous version of PuTTY, consider it compromised! Generate a new key pair, and remove the old public key from authorized_keys files.

Other key types are not affected, even other sizes of ECDSA. In particular, Ed25519 is fine.

This vulnerability has id CVE-2024-31497. Full information is at https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-bias.html

@goatsarah certainly the Amiga was where I first had a need to refer to the mouse pointer at all, and I'm pretty sure that was what it was called there. So I'd believe it!

Been reminded a couple of times recently that I seem to be the only person who refuses to say 'mouse cursor'. I call it the mouse _pointer_, to distinguish it from the 'cursor' which is the block or line or caret in your terminal or text-editing environment that shows where your next keyboard input will go.

If you think 'cursor' is the mouse pointer, what's the other thing called?

And if you say 'cursor' for both, what's your usual strategy when you need to clarify?

Linux sometimes reports a USB peripheral as "Generic Mass Storage Device".

Suddenly strikes me: isn't that a pretty good description of a black hole?