Hac Er | 9 Jun 11:19 2011
Picon

Corcern about sources' procedence

Hello.

I have discovered this piece of wisdom in the SlackBuilds site:

"If you don't trust us to check the scripts for malicious activity,
then please move along."

This has made me wonder how secure is in fact the SlackBuild software.
Sure, 99.9% of contributors are honorable people with pure motivations
who work to enchance the whole Slackware comunity, but Black Hats do
exist too out there.

The main reason I prefer compiling myself my software is because
unofficial binary packages can easily be troyanized or otherwise
infected by malware. By using build scrips, you can just get the source
code from the original author, then package it and install. However,
many appications cannot be obtained from the original author anymore.

Let's take Snort as an example. Snort upstream developers just provide
the latest version in their site. That means SlackBuilds.org cannot just
link to the original Snort x.y.z once Snort x.y.z+1 is released. This
forces the script mantainer (Niels Horn in this case) to make Snort
x.y.z availible from another location (www.nielshorn.net in this case)
and link to it from SlackBuild.org.

I trust SlackBuild's statement of them checking the scripts for evil
contents. In fact, many scripts are so simple that you can check them
quickly in a few minutes. However... what happens if Niels Horn is one
of those Black Hats who live in the shadows, slowly infecting computers
all around the world as part of his plan for conquering the Earth? What
(Continue reading)

Willy Sudiarto Raharjo | 9 Jun 11:36 2011
Picon

Re: Corcern about sources' procedence

> I trust SlackBuild's statement of them checking the scripts for evil
> contents. In fact, many scripts are so simple that you can check them
> quickly in a few minutes. However... what happens if Niels Horn is one
> of those Black Hats who live in the shadows, slowly infecting computers
> all around the world as part of his plan for conquering the Earth? What
> is preventing him from patching the original Snort x.y.z and turning it
> into a dangerous backdoor? If Snort x.y.z was in www.snort.org, you
> could easily check if Niel's version is the same, but you only will be
> able to check against x.y.z+1 version. You can still modify the build
> script and build the last version of Snort from the authors website,
> yes, but this would be no solution for Niel infecting thousands of
> computers.
>
> What procedure is taken in order to avoid this nightmare?
> Because, knowing SlackBuild.org has a very good reputation and its
> software works flawlessly most of the times, I asume you have some
> method to prevent Niel and his friends from taking over Slackware
> Universe.

That's why in SBo, they never give any source in the repository
you have to download the source by yourself

if you don't believe the script, you can check whether it tries to
patch or do something malicious and you can always edit the script
according to your senses.

In most cases, the script can be used to compile x.y+1, x.y+2, or even more
you only need to edit the VERSION line

--

-- 
(Continue reading)

Hac Er | 9 Jun 13:45 2011
Picon

Re: Corcern about sources' procedence

On Thu, 9 Jun 2011 16:36:00 +0700
Willy Sudiarto Raharjo <willysr@...> wrote:

> That's why in SBo, they never give any source in the repository
> you have to download the source by yourself
> 
> if you don't believe the script, you can check whether it tries to
> patch or do something malicious and you can always edit the script
> according to your senses.
> 
> In most cases, the script can be used to compile x.y+1, x.y+2, or
> even more you only need to edit the VERSION line
> 

I get your point. Anyways, even being true that you can track the source
by yourself, or modifiy the SlackBuild if necessary, the backgroud
question remains unanswered.

SlackBuilds.org does not host the sources itself, but provides links
to them. I wouldn't trust some of these links if I were given no
guarantee they are trustworthy. That's exactly what I am asking: How do
SBo administrators ensure they are linking to the right sources?

This is a non-trivial question. Experience shows that many sites who
trust their uploaders to play fair end up hosting some percentage of
malware. I myself use to track the original code to build my packages,
but look at this:

http://slackbuilds.org/repository/13.37/multimedia/HandBrake/

(Continue reading)

Willy Sudiarto Raharjo | 9 Jun 16:24 2011

Re: Corcern about sources' procedence

> I get your point. Anyways, even being true that you can track the source
> by yourself, or modifiy the SlackBuild if necessary, the backgroud
> question remains unanswered.
>
> SlackBuilds.org does not host the sources itself, but provides links
> to them. I wouldn't trust some of these links if I were given no
> guarantee they are trustworthy. That's exactly what I am asking: How do
> SBo administrators ensure they are linking to the right sources?

> The question remains: How do administrators decide if the links they
> post are trustworthy?

AFAIK, all admin (at least the one who commited the update and post it
on the list) tested all submissions before they agreed to approve it.
If it gets suspicious, i'm sure it won't pass their filter :)

--

-- 
Willy Sudiarto Raharjo
Personal Blog : http://willysr.blogspot.com
Linux Blog: http://slackblogs.blogspot.com
Bradley D. Thornton | 10 Jun 01:18 2011
Picon

Re: Corcern about sources' procedence


On 06/09/2011 04:45 AM, Hac Er wrote:

> 
> The question remains: How do administrators decide if the links they
> post are trustworthy?

Well, since you're asking, I might as well get all socratic on you too:

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

Oh, I'm sorry... That was a Rhetorical question wasn't it? (Answer:
YES). And about 10 messages back there's a link to Ken Thompson's
treatment of that same question.

The outcome of that treatment? You can't be certain at all unless you
wrote it yourself.

Let take a moment now to poke a couple of holes into the notions which
you infer *could* exist here.

First, when someone submits a SlackBuild, a member of the SBo team vets
it out. The checksum you see at SlackBuilds.org for any particular
source won't match what you download if something changes (up thar in
that cloud thingy). sbopkg does a bit of work for you toward that end
that I am certain many people just disregard performing manually
themselves, and at times, I've been in a rush to launch a new server and
have been guilty of it myself.

(Continue reading)

Hac Er | 10 Jun 09:13 2011
Picon

Re: Corcern about sources' procedence

> 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".

(Continue reading)

Al | 10 Jun 12:28 2011
Picon

Re: Corcern about sources' procedence

Not to offend.  But to have fun.  If you're serious, then stop reading 
now!!! (except for the command at #3 below **is an actual command**)

By reading any further you waive your rights to any and all seriousness.

Now I'm starting to worry about the amount of electricity consumption 
needed by all of the running boxes that I've deemed necessary just for 
me to remain secure (if y'all read that far along down below, that is)

<grin> 1. build only on a certain machine that this machine is at least 
somewhat if not more so quarantined/isolated.

<grin> I'm a good guy in a white hat.  And another or #2 part of my good 
guy bag of goodies is the "scan your lan" technique/tool/appoach (tta 
for short).

<grin>  2. scan your network regularly.  Scan it with Perl.  Scan it 
with Wireshark.  Also, scan it with the various other utilities as 
well.  Just scan that lan at all hours as well as at irregular hours.  
<grin> we're scan/watching for something new activity/protocol.  So, 
uniq and diff those results regularly too.  But, BTW, be sure to do so 
with an uncompromised uniq and diff.

<grin> To "scan your lan"  Use the various different security/forensic 
distros that exist on live cd.  Also, to do the scans: do so from an 
OpenBSD box and a NetBSD box and a FreeBSD  box and a Slackware box and 
a Debian box and a CentOS box and a RedHat box if you are able to afford 
that last one.

3.
(Continue reading)

markus reichelt | 10 Jun 15:27 2011

Re: Corcern about sources' procedence

* Al <acummingsus@...> wrote:

> By reading any further you waive your rights to any and all seriousness.

:-) This thread reminds me of a great quote:

"I refuse to tiptoe through life only to arrive safely at death."
 --Tony Campolo

-- 
left blank, right bald
* Al <acummingsus@...> wrote:

> By reading any further you waive your rights to any and all seriousness.

:-) This thread reminds me of a great quote:

"I refuse to tiptoe through life only to arrive safely at death."
 --Tony Campolo

--

-- 
left blank, right bald
Al | 10 Jun 12:42 2011
Picon

Re: Corcern about sources' procedence

find / -xdev -ctime -1

As root, redirect that command to a file before installing a package.

Correction:  "immediately after" installing a package, not before.

But, what's to say that a trojan couldn't alter a file time or time 
stamp (which, in turn, would render that find command useless)
Jens Weber - Tuxane.com | 10 Jun 17:05 2011

Re: Corcern about sources' procedence

Am 10.06.2011 01:18, schrieb Bradley D. Thornton:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>
> On 06/09/2011 04:45 AM, Hac Er wrote:
>
>> The question remains: How do administrators decide if the links they
>> post are trustworthy?
> Well, since you're asking, I might as well get all socratic on you too:
>
> "How do you know that the upstream, original author/maintainer of the
> software you want to run is trustworthy?
>
> Oh, I'm sorry... That was a Rhetorical question wasn't it? (Answer:
> YES). And about 10 messages back there's a link to Ken Thompson's
> treatment of that same question.
>
> The outcome of that treatment? You can't be certain at all unless you
> wrote it yourself.
>
> Let take a moment now to poke a couple of holes into the notions which
> you infer *could* exist here.
>
> First, when someone submits a SlackBuild, a member of the SBo team vets
> it out. The checksum you see at SlackBuilds.org for any particular
> source won't match what you download if something changes (up thar in
> that cloud thingy). sbopkg does a bit of work for you toward that end
> that I am certain many people just disregard performing manually
(Continue reading)

Niklas "Nille" Åkerström | 11 Jun 22:59 2011
Picon

Re: Corcern about sources' procedence

After reading some of this thread (it was a bit much to read all) i checked the example handbrake.
And i asked myself why doesn't handbrake use the original source mirrors and why doesn't the source have the same md5sum as the original.
I do maintain a52dec, faac, faad2 and  when i saw that the md5sum differ from the original i thought wtf?
Now if i do an diff it seems okey and doesn't differ except for a52dec that has the top folder named differently so i guess the sources are good.
But it still makes me wonder why does handbrake use an own mirror and why does the md5sum diff from the original.
We can't have different md5sum for the same source on SBo and we should use the official mirrors if possible.
And if some sources are stripped or patched i rather have the patches for each source and run them myself against the official source so i can keep up on whats happening.
So i really think that handbrake should be considered broken in it's current state due to link and md5sum mismatch.

That said i trust SBo and its maintainers and if you don't then don't use SBo.


<div><p>After reading some of this thread (it was a bit much to read all) i checked the example handbrake.<br>And i asked myself why doesn't handbrake use the original source mirrors and why doesn't the source have the same md5sum as the original.<br>
I do maintain a52dec, faac, faad2 and&nbsp; when i saw that the md5sum differ from the original i thought wtf?<br>Now if i do an diff it seems okey and doesn't differ except for a52dec that has the top folder named differently so i guess the sources are good.<br>
But it still makes me wonder why does handbrake use an own mirror and why does the md5sum diff from the original.<br>We can't have different md5sum for the same source on SBo and we should use the official mirrors if possible.<br>
And if some sources are stripped or patched i rather have the patches for each source and run them myself against the official source so i can keep up on whats happening.<br>So i really think that handbrake should be considered broken in it's current state due to link and md5sum mismatch.<br><br>That said i trust SBo and its maintainers and if you don't then don't use SBo.<br><br><br></p></div>
Heinz Wiesinger | 11 Jun 23:40 2011

Re: Corcern about sources' procedence

On Saturday 11 June 2011 22:59:47 Niklas "Nille" Åkerström wrote:

> We can't have different md5sum for the same source on SBo and we should use

> the official mirrors if possible.

Actually, it's the other way around. We support multiple md5sums per download link, but only one download link per md5sum. That is also why there are two links for handbrake that do not point to the handbrake server. The md5sums of those match links we already have in the system for the individual SlackBuilds of those. The download links of handbrake got adjusted to not cause conflicts between those scripts.

Grs,

Heinz

<div>
<p>On Saturday 11 June 2011 22:59:47 Niklas "Nille" &Aring;kerstr&ouml;m wrote:</p>
<p>&gt; We can't have different md5sum for the same source on SBo and we should use</p>
<p>&gt; the official mirrors if possible.</p>
<p></p>
<p>Actually, it's the other way around. We support multiple md5sums per download link, but only one download link per md5sum. That is also why there are two links for handbrake that do not point to the handbrake server. The md5sums of those match links we already have in the system for the individual SlackBuilds of those. The download links of handbrake got adjusted to not cause conflicts between those scripts.</p>
<p></p>
<p>Grs,</p>
<p>Heinz</p>
</div>
Niklas "Nille" Åkerström | 11 Jun 23:56 2011
Picon

Re: Corcern about sources' procedence

Well a source should only have one md5sum unless the change is done upstream and not released as an new version. (it happens but is totally wrong in my opinion)
Or how should anyone know if it's correct?
And the md5sum should match the official release.
Or do you think otherwise?
/Nille

2011/6/11 Heinz Wiesinger <pprkut-ko+OqhKiB2wsHrnhXWJB8w@public.gmane.org>

On Saturday 11 June 2011 22:59:47 Niklas "Nille" Åkerström wrote:

> We can't have different md5sum for the same source on SBo and we should use

> the official mirrors if possible.

Actually, it's the other way around. We support multiple md5sums per download link, but only one download link per md5sum. That is also why there arhttp://slackbuilds.org/gitweb/?p=slackbuilds.git;a=summare two links for handbrake that do not point to the handbrake server. The md5sums of those match links we already have in the system for the individual SlackBuilds of those. The download links of handbrake got adjusted to not cause conflicts between those scripts.

Grs,

Heinz


_______________________________________________
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/



<div>
<p>Well a source should only have one md5sum unless the change is done upstream and not released as an new version. (it happens but is totally wrong in my opinion)<br>Or how should anyone know if it's correct?<br>And the md5sum should match the official release.<br>
Or do you think otherwise?<br>/Nille<br><br></p>
<div class="gmail_quote">2011/6/11 Heinz Wiesinger <span dir="ltr">&lt;<a href="mailto:pprkut <at> slackbuilds.org">pprkut@...</a>&gt;</span><br><blockquote class="gmail_quote">

<div>
<div class="im">
<p>On Saturday 11 June 2011 22:59:47 Niklas "Nille" &Aring;kerstr&ouml;m wrote:</p>
<p>&gt; We can't have different md5sum for the same source on SBo and we should use</p>
<p>&gt; the official mirrors if possible.</p>
<p></p>
</div>
<p>Actually, it's the other way around. We support multiple md5sums per download link, but only one download link per md5sum. That is also why there arhttp://<a href="http://slackbuilds.org/gitweb/?p=slackbuilds.git;a=summare">slackbuilds.org/gitweb/?p=slackbuilds.git;a=summare</a> two links for handbrake that do not point to the handbrake server. The md5sums of those match links we already have in the system for the individual SlackBuilds of those. The download links of handbrake got adjusted to not cause conflicts between those scripts.</p>

<p></p>
<p>Grs,</p>
<p>Heinz</p>
</div>
<br>_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br><br>
</blockquote>
</div>
<br>
</div>
Niklas "Nille" Åkerström | 12 Jun 00:03 2011
Picon

Re: Corcern about sources' procedence

Sorry for the link that not supposed to be there.
New toshiba laptop that i'm not used to so it got it to paste something where i didn't want it.
I need to make it turn off tuchpad while i write.
Or better sell the crap and get an new thinkpad.
/Nille

<div><p>Sorry for the link that not supposed to be there.<br>New toshiba laptop that i'm not used to so it got it to paste something where i didn't want it.<br>I need to make it turn off tuchpad while i write.<br>Or better sell the crap and get an new thinkpad.<br>
/Nille<br></p></div>
Niklas "Nille" Åkerström | 12 Jun 00:49 2011
Picon

Re: Corcern about sources' procedence

I feel stupid when i see that there's tar.bz2 and tar.gz
So faad2 and faac are fine.
a52dec is still wrong and no official release.

Sorry for my mistake.
/Nille

<div><p>I feel stupid when i see that there's tar.bz2 and tar.gz<br>So faad2 and faac are fine.<br>a52dec is still wrong and no official release.<br><br>Sorry for my mistake.<br>/Nille<br><br></p></div>
Rob McGee | 9 Jun 13:00 2011

Re: Corcern about sources' procedence

On Thu, Jun 09, 2011 at 11:19:25AM +0200, Hac Er wrote:
> I have discovered this piece of wisdom in the SlackBuilds site:
> 
> "If you don't trust us to check the scripts for malicious
> activity, then please move along."

Wise words indeed.

> I trust SlackBuild's statement of them checking the scripts for 
> evil contents. In fact, many scripts are so simple that you can 
> check them quickly in a few minutes. However... what happens if 
> Niels Horn is one of those Black Hats who live in the shadows, 
> slowly infecting computers all around the world as part of his
> plan for conquering the Earth?

It's not Niels. It's Michiel. We have suspected it all along, and 
have known it for quite some time. I'm afraid is is too late now. 
Relax and cooperate with him; he might not hurt you.
--

-- 
    Rob McGee - /dev/rob0 - rob0@...
Niels Horn | 9 Jun 13:04 2011
Picon

Re: Corcern about sources' procedence

On Thu, Jun 9, 2011 at 8:00 AM, Rob McGee <rob0@...> wrote:
> On Thu, Jun 09, 2011 at 11:19:25AM +0200, Hac Er wrote:
>> I have discovered this piece of wisdom in the SlackBuilds site:
>>
>> "If you don't trust us to check the scripts for malicious
>> activity, then please move along."
>
> Wise words indeed.
>
>> I trust SlackBuild's statement of them checking the scripts for
>> evil contents. In fact, many scripts are so simple that you can
>> check them quickly in a few minutes. However... what happens if
>> Niels Horn is one of those Black Hats who live in the shadows,
>> slowly infecting computers all around the world as part of his
>> plan for conquering the Earth?
>
> It's not Niels. It's Michiel. We have suspected it all along, and
> have known it for quite some time. I'm afraid is is too late now.
> Relax and cooperate with him; he might not hurt you.
> --
>    Rob McGee - /dev/rob0 - rob0@...
> _______________________________________________

To all:

Please check my picture on my site: http://www.nielshorn.net/other/personal.php
That's a *brown* hat, not a black hat!

--
Niels Horn
David Woodfall | 9 Jun 13:20 2011
Picon

Re: Corcern about sources' procedence

On (08:04 09/06/11), Niels Horn <niels.horn <at> gmail.com> put forth the proposition:
>On Thu, Jun 9, 2011 at 8:00 AM, Rob McGee <rob0 <at> slackbuilds.org> wrote:
>> On Thu, Jun 09, 2011 at 11:19:25AM +0200, Hac Er wrote:
>>> I have discovered this piece of wisdom in the SlackBuilds site:
>>>
>>> "If you don't trust us to check the scripts for malicious
>>> activity, then please move along."
>>
>> Wise words indeed.
>>
>>> I trust SlackBuild's statement of them checking the scripts for
>>> evil contents. In fact, many scripts are so simple that you can
>>> check them quickly in a few minutes. However... what happens if
>>> Niels Horn is one of those Black Hats who live in the shadows,
>>> slowly infecting computers all around the world as part of his
>>> plan for conquering the Earth?
>>
>> It's not Niels. It's Michiel. We have suspected it all along, and
>> have known it for quite some time. I'm afraid is is too late now.
>> Relax and cooperate with him; he might not hurt you.
>> --
>>    Rob McGee - /dev/rob0 - rob0 <at> slackbuilds.org
>> _______________________________________________
>
>To all:
>
>Please check my picture on my site: http://www.nielshorn.net/other/personal.php
>That's a *brown* hat, not a black hat!
>
>--
>Niels Horn

I understand the OP's point, but then someone could hack the server of
whoever provides the source and we have the same problem. I doubt
there is any realistic way of checking source, apart being vigilant
and watchful when using software.

Nice hat by the way Niels ;)

D.
_______________________________________________
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/

Hac Er | 9 Jun 13:59 2011
Picon

Re: Corcern about sources' procedence

On Thu, 9 Jun 2011 12:20:32 +0100
David Woodfall <dave@...> wrote:

> 
> I understand the OP's point, but then someone could hack the server of
> whoever provides the source and we have the same problem. I doubt
> there is any realistic way of checking source, apart being vigilant
> and watchful when using software.
> 
> Nice hat by the way Niels ;)
> 
> D.

I know.

However, many do provide means to test if what you are downloading is
what you want to download. They could crack www.snort.org and hang
there a evil copy of Snort, with a fake signature and a fake GPG key,
but if they did, anyone who had downloaded the GPG key a week before
would know there is something wrong when checked "snort latest version"
and found the signatures mismatch.

The only way you can ensure no one is gonna break into your computer is
trashing away your machines and rejecting every shape of I.T. from your
live. For those who don't want to apply so extreme measures, there is
prudence.
Bradley D. Thornton | 9 Jun 13:40 2011
Picon

Re: Corcern about sources' procedence


On 06/09/2011 04:04 AM, Niels Horn wrote:
> On Thu, Jun 9, 2011 at 8:00 AM, Rob McGee <rob0@...> wrote:
>> On Thu, Jun 09, 2011 at 11:19:25AM +0200, Hac Er wrote:
>>> I have discovered this piece of wisdom in the SlackBuilds site:
>>>
>>> "If you don't trust us to check the scripts for malicious
>>> activity, then please move along."
>>
>> Wise words indeed.
>>
>>> I trust SlackBuild's statement of them checking the scripts for
>>> evil contents. In fact, many scripts are so simple that you can
>>> check them quickly in a few minutes. However... what happens if
>>> Niels Horn is one of those Black Hats who live in the shadows,
>>> slowly infecting computers all around the world as part of his
>>> plan for conquering the Earth?
>>
>> It's not Niels. It's Michiel. We have suspected it all along, and
>> have known it for quite some time. I'm afraid is is too late now.
>> Relax and cooperate with him; he might not hurt you.
>> --
>>    Rob McGee - /dev/rob0 - rob0@...
>> _______________________________________________
> 
> To all:
> 
> Please check my picture on my site: http://www.nielshorn.net/other/personal.php
> That's a *brown* hat, not a black hat!
> 
> --
> Niels Horn

I don't think a black hat would have bothered me as much as a *red* one
Niels ;)

--

-- 
Bradley D. Thornton
Manager Network Services
NorthTech Computer
TEL: +1.760.666.2703  (US)
TEL: +44.203.318.2755 (UK)
http://NorthTech.US

Niels Horn | 9 Jun 16:43 2011
Picon

Re: Corcern about sources' procedence

On Thu, Jun 9, 2011 at 8:40 AM, Bradley D. Thornton
<Bradley@...> wrote:
>
> I don't think a black hat would have bothered me as much as a *red* one
> Niels ;)
>

Red Hat? No I'd never use such a thing... :-)

--
Niels
Klaatu | 9 Jun 17:11 2011

Re: Corcern about sources' procedence

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

On Thursday, June 09, 2011 10:43:27 am Niels Horn wrote:
> On Thu, Jun 9, 2011 at 8:40 AM, Bradley D. Thornton
> 
> <Bradley@...> wrote:
> > I don't think a black hat would have bothered me as much as a *red* one
> > Niels ;)
> 
> Red Hat? No I'd never use such a thing... :-)
> 
> --
> Niels
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users@...
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
Hac Er | 9 Jun 18:01 2011
Picon

Re: Corcern about sources' procedence

On Thu, 9 Jun 2011 11:11:08 -0400
Klaatu <notklaatu@...> 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!
chris.abela | 9 Jun 18:21 2011

Re: Corcern about sources' procedence

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@...>
Sender: slackbuilds-users-bounces@...: Thu, 9
Jun 2011 18:01:04 
To: <slackbuilds-users@...>
Reply-To: "SlackBuilds.org Users List" <slackbuilds-users@...>
Subject: Re: [Slackbuilds-users] Corcern about sources' procedence

On Thu, 9 Jun 2011 11:11:08 -0400
Klaatu <notklaatu@...> 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@...
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

gmartin | 9 Jun 18:02 2011

Re: Corcern about sources' procedence



On Thu, Jun 9, 2011 at 11:11 AM, Klaatu <notklaatu-zuxtXHtp7yRFbkejpFhFiEM9+F4ksjoh@public.gmane.org> 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
To me this comes down to reputation within the community.  I don't know anyone involved in the snort project and have no reason to trust their code except that it is public and open and hopefully there are eyes looking for such things.  But in the end is is a large, faceless community - to me.
Enter Niels (thanks, btw, for lending us your reputation for this discussion).  He is part of a much smaller and more well known to me group - the slackbuild contributers.  While I know the slackbuild admins are only reviewing the script, and not Niels copy of of version x.y.z, he has, nevertheless, developed a large positive personal reputation in the community.  He could choose to burn that trust and we likely would not discover it right away.  But the fact that he has earned his reputation over time is an indicator that he is less likely to harm in the future.
For me, it is easier to trust Niels then Snort due to the size of ther SB community and my closer connection to it.
Perhaps the thing for you to do is spot check his (and others') tar ball against the site's published signature (assuming it is available) for that version.  This would give both trust AND verify .

\\Greg
 
<div>
<div>
<br><br>
</div>
<div class="gmail_quote">On Thu, Jun 9, 2011 at 11:11 AM, Klaatu <span dir="ltr">&lt;<a href="mailto:notklaatu <at> straightedgelinux.com">notklaatu@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

There's no need to follow links from SlackBuilds.org for anything more than<br>
the SlackBuild itself, which you can audit and verify manually. &nbsp;Proceed to<br>
your trusted site for the source code, grab the source, edit the SlackBuild<br>
script as needed, and build.<br><br>
I guess the larger issue, really, as Ben I think is saying, how do you know<br>
ANY source code you download is trustworthy? &nbsp;As Ken Thompson says in Ben's<br>
link (great article, btw, thanks for the link Ben) &nbsp;"The moral is obvious. You<br>
can't trust code that you did not totally create yourself."<br><br>
-- klaatu<br><div><div></div></div>
</blockquote>
<div>
<div>To me this comes down to reputation within the community.&nbsp; I don't know anyone involved in the snort project and have no reason to trust their code except that it is public and open and hopefully there are eyes looking for such things.&nbsp; But in the end is is a large, faceless community - to me.</div>

<div> </div>
<div>Enter Niels (thanks, btw, for lending us your reputation for this discussion).&nbsp; He is part of a much smaller and more well known to me group - the slackbuild contributers.&nbsp; While I know the slackbuild admins are only reviewing the script, and not Niels copy of&nbsp;of version x.y.z, he has, nevertheless, developed a large positive personal reputation in the community.&nbsp; He could choose to burn that trust and we likely would not discover it right away.&nbsp; But the fact that he has earned&nbsp;his reputation&nbsp;over time is an indicator that he is less likely to&nbsp;harm in the future.</div>

<div> </div>
<div>For me, it is easier to trust Niels then Snort due to the size of ther SB community and my closer connection to it.<br clear="all">
</div>
<div>Perhaps the thing for you to do is spot check his (and others') tar ball against the site's published signature (assuming it is available) for that version.&nbsp; This would give both trust AND verify .</div>

<div>
<br>\\Greg<br>&nbsp;</div>
</div>
</div>
</div>
Eric Hameleers (SBo | 9 Jun 19:09 2011

Re: Corcern about sources' procedence

Op 9-6-2011 18:02, gmartin schreef:

> Enter Niels (thanks, btw, for lending us your reputation for this
> discussion).  He is part of a much smaller and more well known to me
> group - the slackbuild contributers.

Niels is one of the admins of slackbuilds.org.

If you do not trust his contributions, then there is the door ------->

Eric
gmartin | 9 Jun 19:26 2011

Re: Corcern about sources' procedence



\\Greg



On Thu, Jun 9, 2011 at 1:09 PM, Eric Hameleers (SBo) <alien-ko+OqhKiB2wsHrnhXWJB8w@public.gmane.org> wrote:
Op 9-6-2011 18:02, gmartin schreef:

> Enter Niels (thanks, btw, for lending us your reputation for this
> discussion).  He is part of a much smaller and more well known to me
> group - the slackbuild contributers.

Niels is one of the admins of slackbuilds.org.

If you do not trust his contributions, then there is the door ------->

Eric

 
I do trust him.  I hope nothing I said implied anyting else. 
<div>
<br clear="all"><br>\\Greg<br><br><br><br><div class="gmail_quote">On Thu, Jun 9, 2011 at 1:09 PM, Eric Hameleers (SBo) <span dir="ltr">&lt;<a href="mailto:alien@...">alien@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

Op 9-6-2011 18:02, gmartin schreef:<br><div class="im">
<br>
&gt; Enter Niels (thanks, btw, for lending us your reputation for this<br>
&gt; discussion). &nbsp;He is part of a much smaller and more well known to me<br>
&gt; group - the slackbuild contributers.<br><br>
</div>Niels is one of the admins of <a href="http://slackbuilds.org" target="_blank">slackbuilds.org</a>.<br><br>
If you do not trust his contributions, then there is the door -------&gt;<br><br>
Eric<br><div>
<br>&nbsp;</div>
</blockquote>
<div>I do trust him.&nbsp; I hope nothing I said implied anyting else.&nbsp;</div>
</div>
</div>
Hac Er | 9 Jun 19:47 2011
Picon

Re: Corcern about sources' procedence

Eric Hameleers wrote:

> Niels is one of the admins of slackbuilds.org.
> 
> If you do not trust his contributions, then there is the door ------->

I think this is another version of a piece of wisdom I have already
mentioned...

It seems I did choose a bad example with Snort and Neils. Sorry if
someone got offended.

By the way, Eric, thanks for your multilib and LibreOffice packages.

Chris wrote:

>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.

Not everybody can afford an auditor, but surely many hate the
idea of their computers turned into spam-sender-zombie-robots. No
matter your objetives or circunstances, the less risks you take, the
better.

Greg wrote:

>While I know the slackbuild admins are only
>reviewing the script, and not Niels copy of of version x.y.z, he has,
>nevertheless, developed a large positive personal reputation in the
>community.

That's what I wanted to know.

I'm not attacking Neils, nor anyone. I was just asking how does
SlackBuild care of a potential security issue. A threat is less
dangerous when you know its existence. Many web sites (mainly aidmed as
MS Windows users) which provide software for free do contain malware
just because nobody checks the software that is posted in them. 

In SlackBuilds you can mitigate the risks by tracking down the original
source or by following only the links provided by reputable people who
is not trashing away its reputation so easily.

That is enough for me.

Cheers.
Ben Mendis | 9 Jun 14:20 2011
Picon

Re: Corcern about sources' procedence

I'm sorry, but this is really nothing new.


More wisdom from the ancients: http://cm.bell-labs.com/who/ken/trust.html


On Thu, Jun 9, 2011 at 5:19 AM, Hac Er <spamered-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:
Hello.

I have discovered this piece of wisdom in the SlackBuilds site:

"If you don't trust us to check the scripts for malicious activity,
then please move along."

This has made me wonder how secure is in fact the SlackBuild software.
Sure, 99.9% of contributors are honorable people with pure motivations
who work to enchance the whole Slackware comunity, but Black Hats do
exist too out there.

The main reason I prefer compiling myself my software is because
unofficial binary packages can easily be troyanized or otherwise
infected by malware. By using build scrips, you can just get the source
code from the original author, then package it and install. However,
many appications cannot be obtained from the original author anymore.

Let's take Snort as an example. Snort upstream developers just provide
the latest version in their site. That means SlackBuilds.org cannot just
link to the original Snort x.y.z once Snort x.y.z+1 is released. This
forces the script mantainer (Niels Horn in this case) to make Snort
x.y.z availible from another location (www.nielshorn.net in this case)
and link to it from SlackBuild.org.

I trust SlackBuild's statement of them checking the scripts for evil
contents. In fact, many scripts are so simple that you can check them
quickly in a few minutes. However... what happens if Niels Horn is one
of those Black Hats who live in the shadows, slowly infecting computers
all around the world as part of his plan for conquering the Earth? What
is preventing him from patching the original Snort x.y.z and turning it
into a dangerous backdoor? If Snort x.y.z was in www.snort.org, you
could easily check if Niel's version is the same, but you only will be
able to check against x.y.z+1 version. You can still modify the build
script and build the last version of Snort from the authors website,
yes, but this would be no solution for Niel infecting thousands of
computers.

What procedure is taken in order to avoid this nightmare?
Because, knowing SlackBuild.org has a very good reputation and its
software works flawlessly most of the times, I asume you have some
method to prevent Niel and his friends from taking over Slackware
Universe.

Niel, if you are reading this, sorry for being the bad guy of the
story. I needed an example, and Snort was the first that came to my
mind :-)

_______________________________________________
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/


<div>
<p>I'm sorry, but this is really nothing new.</p>
<div><br></div>
<div>More wisdom from the ancients:&nbsp;<a href="http://cm.bell-labs.com/who/ken/trust.html">http://cm.bell-labs.com/who/ken/trust.html</a><br>
</div>
<div><br></div>
<div>
<br><div class="gmail_quote">On Thu, Jun 9, 2011 at 5:19 AM, Hac Er <span dir="ltr">&lt;<a href="mailto:spamered <at> hotmail.com">spamered@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
Hello.<br><br>
I have discovered this piece of wisdom in the SlackBuilds site:<br><br>
"If you don't trust us to check the scripts for malicious activity,<br>
then please move along."<br><br>
This has made me wonder how secure is in fact the SlackBuild software.<br>
Sure, 99.9% of contributors are honorable people with pure motivations<br>
who work to enchance the whole Slackware comunity, but Black Hats do<br>
exist too out there.<br><br>
The main reason I prefer compiling myself my software is because<br>
unofficial binary packages can easily be troyanized or otherwise<br>
infected by malware. By using build scrips, you can just get the source<br>
code from the original author, then package it and install. However,<br>
many appications cannot be obtained from the original author anymore.<br><br>
Let's take Snort as an example. Snort upstream developers just provide<br>
the latest version in their site. That means SlackBuilds.org cannot just<br>
link to the original Snort x.y.z once Snort x.y.z+1 is released. This<br>
forces the script mantainer (Niels Horn in this case) to make Snort<br>
x.y.z availible from another location (<a href="http://www.nielshorn.net" target="_blank">www.nielshorn.net</a> in this case)<br>
and link to it from SlackBuild.org.<br><br>
I trust SlackBuild's statement of them checking the scripts for evil<br>
contents. In fact, many scripts are so simple that you can check them<br>
quickly in a few minutes. However... what happens if Niels Horn is one<br>
of those Black Hats who live in the shadows, slowly infecting computers<br>
all around the world as part of his plan for conquering the Earth? What<br>
is preventing him from patching the original Snort x.y.z and turning it<br>
into a dangerous backdoor? If Snort x.y.z was in <a href="http://www.snort.org" target="_blank">www.snort.org</a>, you<br>
could easily check if Niel's version is the same, but you only will be<br>
able to check against x.y.z+1 version. You can still modify the build<br>
script and build the last version of Snort from the authors website,<br>
yes, but this would be no solution for Niel infecting thousands of<br>
computers.<br><br>
What procedure is taken in order to avoid this nightmare?<br>
Because, knowing SlackBuild.org has a very good reputation and its<br>
software works flawlessly most of the times, I asume you have some<br>
method to prevent Niel and his friends from taking over Slackware<br>
Universe.<br><br>
Niel, if you are reading this, sorry for being the bad guy of the<br>
story. I needed an example, and Snort was the first that came to my<br>
mind :-)<br><br>
_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
Chris ABELA | 9 Jun 16:25 2011

Re: Corcern about sources' procedence


What procedure is taken in order to avoid this nightmare?
Because, knowing SlackBuild.org has a very good reputation and its
software works flawlessly most of the times, I asume you have some
method to prevent Niel and his friends from taking over Slackware
Universe.  

From: slackbuilds-users-bounces@...
[mailto:slackbuilds-users-bounces@...] On Behalf Of Hac Er
Sent: 09 June 2011 11:19
To: slackbuilds-users@...
Subject: [Slackbuilds-users] Corcern about sources' precedence

My advise is the following:

1. If you can, audit the source code.
2. If you have a liability, prepare your Case (see 1).
3. If you cannot audit the code, then don't worry, because it is useless to
worry.

This holds for wherever the codes originates. As far as I know, the only
source code that comes with an audit report is xinetd-2.3.0.

Chris

King Beowulf | 10 Jun 02:10 2011
Picon

Re: Corcern about sources' procedence

On 06/09/2011 02:19 AM, Hac Er wrote:
> --------snip---------
> This has made me wonder how secure is in fact the SlackBuild software.
> Sure, 99.9% of contributors are honorable people with pure motivations
> who work to enchance the whole Slackware comunity, but Black Hats do
> exist too out there.
>
> ------------snip--------

There is no life without some risk.  As individuals we each have a 
personal responsibility for our own safety.  One can hide under a rock 
in fear, or, one can pay attention to what one is doing, be smart about 
it, and try to minimize the risk.

A 99.9% confidence limit is plenty good enough for me as I am quite 
capable of watching out for the 0.1% of black hats.

That does not mean I will sift through thousands of lines of code (can I 
trust PV?) but rather be part of the Slackware community.  This 
community is quite capable of weeding out the less desirable elements.

So how exactly would you expect a "black hat" to infiltrate 
Slackware.com, Slackbuilds.org, linuxquestions.org, etc., and not be 
noticed fairly quickly?

Gmane