[Slackbuilds-users] Corcern about sources' procedence

Hac Er spamered at hotmail.com
Fri Jun 10 07:13:53 UTC 2011


> Third, at some point you're going to have to go to the grocery store.
> I know you wouldn't trust getting there in a Ford Pinto with Firestone
> 500's, but even if you walked, there are one legged crack mamas
> waiting to stab you in the heart for another 20 dollar rock.

You cannot live risk free, but you can mitigate the risks. If you are
concerned of somebody wanting to stab you, carry a short cannon gun
with you. Maybe it is not a 100% efective protection, but it is surely
harder to stab someone when your brains are spreaded on the floor.

> "How do you know that the upstream, original author/maintainer of the
> software you want to run is trustworthy?

No way you can be certain about this, but please remember the theory of
machine survival I have already explained. If you download Warmux from
www.warmux.org, you are depending on them to be as kind as they claim
to be. If you download it from a packager or third party link, you are
introducing another potential point of failure in the chaim.

> sixth, I would be much more concerned with the sofware management
> systems of "Other distros" besides Slackware

I wouldn't be much more concerned with the software management systems
of "Other distros" I do not use. Debian's security documentation even
warns the user with this alarming text:

"As a matter of fact, a Debian developer could distribute a Trojan in
a package, and there is no possible way to check it out.[...]That is
why Debian has a "no guarantees" license clause".

No good for peace of mind, but kind of them to warn us.

> Fourth, There is indeed software that I don't personally trust. I
> don't trust selinux, or anything from those bozos; I don't trust
> Canonical, or Microsoft, or Skype, or yahoo, or Oracle, or many many
> others either

Good you do not trust them. Can anyone realy think SElinux is not
plaged with backdoors from the NSA? :-)

> Fifth, it simply isn't the job of an SBo maintainer, or
> SlackBuilds.org, to audit upstream software 

Nor I have said it should be, but ensuring the software posted in the
page is in fact the unmodified upstream software could be desirable
(although is not needed, it would do no harm). Refer to theory of
machine survival.

> Second, There really isn't anything to trust here, and the site pretty
> much says so too. you get a very small script, which is overwhelmingly
> just a boilerplate. So if an SBo maintainer were to do anything
> funky...

I had already reached that conclusion. The SlackBuild comunity talking
openly about this issue tells wonders about its honorability. 


More information about the SlackBuilds-users mailing list