Thomas Delrue on 1 Jun 2015 08:15:54 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] SourceForge has Malware?

Hash: SHA512

*puts on tinfoil hat*

Do you look at the source before you compile it? What if the code you
get is not the code you think you got? Did you validate the sig of the
code; GPG or MD5 or whatever?
And even upon that: do you trust your compiler? (For you yung'ens, I'm
referring to the "Thompson Hack" - see

I'm not trying to be facetious here but just pointing out that 'just
compiling the code' isn't necessarily better unless you inspect what you
compile and compile it with a trusted compiler. It may give you
an unwarranted and false sense of security. What if during the time that
SF took over the account, they injected the code with the
crapware-delivery as well?

Broadening this even further (and putting on my secondary tinfoil hat):
with everyone dumping their code on GitHub instead of hosting it on
their own server; what if GitHub suddenly goes rogue? How do you know
that the code you see on GitHub the 'real code'?
There was an interesting article on yesterday that
brushed on this talking about how everyone is raving about distributed
SCCSs and then puts all their code on a single centralized GitHub: (note: I am not
advocating for or against the 'decentralized GitHub')

*takes off tinfoil hat(s)*

By compiling the code, you are however reducing the chances that you'll
get crapware like what SourceForge is delivering because injection of
those things are likely to be detected before they can become a real
issue. More subtle and 'tailored' hacks may not be so easy to detect and
be inserted over long or longer periods of time.

*now /really/ takes off the tinfoil hat*

I realize that at this point I'm not offering solutions and am just
pointing at problems but at least it gets me to start /thinking/ about

I'm a heavy Mercurial user which has a 'sign' feature: you can
crypto-sign a commit - and therefore it plus all of it's ancestors - I
think this enables a higher level of trustworthiness. This feature is
used in the mercurial source code itself.
While it does put the onus on the user to perform the validation, it is
things like that may increase trustworthiness in source-based software

I don't know if git (what all the 'cool' kids are using these days) has
a similar feature. I'd be surprised if it doesn't but am looking at this
community to inform me.
If git has this feature, how extensively is it used for mainstream
projects (I haven't seen anything like this in for instance the Linux
Kernel repo) ?

On a different note: it looks like anything that gets taken over by Dice
(SlashDot, SourceForge) gets corrupted and becomes something to be
avoided. But that's just my opinion...

On 06/01/2015 10:21 AM, Keith C. Perry wrote:
> This is why I compile as much as possible and get the source to 
> compile from the writer's website.
> Still, someone at sourceforge / dice needs to be fired for this 
> implementing this practice.  Distributing binaries implies a level
> of trust that doesn't have to be earned so when it gone, its done.
> --- KP-
> On Jun 1, 2015 03:00, Rachel Rawlings <> wrote:
>> Soutceforge has begun bundling extra software in their installers. 
>> These are programs they're psid to include as/like advertising, and
>> there's no opt-out (othrr than downloading the, you know, source).
>> Some of the bundled software has included malwsre and annoyware. 
>> This practice actually started in 2013 after they were acquired by 
>>, and you can read a hellacious saga in the filezilla 
>> community fora.
>> It recently became a scandal again after sf spent a week bundling
>> a search hijacker called Binkiland. 
Sourceforge has indeed joined the dark side.
>> On May 31, 2015 9:33 PM, "Anthony Martin" 
>> <> wrote:
>>> Just wondering if anyone knows if theres truth to this or not? 
>>> (sorry if this is old news) 
Version: GnuPG v2.0.22 (GNU/Linux)

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --