* https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
I created a mitigation tool that can be used to fix/remove the worm from all infected repositories, and did a writeup about this.
On Monday, the Hades campaign introduced Composer, Go and Pip support. Before that it had only support for NPM and AI assistant editors. (Well, and Ruby btw but nobody uses Rubygems anymore it seems).
What even Microsoft gets wrong: This is the first worm that runs on all platforms in the code ecosystem. Developer host machines, servers, ci/cd runners. And all of them spread the worm to all repositories that are accessible on those machines.
You would have to completely shutdown 100% of all computers AND aws ec2 AND google cloud platform AND azure AND kubernetes clusters AT THE SAME TIME to beat this worm. It literally spreads across all infrastructure.
Kill switch, as always with APT28 malware, is setting the host language to ru_RU.KOI8-R (LANG environment variable). That disables the spread mechanism.
My Mitigation Tool (I'm updating it as new package systems are targeted ...):
Yes you do. It's the one that your in-kernel terminal emulator talks to in order to splat its bitmap fonts onto the screen. It is whatever wsdisplay has attached to, which can be one of a range of things from genfb through voodoofb and machfb to radeonfb. There was even a vesafb about 20 years ago.
If you have the files in the XDG locations and symbolic links in the old locations, this migration mechanism will mess things up quite badly, because it does not check for either symbolic or normal links and renames over the XDG file if an old location file exists.
The model here seems to be that configuration files are entirely under application control, and users do not go around manually creating them, changing them, or creating compatibility symbolic links. Which really does make a nonsense of using an INI variant as the configuration file format. One might as well make it easily machine readable if humans are never meant to be touching it.
But then this library has old design written all over it, once one looks at it with a Windows developer hat on. It claims to place global INI files in the Windows directory, something that has been deprecated in Windows for over 30 years. Although, just to make things interesting, that documentation does not describe what the code nowadays does.
Maybe, but notice that almost all of the article, and its followup posted today, is about the speed of starting a shell not of a terminal emulator window. So if you use interactive sub-shells, anything from shelling out of a vi clone or mailx, through :terminal in NeoVIM, to running tmux/screen or script, then the concerns are relevant.
That said, it is almost totally about the Z shell. So you might still qualify as 'weird' in this case on the alternative grounds of not using the Z shell. (-:
You can even tell which operating systems xe has used. Both of those are very specific. The \FOUND.nnn directories are something that IBM/Microsoft introduced when they re-did CHKDSK for OS/2, which was what Windows NT inherited. FILEnnnn.CHK in the root directory was the old Microsoft CHKDSK, and also Symantec/Norton SCANDISK, for MS/PC/DR-DOS.
On the UFS and suchlike filesystems, at the point that fsck is rescuing orphaned i-nodes, it still has not fully gone through the process of checking and correcting free list information, or indeed fully eliminating errors from the i-node table. Creating a directory involves allocating a new i-node from an unused slot, and free blocks off the free block list.
Ironically, because they are slightly or grossly different to Unix filesystem formats, on HPFS and FAT this is less of an issue. (FAT usually has unused slots in the root directory that it is sane to use at that point, for example.) CHKDSK on OS/2 did create its \FOUND.nnn files on the fly.
I recommend starting with ECMA-35. The actual structure of escape sequences is explained there. Otherwise it gets lost that it's the ESC [ that is the entire escape sequence, an alternative form of CSI, and that this actually is one part of an entire mechanism of escape sequences with intermediate and final bytes. It's a control sequence that CSI then introduces.
The important part is that the escape prefix is just an alternate way to represent each of the 32 C1 control characters with a pair of 7-bit characters.
I have a book on my bookshelf, Eric Foxley's Unix for Super-Users. It was published in 1985, and it answers this question on page 52, the first page listed for the entry 'lost+found' in its index.
This is surely not the earliest book mention, is it? (It'll be in earlier man pages, of course.) Google Books does not give me an earlier one, although it does yield another 1985 book.
Fun fact: Foxley cautioned that lost+found must be pre-sized ahead of time, because the fsck of the time did not grow the directory to fit found files.
Foxley gives the manual procedure for sizing the lost+found directory on the aforementioned page 52.
I have the 1986 edition of Fielder's and Hunter's UNIX System Administration and it does not mention any such command in its discussion of lost+found in chapter 3. It references AT&T Unix System 5 Release 2 (or 'UNIX 5.2' as the book puts it).
But Google Books tells me that their later 1991 update, referencing Release 4 and with an updated title to match, does indeed mention mklost+found. So that looks like something that appeared in Release 3 or 4.
I used to port Unix for a living (V6 thru SysVr3) I know it was in Vr2, and I have a man page that says "(last mod. 1/15/87)" which would likely make it SysVr1 or earlier
My guess is that it was undocumented until Release 3 or 4, so the book authors simply never found out about it. Andrew Tanenbaum knew about it at the same time as the first Hunter and Fielding book, but likely this was word-of-mouth stuff.
Foxleys book does not actually claim reason why it need to be preallocated. I've got the book also. Index mentions fsck only page 52, where it reads:
"52 UNIX FOR SUPER-USERS
...
The filestore consistency check is performed by the command fsck (usu-
ally stored as /etc/fsck, but sometimes in /bin), which should be used to check
all discs used as file-systems. It defaults to the list of filestore devices given
in the file /etc/checklist. At this stage, most of the file-systems will not be
mounted, so will be inactive; only the root file-system will be active. The
fsck command goes through each one in turn, reports any inconsistencies in
them, and offers to correct them. The reply to each query is either 'y' for yes
(correct the inconsistency), or 'n' for no (leave the file-system inconsistent).
A parameter '-y' to the command assumes 'yes' replies to all questions, so
that no further interaction is necessary; a parameter '-n' similarly assumes
all 'no' answers, and therefore needs no write permission to the device. Any
'yes' reply may involve the loss of information, such as the complete removal
of a suspect file. Suspect files on the file-system being checked are written to
a directory lost + found on the device if such a directory exists; this directory
must have been created, and be sufficiently large already to hold the names
of all the files involved. This can be ensured by first creating the directory,
then creating a number of files in the directory, and then removing them.
The corrected systems will be consistent, and can later be mounted as and
when required. It may be possible to recover information from deleted files
by looking at the lost + found directory. There should be a lost + found direc-
tory at the head of each mountable file-system.
When checking the root file-system, there are complications, in that it
will be active (even though, because it is root, it will not be formally mounted
as such, but is implicitly mounted as root during the booting process). If
modifications are necessary, they should be completed, and the machine
rebooted without first performing a sync (see section 4.5 below for the nor-
mal procedure for taking a system down). This is to ensure that the disc as
modified by fsck is not overwritten by any in-core information, which may
have been generated from information read from the original corrupt (incon-
sistent) version.
...
"
But I've also read more detailed explanation that recollect is that unless blocks were preallocated, there was a possibility that lost+found need first allocate more blocks directory it already had, it would possibly led to losing some data that would otherwise been able to recover once fsck had advanced further from that point.
Old time UNIX systems directories were just another structured file, which a 'd' bit (like others you changed with chmod) on them, where each record was 16 bytes, which 2 first were the inode number followed by 14 bytes reserved for filename. IIRC linux also had first same limit first filesystems. You could read directory with any program, common feat was to check any odd stuff that "ls" would not show with could hexdump or "od" with some flags and print 16 bytes lines per row. That way you also could see any deleted or moved files from that directory, because directory entry was not quite long otherwise cleared but just clearing that inode reference two bytes.
A Quick look from other books that I have close me now Maurice J. Bach, The Design of Operating UNIX System (-86) contains much more about fsck and filesystem fixing issues scattered few pages in the book and what methods were used to mitigate loss of data. S.R Bourne The Unix System, no mention of fsck at all, at least by looking book automatically generated index.
It could have been some other quite old book I did read, but did not own or anything since BSD4.3-tahoe documentation I've read over the years. But sure it would be nice to read that exact reasoning again from credible sources.
edit: Oh, and you could preallocate also just by adding entries or copying some data to lost+found enough, and then remove entries. Unix traditionally have not compacted and resized directories. They only grow and can be if have been very large slow to traverse. The way to compact is creating another, moving existing data there and then swapping directories.
OK, I found bit more from UNIX System Administration Handbook Third Edition (Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein, with even more authors mentioned) 2001 book following:
"134 UNIX System Administration Handbook
...
The lost+found directory is automatically created when you build a filesystem. It is
used by fsck in emergencies; do not delete it. The lost+found directory has some
extra space prealocated so that fsck can store "unlinked" files there without having
to allocate additional directory entries on an unstable filesystem. Some systems pro-
vide mklost+found command that can recreate this special directory if it is aci-
dentally deleted.
...
"
No, that would be reverted for "violating the author's intent" if you edited an existing answer, and if you posted a new answer it'd be permanently at the end of the list because it would never attract many votes due to being at the end of the list.
* https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
* https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
* https://news.ycombinator.com/item?id=48416155
* https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)
reply