Thomas Delrue on 1 Jun 2015 09:33:01 -0700

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

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.

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.

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

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

> 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

> 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

*From: *"Thomas Delrue" <>
> *To: *"Philadelphia Linux User's Group Discussion List" 
> <> *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 
> 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 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 <> 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)

Attachment: signature.asc
Description: OpenPGP digital signature

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