[sf-lug] "RANSOM VIRUS" ATACHED TO WEB SITE?

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Nice catch on Startpage!

I'm not going to mince words, here:  The real problem is the underlying
bad judgement shown by anyone ignoring the protection of Linux
distribution gatekeeping and installing software recklessly from
untrustworthy non-distro sources.  Don't.  Do.  That.  (Not you,
Michael, but the upthread poster and reckless software users generally.)

> (and why, pray tell, does Mozilla have it so readily as an install, with
> no particularly clear caveats or warnings at all?
> "Welcome to Firefox Add-ons.  Choose from thousands of"
> *thousads*?  Seems rather excessive to me).

The https://addons.mozilla.org/ site is _not_ meaningfully curated,
hence in effect a rather dangerous place.  For all practical purposes,
it's not curated in any way.  It's just the sum of every extension and
similar add-on for Mozilla products produced by anyone and added to
Mozilla's bazaar-site.  Just because you _can_ shop around for extension
software there doesn't mean you should.  And when a friend tells you
(generic 'you') that you should ignore your Linux distribution's
software management regime and install a cool 'search engine' or
'dashboard' from there, you should be saying 'No thanks.'

I'm going to close here with a cautionary footnote I published at the
bottom of an author's article in the late monthly magazine _Linux
Gazette_, because the author had blithely recommended ignoring one's
distribution package regime and installing 'upstream' software from
coders' Web sites:


http://linuxmafia.com/~rick/weatherwax.html#1

[1] Rick Moen comments: While it's useful and worthwhile to know about a
program's "upstream" development site, where (among other things) the
author's latest source code can be downloaded, there are a few
disadvantages that should be noted (and some alternative locations that
should be usually be preferred, instead, if such are findable):

1. Absent extraordinary measures on your part, your Linux distribution's
package-tracking system won't know about the program's presence on your
system. Therefore, it won't know to avoid installing conflicting
programs, removing libraries it depends on, etc.

2. You won't get any tweaks and enhancements that may be normal (or
necessary!) for applications on your Linux distribution — unless you
yourself implement them. You won't get security patches, either, except
those written by the upstream author.

3. Along those same lines, the desirable version to compile and run may
well not be the author's latest release: Sometimes, authors are trying
out new concepts, and improvements & old bugs fixed are outweighed by
misfeatures & new bugs introduced.

4. As a person downloading the upstream author's source code directly,
you have to personally assume the burden of verifying that the tarball
really is the author's work, and not that of (e.g.) a network intruder
who cracked the download ftp site substituted a trojaned version.
Although this concern applies mostly to software designed to run with
elevated privilege, it's not a strictly academic risk: Linux-relevant
codebases that have been (briefly) trojaned in this fashion, in recent
years, on the upstream author's download sites, include Wietse Venema's
TCP Wrappers (tcpd/libwrap), the util-linux package, sendmail, OpenSSH,
and the Linux kernel (CVS gateway's archive, only). Unless you are
prepared to meaningfully verify the author's cryptographic signature —
if any — on that tarball, you risk sabotaging your system's security.
(None of those upstream trojanings escaped into Linux distributions
because of distribution packager vigilance. Make sure you can be as good
a gatekeeper, or rely on those who already do the job well.)

All of the above are problems normally addressed (and the burden of
solving them, shouldered) by Linux distributions' package maintainers,
so that you won't have to. It's to your advantage to take advantage of
that effort, if feasible. The memory of when a thousand Linux sysadmins,
circa 1993, would need to do all of that work 999-times redundantly, is
still fresh to us old-timers: We call those the Bad Old Days, given that
today one expert package maintainer can instead do that task for a
thousand sysadmins. And yes, sometimes there's nothing like such a
package available, and you have no reasonable alternative but to grab
upstream source tarballs — but the disadvantages justify some pains to
search for suitable packages, instead.

Depending on your distribution, you may find that there are update
packages available directly from the distribution's package updating
utilities, or from ancillary, semi-official package archives (e.g., the
Fedora Extras and "dag" repositories for Fedora/RH and similar
distributions), or, failing that, third-party packages maintained by
reputable outside parties, e.g., some of the Debian-and-compatible
repositories registered at the apt-get.org and backports.org sites.
Although those are certainly not unfailingly better than tarballs, I
would say they're generally so.

The smaller, less popular, and less dependency-ridden a package is, the
more you might be tempted to use an upstream source tarball. For
example, I use locally compiled versions of the Leafnode pre-2.0 betas
to run my server's local NNTP newsgroups, because release-version
packages simply lack that functionality altogether. On the other hand,
that package's one dependency, the Perl PCRE library, I satisfy from my
distribution's official packages, for all the reasons stated above.