automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor


From: Jacob Bachmeyer
Subject: Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
Date: Tue, 02 Apr 2024 01:11:31 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0

Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >     `distcheck` target's prominence to recommend it in the "Standard
> Targets for All Users" section of the GCS?
  > Replying as an Automake developer, I have nothing against it in
  > principle, but it's clearly up to the GNU coding standards
  > maintainers. As far as I know, that's still rms (for anything
  > substantive)

To make a change in the coding standards calls for a clear and
specific proposal.  If people think a change is desirable, I suggest
making one or more such proposals.

Now for a bit of speculation.  I speculate that a cracker was careless
and failed to adjust certain details of a bogus tar ball to be fully
consistent, and that `make distcheck' enabled somene to notice those
errors.

I don't have any real info about whether that is so.  If my
speculation is mistaken, please say so.

I believe it is completely mistaken. As I understand, the crocked tarballs would have passed `make distcheck` with flying colors. The rest of your questions about it therefore have no answer.

On a side note, thanks for Emacs: when I finally extracted a copy of the second shell script in the backdoor dropper, Emacs made short work (M-< M-> C-M-\) of properly indenting it and making the control flow obvious. Misunderstandings of that control flow have been fairly common. (I too had it wrong before I finally had a nicely indented copy.)

The backdoor was actually discovered in operation on machines running testing package versions. It caused sshd to consume an inordinate amount of CPU time, with profiling reporting that sshd was spending most of its time in liblzma, a library not even linked in sshd. (The "rogue" library had been loaded as a dependency of libsystemd, which the affected distributions had patched sshd to use for startup notification.)

I will send a more detailed reply on the other thread, since its subject is more appropriate.


-- Jacob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]