Re: [PLUG] SourceForge has Malware?

[Thomas Delrue <delrue.thomas@gmail.com>]

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

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 https://en.wikipedia.org/wiki/Message_authentication_code?

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

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
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