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

Jacob Bachmeyer <[email protected]>
Newsgroups gmane.comp.gnu.standards,gmane.comp.sysutils.automake.general
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.