A cautionary tale from the decline of SourceForge
neverworkintheory.org
neverworkintheory.org
Ads and bundling malware (here: unwanted software) with downloads won't be received very well. The malware even had a negative influence on projects themselves. Example I know of was filezilla, which many never used or trusted again.
I don't know if you can compare sourceforge with github because the former was also used by many to get ready-to-use binaries where github is more exclusive to developers and peers.
Some projects use the gist page for their web page, and some use the release downloads as the download binary they link to. Sometimes, just as was often the case with sourceforge, the main project repo page was the main page for the project. If you think github is more exclusive to developers and peers, I think that's just your own bias in how you use it coming though, as many non-developer people I mention it to know what it is if it comes up in conversation.
I see them as extremely similar, to the point that on the relevant point of how it's used by the public I'm having a hard time coming up with differences.
The only things that will stop Github going the way of SourceForge is that:
1. It's owned by Microsoft. They'd be damaging their own reputation twofold. Once because of the malware on the Github and a second time because of their OS, Windows, running like crap after that malware is installed.
2. There's a general movement away from [edit: manually] downloading binaries (as there should be!) -- even on Windows package managers are becoming more commonly used.
I think the GP meant downloading random binaries through a web browser, as most people do on Windows. Package managers with hash verification are a million times safer than that.
Nothing short of a full code review will save you from a malicious supply chain attack. This is currently exploding with NPM as well, so building from source doesn't save you here either. See the node-ipc debacle from a few weeks ago [0], and also my own post from last week about a malware infected NPM module [1].
The reality is that yes, the days of being able to trust anything downloaded from a stranger on the internet are pretty much over now. But known-hash package management is still a good first layer of security versus downloading random binaries from the web.
Node is just insane, always was, along with the curl | bash crowd.
Madness.
Nonsense. Or, at least, an oversimplication.
https://medium.com/agoric/pola-would-have-prevented-the-even...
Nothing short of full code review will ensure that malicious code from a dependency doesn’t get into your program at all, but the capabilities of that malicious code once it does get into your program can certainly be limited.
That's a tall order for the open source community when it comes to a volume of packages like npm or composer.
You can logically look at lpad as a package and say "We're padding strings, we don't need to do anything with network traffic or disk reads" but building an automated system to make that evaluation and saving that evaluation in a tamperproof manner is going to be hard... and what happens if lpad starts trying to do a better job - operating correctly in left-to-right character sets and in languages where alignment is dictated by hyphens instead of blank space.
Code isn't simple and while the above statement may seem hyperbolic I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk but actually fully 100% preventing that risk? You'll need to check every usage scenario on every set of hardware and go through that code with a fine toothed comb.
If you're expecting to have to craft ACLs program-wide for that package, then sure, that's going to be hard. That's more coarse-grained than what I'm talking about here though.
Imagine, if you will, a programming environment where modules you load don't have any authority to access the network, filesystem, etc unless you pass them in. They're just not in scope. In such a language, the default way to grant HTTP access might look like this in pseudo-Python:
http = require("http")
myMaliciousLibrary = require("myMaliciousLibrary", http=http)
Now, this library has the problem you mentioned; it can make arbitrary outgoing HTTP requests, meaning it can send any metrics it collects to an ad server. It can't access the filesystem because the filesystem isn't in scope either, so what it can collect is limited, but still more access than it needs. So here's one way you might fix that (obviously highly simplified/incomplete in its implementation): class ProxyHTTP(origin="https://example.com", http):
def __init__(origin="https://example.com"):
self.allowed_origin = origin
def get(origin, path="/"):
return http.get(self.allowed_origin, path)
http = require("http")
myMaliciousLibrary = require("myMaliciousLibrary", http=ProxyHTTP(origin="https://good-site.example.com", http))
Now, this version of myMaliciousLibrary gets an object that looks like the http library it would normally use; it just happens to ignore the origin parameter that the library passes to it and uses the one it was initialized with instead. Now, that library can make requests to good-site.example.com, but if it tries to make a request to adserver.evil.com, it'll go to good-site.example.com instead. (You might also imagine a version of ProxyHTTP that just throws an error if the request's origin isn't the same one it was initialized with, or isn't in a list it was initialized with.)Most of today's programming languages aren't strict enough to enable this of course; JavaScript isn't there yet for example, and most other languages aren't even close to being able to do this. But that's mostly because they don't provide strict enough encapsulation, not because they're lacking some complex security enforcement mechanism.
> I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk
I just think people are accepting way more risk than they realize, given the number of dependencies in modern applications and the amount of access each of those dependencies have. It feels crazy that any one of those dependencies in any application could exfiltrate massive amounts of sensitive data from any machine it happens to run on.
There are ways you can instruct an OS to block calls to certain library functions/memory ranges (i.e. remove and grant elevations privileges) but I think such a system would need to be designed from the ground up. If you can still `require(lib/reallyOldCurl)` then your protections might allow linters to be able to mark packages as unsafe, but I think it'd be extremely difficult to block access without an extremely fundamental design intent.
I appreciate your reply quite a bit though as I was envisioning the restrictions being defined on a universal package level (aka lpad is given no disk access) rather than being delegated to the consuming developer.
Actually, binary package managers are arguably strictly less safe than getting the binaries directly from upstream because you've just introduced a (literal) "man in the middle", who might have their own agendas and their own need to monetize. Like, for example ... SourceForge did. In a different context these MITM attacks can go wrong even when they're genuinely trying to be helpful, as we may remember when Debian accidentally patched out important code from a core encryption library and caused everyone to get the same SSH keys.
Generally for security you want to reduce the number of middlemen who can tamper with things, unless those middlemen are explicitly adding some sort of security value by pre-tasting the apps. So, Apple app reviewers: yes. Linux distro maintainers: sorta sometimes. Homebrew, winget etc: no. It's all automated.
https://www.vlcdownload.com
https://www.vlcdownloads.com
https://www.videolan.com
https://www.vlc.com
https://www.downloadvlc.com
https://www.videolan.org
https://www.videolan.co.uk
https://sourceforge.net/projects/vlc/
In linux/Mac, I can "sudo apt install vlc", "sudo yum install vlc", or "sudo brew install vlc". I know I'm getting a valid and good software delivery. It just works. No malware. No sketchy websites. No malware packages.On Windows, well, you feelin lucky?
Chocolatey does have it's quirks though, there is both a '7zip' and a '7zip.install' package, it's not intuitive what the difference is.
Doesn't chocolatey fit the bill?
choco install vlcBut there are package managers for Windows, aren't there?
Microsoft even has its own app store, that you need to use to install applications such as Windows Terminal.
People often install software on Linux and macOS by downloading installers using a browser. In fact, that's how non-bleeding edge versions of Xcode are installed.
apt-get install wine
Did you just get Wine from upstream? The answer is no and this has wasted significant amounts of time of Wine developers in the past. I used to be one and spent way too many free evenings and weekends debugging subtle crashes reported by users, that turned out to be packaging bugs introduced by men-in-the-middle.
Lots of other Wine devs had the same experience, so at that time we had a policy that if someone reported a bug the first instruction was to uninstall their distro package and to install the binary packages produced by the Wine project itself. Sometimes users were upset by this advice, but it resolved a significant number of "bugs" that were being added by the distributors.
For lesser known projects I just cross my fingers, but typically lesser known projects are less likely to have malware posing as them
a) Download file.EXE binary from somewhere
b) run: certutil -hashfile file.EXE (which spits out hash value)
c) search for hash value obtained at step “b” on a site like: virustotal.com : it tells you if malware is detected
d) run: file.exe (if no malware detected)
I honestly couldn’t find a better method on MS Windows. Other suggestions?
Maybe I could have been more explicit, I took for granted that the context would be pretty obvious to most people. Sorry about that.
I've only been a sysadmin and developer since the mid 90's so for a fact I'm still in the process of getting my head out of my ass.
Gentoo's package manager mostly builds from source (though there are some binary packages available for Gentoo -- usually of huge binaries like Firefox, which take forever to build and which you have to update pretty frequently).
Guix can also build from source.
Thankfully my head has paradox-absorbing crumple zones.
Sourceforge probably killed a lot of projects with adware, but Filezilla ruined their own reputation and continue to stealthily distribute adware/malware.
It looks like they no longer do this, for what that's worth, but I still don't recommend it to people. A pity as the application itself is very good.
I regularly wonder how much it would really cost to host those assets somewhere else that didn’t do that. Or GitHub! Why don’t the devs just move their mods to GitHub!?!?
Are the mods generally FOSS? That would enable cleaned-up forks, although in the case of Filezilla this doesn't seem to have happened, which I find somewhat surprising.
I’m surprised they don’t split them up into 1.44mb rar archives “for your convenience”.
Luckily the modding community does a pretty good job of rewriting any egregiously bad mods like that to work around such devs.
Modding communities often also take a 'permissive' approach to the copyrights of the base game, but fortunately the publishers are often wise enough not to bother taking action against such mods. A mod like [0] gets to exist despite that, ultimately, it's infringing on the base game's copyrights.
[0] https://www.moddb.com/mods/deus-ex-invisible-war-esrgan-pack
Some platforms themselves have gotten real mediocre - curseforge I'm looking at you.
Don't use mods that redirect to ad.fly or whatever adware these days.
I’ve dealt with shitty as infested download websites, but this one took it a whole new level. I had to disable UBO, and even then getting the download was nigh impossible.
I agree it’s not worth the trouble, just avoid, the website is a whole new level of user hostile.
In regards to Curseforge, I agree it’s not great, but at least it works.
I don’t like 3rd party launchers or mod management applications, so for our little server I just make .zip available with a readme with pictures.
What’s useful about Curseforge is that with just a mod identifier, you can construct links using an excel formula with the url setting download filters to be for our client version automatically. So I use an excel sheet to help me keep track of the mods and make it easy to check for updates.
Mechanism for a while could only be downloaded from a website which made it nigh impossible to do the download. I had to disable UBO, and then all the redirects and click hijacking made it almost impossible still.
It really seemed like the mod author, Aidan C. Brady, had sold out.
I didn’t have the displeasure of needing it for a few years but when I checked recently, it was thankfully available on Curseforge, which although could be better, could also be a lot worse, at least it’s functional with UBO.
I put it down to that the majority of mods are not developed by professional developers and learning git on top of learning enough coding to make a mod is just too much to ask of these people.
Really, they don't need or want version control, CI pipelines, CLI tools, or any of the things normally used by professionals. All they need/want is a good user friendly webpage to share their mods, and maybe a forum or some way for users to ask questions/provide suggestions/report bugs in a non formalized way.
(Click here to start speedtest!)
I've reported them to google - but they still run.
"Murder for hire" (or any legally unambiguous high-profile crime enabler) -> Guaranteed removal. GReply: "Look how much we care"
"Run the dslreports malware infected" -> No meaningful action is taken by Google, they want 'dat DSLReports.exe $$$! GReply: <Crickets>
"Fuck yo and pwn your network" -> ? GReply: <Crickets>
The juicier question is:
How many straight up virus vendors have proliferated through Google ads and chrome 0-days? That's not going to be publicly available data. Why not? Seems like as a service operator, the right thing is informing clients who $BIGCO helped get infected with virii or malware. If notification upon discovery were mandated, at least some of the pool of desolation which undeniably exists (directly thanks to Google AdHoles) would be cleaned up. Is Google too proud to admit this happens? Protecting users, especially the most defenseless in the case of Ads, is consistently not a real priority for BigG.
Companies are full of people, and being humans we all makes mistakes or overlook things for too long. That would be okay if good faith efforts truly existed.
After watching people I know search for it (years ago) and click the first result (which was never the actual flashplayer) - they must of infected 10s of thousands.
Also terms like 'social security admin' 'new social sec card'- I watched my mom do the same thing - g-search, click first results.. start filling in info, second screen more personal info, third screen start to question whyu.. fourth screen - wait this ain't right.. sigh.
I wonder if such campaigns or comparable still succeed today.
To my knowledge (I was very young during the period when sourceforge was still good) sourceforge never really attracted private customers by offering value adds to CVS/SVN so it didn't have a reliable non-donation revenue model. Github has accumulated a cash cow in the form of a lot of companies using it for issue tracking and as a nice UI into their repository state - this doesn't make them secure for ever, they do have some very real competition and the fact that they are maintaining an ecosystem means they have a lot of costs beyond just hosting but I think they're in a place where, if they started to inject obnoxious ads, they believe their revenue would suffer even in the short term.
Correct. At the time it was a much tough hill to climb; the business climate was still not ready for it by and large; quite resistant actually, hence why for a while an on-prem version of the software was developed and sold and supported.
That itself was forced by the dot com fallout that killed the parent company hardware business and made SF a more critical leg for revenue. It all went downhill from there, especially when new leadership came in.
Disclosure: I worked at VA Linux/SF for 4 years (1998-2002), was on the SFDN "launch" team, and am still friends with a few of the original SF core guys. We all view what happened to SF as a tragedy.
I think because of the abundance of expertise in low-level machine language there, many cracked deDRM'd binaries or patched executables for abandonware games come out of Eastern Europe, hence the association.
I remember finding some patches for Heroes III that were only available on some .ru site and there were lots of ads if you turned the adblocker off.
I couldn't read Russian but it was pretty clear they were not the highest quality of ad.
I believe some Americans underestimate how many forums are actually hosted in Eastern Europe. They're still popular over here.
In Norway (~5M population) you'll find atleast 3 huge forums but also several niche ones.
When I wanted to change some hidden settings on my car I found many strange software packages on these strange forums. But nothing on GitHub, these forum people live in their own strange walled of garden.
> While DevShare was an opt-in service, some projects complained that SourceForge bundled third-party adware in their downloads without their consent.25 Ads were added to project download pages with fake download buttons to trick users into clicking on the ad. Often, clicking on these ads resulted in the download of adware.
> Management focused on ROI; SourceForge was expensive to run and did not have a plan to bring in revenue. This led to the introduction of DevShare, but since management did not understand the open source ethos and the development team was not included in management decisions, DevShare was a major failure. It prioritized ROI over trust and bundled adware with project downloads. Many projects started leaving SourceForge, citing DevShare as a main reason.
Then, I instantly flipped to having a very strong commitment to never again trust SourceForge. You've probably heard about how a reputation is built over years but can be destroyed in an instant... that's exactly what happened here.
Part of the reason is that from the point of view of the person downloading (binary executable) software, the most important feature the site provided was my trust that they would give me the same binary I was asking for. In a similar vein, if I discovered that a bank had been intentionally lying about account balances and adjusting them in the bank's favor to make a profit, I would immediately and permanently sever my relationship with that bank.
I found the article rather thin; I was hoping for some explanation of who made those disastrous decisions, and why.
The proportion of projects on Sourceforge that didn't have single commit was staggering and made it really hard to discover legitimate projects.
There certainly are plenty of immature and barely started projects on Github, but Sourceforge had devolved into a wasteland for people to post ideas in hopes that developers would flock to their aid.
(They seem to have improved that too, although the site is still quite cluttery even with an adblocker).
This is making me stop and think about whether I should use GitHub for my primary open-source project. Will GitHub become the next SourceForge? Is it already happening?
I respect SourceHut's decision to charge all users (at least once it leaves alpha), but GitHub's network effect is strong, and as much as I respect Drew for pushing toward a free software future, I need Windows and Mac CI. Maybe I should set up something self-hosted; I can afford it, at least for now.
I can't predict the future, but I see no reason why GitHub should "become the next SourceForge". The SourceForge exodus to GitHub was already well underway (and, at the time, also Google Code, BitBucket, Launchpad) because they offered vastly superior products than SourceForge, which was always a mess. People seem to have a lot of rose-coloured glasses about SourceForge, but their UI was clunky (even for the time), slow, chaotic with all the ease of use as your tax form, stuff often didn't work, etc.
The whole adware fiasco was the death rattle of an already declining business that couldn't build a vaguely decent product.
>Forges are online collaborative platforms to support the development of distributed open source software. While once mighty keepers of open source vitality, software forges are rapidly becoming less and less relevant.
By the definition proposed, is not GitHub a "forge", and "relevant" enough?
So yes, but would you call $project on gitlab.com a git hub, or would you call Reddit a chan site.
If anything the lesson is there is never a follow up or redemption arc for giving stuff away for free.
The plus is all the trendy concern trolls are on Github, so I live peacefully among the ancient ruins of sourceforge.net
It's clear why sourceforge went away - GitHub is just better in every way imaginable.
Again, my recollection (as a non-programmer) was Subversion repos were popular at this time -- launchpad.net linked source code was nearly all SVN -- and the likes of Tucows for MS Windows binaries, and other non-SF sites like Freshmeat became useful again.
Then Linus came out with `git` and the ecosystem shifted.
TL;DR to my recollection there was a gap between SF's decline and GitHub's rise, so the GitHub didn't cause SF's decline?