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.
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 
)
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.
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.
)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.
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.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Keith C. Perry, MS E.E.
Keith C. Perry, MS E.E.
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?
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?
-----BEGIN PGP SIGNED MESSAGE-----
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
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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJVbHcjAAoJEKosl9oIs/pO950QAMQV7oXkb/5AuHnhLA0w/YPe
TIceRjTQDtWQA82ZpktWXtWug6t/zJPFEmLxhFwnlGZVk3MuatfqoIOxUBy9ep1D
SDdhgyFflG+YGK3rKuv+jeVR1XyG70c9EubmIF2RVoOxbTZdFhy2dMnKQYYDdsDh
ZqPvacWUa6fbaxrq/p7ophkG3EOssDlwYB2t2JDUFiM8oehoosACf4NmZ/S7B9qK
k6sogoFm0L6r/yRAFZhS850U4daO3eyGcQjrfV53g00ru9oRhBdIJiypJhKnh8ZD
a2J7InAfD50781dR6gIeOQkv5zp45g8i4X7r2WZoumfr5ewf9OPuSKTCAqVXqLXS
VZbj/7evw3rhvf0zjIgKKm+1q0/y6AeF8xDLgcklFlsSvR5b24GRkF/IylBww/85
0hqm5unHc2uaKUxTiI0ID7sodFTEPAqogHC20o/NxSxszpNVnzmnbiA6PIFNRfsx
6eaEMfCMRn0N49gQ8D5v4wlye/qFV3UOlh8pgt+jHq8BWtKo0iBnyFXDapUUYUDW
1/AwFemF6rJzzsyrTrLrZPxyuzNV6sgdMJDvtb+yfUyewYfyS3Xq9RBTe/4wAeSV
zVy2gBDE9E054B9kmyYal3wGkA9LAgX6vAsqwRdO6tb+BxH/wm5NMHnHd4HrBWXm
nHv2jpV02IzXfDG60iIY
=9ZZX
-----END PGP 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