Re: [PLUG] SourceForge has Malware?

I have a point every now and again. Sometimes even on a Monday :)

Responses below as well...

(in blue)

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Keith C. Perry, MS E.E.

Owner, DAO Technologies LLC

(O) +1.215.525.4165 x2033

(M) +1.215.432.5167

www.daotechnologies.com

From: "Thomas Delrue" <delrue.thomas@gmail.com>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Monday, June 1, 2015 12:32:53 PM
Subject: Re: [PLUG] SourceForge has Malware?

You make good points :)
See inline

On 06/01/2015 12:19 PM, Keith C. Perry wrote:

That's not a tin foil hat argument at all. However, this idea that
"signing code" makes things so much better is false too...

Do you trust the keys on the writer's website? Do you trust the keys
on an 3rd party repositories?

The answer to both questions /should/ be "no". If not, then people
are letting down their guard. The ONLY person you /can/ implicitly
trust is yourself.

(note the use of "can" instead of "should" there )

In principle I agree, and this bring us to the Web Of Trust which is
imperative for these things. It is true that I can only trust myself
fully. But in real life and for practical reasons, I also trust my wife,
I trust my friends, I trust others around me that I know personally.
Some of them I trust for subject A, others I don't but I would defer to
them for subject B. That's how the real world works.

Very true. I don't trust everyone for everything.

I'm (indeed) not going to trust just any sig/pubkey file I find on a
website, but I may reach out and get a sig/pubkey of the signer which in
turn is signed by people *I* trust.
That isn't going to protect me 100%, you are right, because one of these
people I know may turn out to be untrustworthy. But I would argue that
it *does* increase my overall level of protection. Bringing it back to a
practical and conrete/real level: my friend could be sleeping with my wife.

Yes and I agree with that because as I say below its gets you closer to having 3rd party remediation. I just wanted to stress that that is not infallible.

I'll cede to you that getting into a WOT is indeed the hard part we are
still lacking critical mass around things like GPG to make these things
easier.

Speaking of which, when is the next PLUG key signing/exchange party?

You got me. That's not something I would participate in. I didn't know that was a thing LOL

That's the "trivial solution" of course. None of us are going to
write every piece of code we use. Years ago I used to look at
certain parts of the code I would download before compiling but I
don't have that level of time anymore. Unless its something
completely need to me, I initially trust the developer and then
verify operation in a more indirect fashion. Most malicious
operations are going to be caught like any other bug. If I see
something I don't like then I'll dig or send a message to the dev.
The "trust-but-verify" mindset is as good as it gets for humans.
Repositories can provide remediation points- companies like Verisign
do for PKI (i.e. SSL certificate signers) but that doesn't make them
infallible. It is possible for people hosting code on their own
website to improve their code signing by making it a qualified
process. Without getting into too much of a technical discussion the
heart of the matter, as I see it, is two fold.

1) using static file signatures. Hashing algorithms like MD5, SHA1,
SHA2 can only ever provide a fingerprint. 2) the proper way to sign
a document is to use a MAC. If you go with the FIPS standards then
using the approved HMAC algorithm can get you then but you have to
use it the algorithms ability to provide authenticity in relevant
and efficient way. That's where the challenge is but there are lots
of ways to do this, including generating the authenticate at the time
of download.

MAC as in https://en.wikipedia.org/wiki/Message_authentication_code?

Yes, if you want to dig more check out http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf

We have Perl modules for this as I'm sure other languages do at this point so it pretty easy to build out a signing process.

I've written software for my clients to provide the basis for this
process and its really not that hard to do. I use it myself when I
produce certain type of writings. More importantly, if the
authentication is generated on the fly, it can't be hacked.

I see you don't sign your e-mails :P Is this truly Keith? :P

~ ~ ~

Yes its me and as an example I signed everything above the "~ ~ ~" for you. See the attachments :D

I've never felt the need to generally sign my email. That would require quite a number of compromises so I don't personally feel the need but I like idea in general. I would prefer SMTP enforce certificates on top of the other things that are done now. For me, I only provide signatures at certain times or when requested.

*From: *"Thomas Delrue" <delrue.thomas@gmail.com>

*To: *"Philadelphia Linux User's Group Discussion List"
<plug@lists.phillylinux.org> *Sent: *Monday, June 1, 2015 11:15:47 AM
*Subject: *Re: [PLUG] SourceForge has Malware?

*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
https://en.wikipedia.org/wiki/Thompson_hack#Compiler_backdoors)

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 SoylentNews.org 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:
https://soylentnews.org/article.pl?sid=15/05/30/1447245 (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 solutions.

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

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 <rachelneko@gmail.com> 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
dice.com, 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.
http://sdtimes.com/sd-times-blog-sourceforge-now-a-source-of-malware/

Sourceforge has indeed joined the dark side.

On May 31, 2015 9:33 PM, "Anthony Martin"
<anthony.j.martin142@gmail.com> wrote:

Just wondering if anyone knows if theres truth to this or not?
(sorry if this is old news)
http://helb.github.io/goodbye-sourceforge/

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug