[Slackbuilds-users] Corcern about sources' procedence

[chris.abela at maltats.com]

I consider this from the point of liability.

If you can employ an auditor to mitigate your liability, then just do it.

If you do not have any liabilities then you have no problems.

If you have liability and you do not afford an auditor then you are in the wrong business.

Chris
Powered by BlackBerry® from Vodafone

-----Original Message-----
From: Hac Er <spamered at hotmail.com>
Sender: slackbuilds-users-bounces at slackbuilds.orgDate: Thu, 9 Jun 2011 18:01:04 
To: <slackbuilds-users at slackbuilds.org>
Reply-To: "SlackBuilds.org Users List" <slackbuilds-users at slackbuilds.org>
Subject: Re: [Slackbuilds-users] Corcern about sources' procedence

On Thu, 9 Jun 2011 11:11:08 -0400
Klaatu <notklaatu at straightedgelinux.com> wrote:
> There's no need to follow links from SlackBuilds.org for anything
> more than the SlackBuild itself, which you can audit and verify
> manually.  Proceed to your trusted site for the source code, grab the
> source, edit the SlackBuild script as needed, and build. 
> 
> I guess the larger issue, really, as Ben I think is saying, how do
> you know ANY source code you download is trustworthy?  As Ken
> Thompson says in Ben's link (great article, btw, thanks for the link
> Ben)  "The moral is obvious. You can't trust code that you did not
> totally create yourself."
> 
> -- klaatu

Hello, klaatu.

I know you don't need to follow links fron SlackBuilds, but I think
most people will follow them. After all, the links are there for
convenience, aren't them? That's why I think it is important to have
some control over them.

Regarding the trustworthy of upstream software, I must say I largely
agree with Ken Thomsom. If you want something even more paranoid, you
have to look wipe's man page to discover how goverments can take over
your hard drives implementing hiden backdoors in the hardware itself.
Anyway, you cannot even trust your own software: shall your compiler be
compromised, you are in trouble.

When you download upstream software, you do it thinking upstream
developer is a nice person, that is, you are trusting one man. When you
download a binary package, you do it thinking that both the developer
and the packager are good guys. That is, you are trusting two men. This
is pure theory of machine survival: the more components you include in
the mechanism, the higher the likeness of any of them failing. Using
upstream software is not risk free, but is less risky than using
packages or uncontrolled builds.

Auditing the code, as Chris suggests, seems nice until you realize
your window manager is twelve thousand lines of code long. Many times 
you have to deal with binary stuff for which the source is unaccesible.
The kernel itself is damn long and includes lots of blobs (unless you
take them out, of course). Most important, the average user does not
know a word of code. I know one or two only :-)

Budda says: "If you cannot fix it, don't worry, because it is useless".
I am not worrying about upstream code. I am worrying about the people
between upstream and the users.

P.D: klatuu, your HandBrake build works nice in my computer. Very kind
of you to gather all those packages!
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users at slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/