Hi list, tldr; Sourceforge has bundled malware with older Windows binaries for Gimp and apparently moved an old Sourceforge repo for nmap to a mirror where the nmap author does not have access. (Sourceforge claims it never bundles adware with security software, but that isn't at all reassuring.)
Please search the web for "sourceforge and gimp" and "sourceforge and nmap" and read a few of the relevant news items for further detailes.
Three suggestions:
- We should migrate away from Sourceforge.
- We should make sure the current Pd Sourceforge repo doesn't become
inactive. 3) Once safely migrated, we should change to the Sourceforge code and release a Pd-extended binary on Sourceforge whose only function is to display a warning message to the user in the main Pd window. The warning should alert the user that Sourceforge is no longer the repo for any flavor of Pd, and that they should uninstall it and scan for malware. 4) We should maintain active accounts on Sourceforge to make sure the current binaries never become a target for delivering malware.
I contacted the Oregon State University Open Source Labs, and it looks
like they can help us host at least the svn, git repos, and binaries.
It may also be possible to have infrastructure for some nightly builds,
but since Pd-extended's nightly builds aren't operational atm that's not
a priority.
If anyone wants to help, take leadership, or perhaps suggest an alternative plan that'd be great. I contacted OSUOSL because they have a long history hosting free software, are non-commercial, and are student-centric.
If anyone is thinking, "Why not just move to Github?" the answer is that ten years ago Sourceforge _was_ Github. We see how that is turning out.
-Jonathan
On 07/06/15 09:52, Jonathan Wilkes via Pd-list wrote:
an alternative plan that'd be great.
I think it was Socrates said something about "code > words":
https://github.com/pure-data/deken
Cheers,
Chris.
On 06/07/2015 11:07 AM, Chris McCormick wrote:
On 07/06/15 09:52, Jonathan Wilkes via Pd-list wrote:
an alternative plan that'd be great.
I think it was Socrates said something about "code > words":
I'm using github for the nw.js port atm, too. But I see way less potential for future shenanigans from a non-commercial host with a long track record.
Also-- if you look at the Gimp/Sourceforge story, Gimp had been offering Windows binaries from a site outside of Sourceforge for a long time. What Sourceforge did was to bundle their old binaries with malware. Sourceforge claimed the site had been "abandoned" by the Gimp devs, as if that is an excuse for the bundling.
http://petapixel.com/2015/05/29/sourceforge-accused-of-bundling-gimp-with-ad...
So unfortunately we have to keep an eye on the Sourceforge Pd repo for the foreseeable future. That's why I suggested "capping the well", so to speak, by releasing a non-functional binary once everything is available and maintainable from a different host.
-Jonathan
https://github.com/pure-data/deken
Cheers,
Chris.
Hi Jonathan,
Whoops, looks like more words were needed after all, heh. :)
On 07/06/15 23:51, Jonathan Wilkes via Pd-list wrote:
I'm using github for the nw.js port atm, too. But I see way less potential for future shenanigans from a non-commercial host with a long track record.
I don't think we should just move the current setup to Github.
I think that as a community it would be good to move to a less fragile setup than a centralized repository with centralized build farms where people get access to their own code revoked and one or two people have to be responsible for keeping the whole thing building and running. As we have seen, that is not sustainable.
What I think is optimal for us as a community:
- Externals developers should be individually free to host their source
code wherever they like, and creating and distributing a new external to users should be frictionless.
- Anybody should be able to easily build and distribute other people's
externals for platforms that the original author doesn't have access to, or build and distribute forked versions of externals with different features, or whatever.
- Users should be able to obtain externals ad-hoc without having to
download a monolithic distribution like Pd-extended.
- Users should be able to run whatever version(s) of Pd they like with
whatever externals they like, in so far as binary compatibility exists.
In short, I think it would be helpful if the community moved to a model more like Python, Node.js, Ruby etc. with regards to externals and Pd itself.
I am hopeful that the deken-plugin.tcl and the deken upload script provide the code necessary for a new decentralized infrastructure as described above. This code is my attempt to move things along in that direction:
https://github.com/pure-data/deken
If you have time to take a look, upload some externals, test out the search plugin, I would be very grateful. I referenced your TCL plugins extensively when building the plugin - thank you very much for making that code public on SourceForge.
As an expert Pd hacker your input is very valuable and I appreciate anything you can contribute if this sounds like a good idea to you.
Cheers,
Chris.
On 06/07/2015 09:54 PM, Chris McCormick wrote:
Hi Jonathan,
Whoops, looks like more words were needed after all, heh. :)
On 07/06/15 23:51, Jonathan Wilkes via Pd-list wrote:
I'm using github for the nw.js port atm, too. But I see way less potential for future shenanigans from a non-commercial host with a long track record.
I don't think we should just move the current setup to Github.
I think that as a community it would be good to move to a less fragile setup than a centralized repository with centralized build farms where people get access to their own code revoked and one or two people have to be responsible for keeping the whole thing building and running. As we have seen, that is not sustainable.
How does what you're working on compare to apt?
I'd really prefer a decentralized repo to match or exceed the security properties of apt. (I know apt isn't cross-platform, I just use it as a reference point because it seems to do things the right way.) But apt (at least as it functions in Debian) isn't frictionless.
Probably I'm thinking of the word "frictionless" in a different way than you mean it. For example, if you make the external publishing system frictionless, you greatly decrease the cost of attack. Someone can try to upload an evil external, and if they fail, they can just try again later.
Additionally, you raise the value of a successful attack. For example, an evil external could rename your tcl procs and redirect requests for any subsequent externals to an evil mirror. (And even if you don't allow writing over the tcl plugin file, those evil externals can rename the procs on Pd startup every time the user loads one of them in a patch.)
-Jonathan
On 09/06/15 11:33, Jonathan Wilkes via Pd-list wrote:
How does what you're working on compare to apt?
It's a bit like a terrible, half-assed, buggy, GUI-only version of apt written in an ancient scripting language and missing 99% of the features. It's designed to download Pd externals, Pd GUI plugins, and Pd abstractions, but not other types of software.
On the up side it runs on the same platforms as Pd does and integrates tightly with the UI. Basically the same idea though.
IOhannes yesterday submitted some feature requests for us to integrate deken with apt. Vapourware: when users are on a Debian based platform the search should also return results from an apt search so that they can optionally install externals from Debian packages instead of puredata.info. He also kicked off the "intent to package" to get deken into Debian:
https://bugs.debian.org/788075
As an Ubuntu user myself I am pretty excited about both of those things!
[Also a bit nervous at the prospect of more humans being subjected to software I wrote.]
I'd really prefer a decentralized repo to match or exceed the security properties of apt.
That would be excellent. A pie in the sky idea is one that stores packages in some type of anonymous torrent-cloud. Patches welcome!
Probably I'm thinking of the word "frictionless" in a different way than you mean it. For example, if you make the external publishing system frictionless, you greatly decrease the cost of attack. Someone can try to upload an evil external, and if they fail, they can just try again later.
Additionally, you raise the value of a successful attack. For example, an evil external could rename your tcl procs and redirect requests for any subsequent externals to an evil mirror. (And even if you don't allow writing over the tcl plugin file, those evil externals can rename the procs on Pd startup every time the user loads one of them in a patch.)
Yes, that's true.
When you let users download and run binaries compiled by arbitrary people you open them up to danger. I have thought a lot about this with respect to deken and here are what I hope are mitigating factors with some bad excuses thrown in for good measure:
- There is a warning prominently displayed when you launch the
deken externals search interface: "Only install externals uploaded by people you trust."
- Uploaders have to have an account on puredata.info which provides a
level of community accountability. The search systems tells the user which username was used when uploading the package. We can tar, gzip, and feather anybody who uploads an NSA compromised binary. Get your pitchforks & flaming rags ready everybody.
- The uploaded packages are sha256-summed and the sum is uploaded with
the package. At the moment this information is not used but in future users can verify with the developer that the same version they have is the one the developer actually uploaded, if they want.
- Vapourware: there is a feature request for optional GPG signing of
the package files. This provides an additional level of trust and verifiability where you don't actually have to ask the developer, you can just check using their public key.
- At the end of the day of course, it is about trust between users and
developers. Users who download Pd binaries from Miller's site trust that he won't inject obscure-music-nerd-spying-software from the NSA into his binaries.
- Every other package management system also faces these same issues,
as does "I am going to download this random Windows executable and double click it with impunity what could possibly go wrong". We can try for best-practice (or better!).
"I am regularly asked what the average Internet user can do to ensure his security. My first answer is usually 'Nothing; you're screwed'." -- Bruce Schneier
Jonathan, I hope your Midi-chlorians are tingling because I could sure use your TCL expertise in the form of pull-requests! :D
https://github.com/pure-data/deken/issues
Cheers,
Chris.
PS Lol: "Back in the 1980s, Yosemite National Park was having a serious problem with bears: They would wander into campgrounds and break into the garbage bins. This put both bears and people at risk. So the Park Service started installing armored garbage cans that were tricky to open -- you had to swing a latch, align two bits of handle, that sort of thing. But it turns out it's actually quite tricky to get the design of these cans just right. Make it too complex and people can't get them open to put away their garbage in the first place. Said one park ranger, 'There is considerable overlap between the intelligence of the smartest bears and the dumbest tourists.'" https://www.schneier.com/blog/archives/2006/08/security_is_a_t.html
On Tue, Jun 9, 2015 at 6:32 AM, Chris McCormick chris@mccormick.cx wrote:
On 09/06/15 11:33, Jonathan Wilkes via Pd-list wrote:
How does what you're working on compare to apt?
It's a bit like a terrible, half-assed, buggy, GUI-only version of apt written in an ancient scripting language and missing 99% of the features. It's designed to download Pd externals, Pd GUI plugins, and Pd abstractions, but not other types of software.
On the up side it runs on the same platforms as Pd does and integrates tightly with the UI. Basically the same idea though.
IOhannes yesterday submitted some feature requests for us to integrate deken with apt. Vapourware: when users are on a Debian based platform the search should also return results from an apt search so that they can optionally install externals from Debian packages instead of puredata.info. He also kicked off the "intent to package" to get deken into Debian:
https://bugs.debian.org/788075
As an Ubuntu user myself I am pretty excited about both of those things!
[Also a bit nervous at the prospect of more humans being subjected to software I wrote.]
I'd really prefer a decentralized repo to match or exceed the security properties of apt.
That would be excellent. A pie in the sky idea is one that stores packages in some type of anonymous torrent-cloud. Patches welcome!
Probably I'm thinking of the word "frictionless" in a different way than you mean it. For example, if you make the external publishing system frictionless, you greatly decrease the cost of attack. Someone can try to upload an evil external, and if they fail, they can just try again later.
Additionally, you raise the value of a successful attack. For example, an evil external could rename your tcl procs and redirect requests for any subsequent externals to an evil mirror. (And even if you don't allow writing over the tcl plugin file, those evil externals can rename the procs on Pd startup every time the user loads one of them in a patch.)
Yes, that's true.
When you let users download and run binaries compiled by arbitrary people you open them up to danger. I have thought a lot about this with respect to deken and here are what I hope are mitigating factors with some bad excuses thrown in for good measure:
- There is a warning prominently displayed when you launch the
deken externals search interface: "Only install externals uploaded by people you trust."
- Uploaders have to have an account on puredata.info which provides a
level of community accountability. The search systems tells the user which username was used when uploading the package. We can tar, gzip, and feather anybody who uploads an NSA compromised binary. Get your pitchforks & flaming rags ready everybody.
- The uploaded packages are sha256-summed and the sum is uploaded with
the package. At the moment this information is not used but in future users can verify with the developer that the same version they have is the one the developer actually uploaded, if they want.
- Vapourware: there is a feature request for optional GPG signing of
the package files. This provides an additional level of trust and verifiability where you don't actually have to ask the developer, you can just check using their public key.
- At the end of the day of course, it is about trust between users and
developers. Users who download Pd binaries from Miller's site trust that he won't inject obscure-music-nerd-spying-software from the NSA into his binaries.
- Every other package management system also faces these same issues,
as does "I am going to download this random Windows executable and double click it with impunity what could possibly go wrong". We can try for best-practice (or better!).
Do you already know the git torrent protocol: https://code.google.com/p/gittorrent/ and http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentral...
I think the with this goals in mind git torrent is worths to give it a try.
cheers husk
On 2015-06-09 07:46, Husk 00 wrote:
Do you already know the git torrent protocol: https://code.google.com/p/gittorrent/
does the use of google code imply that the project is already dead?
fgsdmr IOhannes
On Tue, Jun 9, 2015 at 8:53 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-06-09 07:46, Husk 00 wrote:
Do you already know the git torrent protocol: https://code.google.com/p/gittorrent/
does the use of google code imply that the project is already dead?
:)
cheers husk
On 06/09/2015 12:32 AM, Chris McCormick wrote:
On 09/06/15 11:33, Jonathan Wilkes via Pd-list wrote:
How does what you're working on compare to apt?
[...]
Jonathan, I hope your Midi-chlorians are tingling because I could sure use your TCL expertise in the form of pull-requests! :D
I'll have a look when I finish the nw.js port. But my gut reaction is that this is _way_ outside of my abilities to develop.
IOhannes' original suggestion (or maybe question) about just porting apt to the relevant OSes is probably less work than doing packaging from scratch in a sane and secure way. But I also think releasing a monolithic distro is way less work than either.
-Jonathan
Cheers,
Chris.
PS Lol: "Back in the 1980s, Yosemite National Park was having a serious problem with bears: They would wander into campgrounds and break into the garbage bins. This put both bears and people at risk. So the Park Service started installing armored garbage cans that were tricky to open -- you had to swing a latch, align two bits of handle, that sort of thing. But it turns out it's actually quite tricky to get the design of these cans just right. Make it too complex and people can't get them open to put away their garbage in the first place. Said one park ranger, 'There is considerable overlap between the intelligence of the smartest bears and the dumbest tourists.'" https://www.schneier.com/blog/archives/2006/08/security_is_a_t.html
On Sat, Jun 6, 2015 at 9:52 PM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
Hi list, tldr; Sourceforge has bundled malware with older Windows binaries for Gimp and apparently moved an old Sourceforge repo for nmap to a mirror where the nmap author does not have access. (Sourceforge claims it never bundles adware with security software, but that isn't at all reassuring.)
Please search the web for "sourceforge and gimp" and "sourceforge and nmap" and read a few of the relevant news items for further detailes.
Three suggestions:
- We should migrate away from Sourceforge.
- We should make sure the current Pd Sourceforge repo doesn't become
inactive. 3) Once safely migrated, we should change to the Sourceforge code and release a Pd-extended binary on Sourceforge whose only function is to display a warning message to the user in the main Pd window. The warning should alert the user that Sourceforge is no longer the repo for any flavor of Pd, and that they should uninstall it and scan for malware. 4) We should maintain active accounts on Sourceforge to make sure the current binaries never become a target for delivering malware.
This may be true for the compiled binaries but I think the svn repository should be safe, no? I don't think anyone could add malware to the repository without svn being aware of it.
Martin
On 06/07/2015 11:33 AM, Martin Peach wrote:
On Sat, Jun 6, 2015 at 9:52 PM, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> wrote:
Hi list, tldr; Sourceforge has bundled malware with older Windows binaries for Gimp and apparently moved an old Sourceforge repo for nmap to a mirror where the nmap author does not have access. (Sourceforge claims it never bundles adware with security software, but that isn't at all reassuring.) Please search the web for "sourceforge and gimp" and "sourceforge and nmap" and read a few of the relevant news items for further detailes. Three suggestions: 1) We should migrate away from Sourceforge. 2) We should make sure the current Pd Sourceforge repo doesn't become inactive. 3) Once safely migrated, we should change to the Sourceforge code and release a Pd-extended binary on Sourceforge whose only function is to display a warning message to the user in the main Pd window. The warning should alert the user that Sourceforge is no longer the repo for any flavor of Pd, and that they should uninstall it and scan for malware. 4) We should maintain active accounts on Sourceforge to make sure the current binaries never become a target for delivering malware.This may be true for the compiled binaries but I think the svn repository should be safe, no? I don't think anyone could add malware to the repository without svn being aware of it.
That sounds reasonable. But it also sounds reasonable that a repo catering to FLOSS would refrain from wrapping old binaries in a malware installer. So...
-Jonathan
Martin
-
Chris McCormick -
Husk 00 -
IOhannes m zmoelnig -
Jonathan Wilkes -
Martin Peach