We evaluated recent claims of the nmap project regarding changes to their project presence and data on SourceForge. We’ve confirmed conclusively that no changes were made to the project or data, and that all past download delivery by nmap on SourceForge was through our web hosting service where content is project-administered. Please read the full analysis below.
Concerns
REF: http://seclists.org/nmap-dev/2015/q2/194
Claim is detailed as: “The old Nmap project page is now blank: http://sourceforge.net/projects/nmap/
Meanwhile they have moved all the Nmap content to their new page which only they control: http://sourceforge.net/projects/nmap.mirror/”
Technical Analysis
What “nmap” projects exist?
- nmap (group_id=1508).
- nmap.mirror (group_id=652750).
When were these projects created?
- The nmap project (1508) was created 2000-01-16.
- The nmap.mirror project (652750) was created 2011-12-22.
Who controls these projects?
- The nmap project (1508) is administered by ‘fyodor’.
- The nmap.mirror project (652750) is administered by ‘sf-editor1’.
Where does content come from?
- nmap project (1508) content is as provided by ‘fyodor’.
- nmap.mirror project (652750) content is a verbatim mirror of nmap releases from the canonical nmap site. Content is currently, and has always been, completely unmodified.
Has File Release data been removed from the nmap project (1508)?
- The standard place where files are distributed through SourceForge is the File Release System (FRS).
- The nmap project does not currently have any files in the File Release System (FRS).
- Project audit trail data shows no activity related to the File Release System (FRS).
- File Release System metadata shows no activity related to the nmap project.
- The SourceForge download statistics platform (dstats) shows no downloads ever occurring through the File Release System or its predecessors.
REF: https://sourceforge.net/projects/nmap/files/stats/timeline
Compared to a project which has been active during this time period, e.g. “mysql”, we would expect to see some activity here even for substantially old time periods if the project had been using this service.
REF: https://sourceforge.net/projects/mysql/files/stats/timeline?dates=1999-01-01+to+2015-05-05
- Based on lack of metadata, lack of data, and lack of statistics for the nmap project (1508), we conclude that the File Release Service was never used by this project, and no data was removed from that platform.
- Further confirmation has been made using the Internet Archive (archive.org) cached copies of historical File Release pages for the nmap project.
- We thus conclude that no data was removed because no data was ever placed in this service.
What SourceForge services did the nmap project (1508) consume?
- Records show that the SourceForge project web service (e.g. nmap.sourceforge.net) was used in the past. Two custom VHOSTs were served through this service.
- Project web data is housed separately from File Release System data, where we normally serve downloads.
- Some files still exist on disk for the nmap project (1508) in project web space, namely web page assets. No binary release data exists in project web for nmap.
- Fyodor has advised that he performed download distribution through the Project Web service, something which was permitted in the early days but not in recent years.
- SourceForge has discouraged the use of project web for distribution of binary data for a number of years, and has active controls at the webserver level which prevent download delivery through this service, most recently bandwidth throttling, quotas and file size limitations as detailed in our Site Docs at https://sourceforge.net/p/forge/documentation/Project%20Web%20and%20Developer%20Web/#bandwidth-throttling
- We wish for projects to perform this delivery using our File Release System which is backed by our globally-distributed download mirror network, not through the project web service that consumes our web serving bandwidth.
- File data for project web is not versioned, so there is no audit trail data.
- It is our general policy that project web content is maintained solely by the project except where we need to backup and remove content due to abuse, or where a project has specifically asked for assistance with content management.
- The SourceForge team had prior exchanges with the nmap project regarding quota exceptions. It has been confirmed through review of internal mailing lists and our internal ticketing systems (both current and historical) that no action was taken to remove content from nmap’s Project Web space.
- The SourceForge staff involved with enforcement have direct knowledge of the nmap utility — this is a name brand to us — and any action to remove nmap project content would have set off red flags.
- We have queried the SourceForge ticketing system (alexandria Support Requests) and confirmed that there were no communications there with fyodor regarding data removal or content in project web space; the three tickets from fyodor related to our Compile Farm service (in the 2000’s).
- We thus conclude that no action was taken by SourceForge staff related to content stored by fyodor on our project web service.
Were any changes made to the nmap project (1508) page to make it empty?
- Internet Archive (archive.org) cache was used to assess this concern.
REF: https://web.archive.org/web/*/sourceforge.net/projects/nmap
2001: Project was empty
2005: Project was empty
2007: Project was empty
2012: Project was empty
2015: Project is empty
The last update date in 2013 relates to the migration of the nmap project (along with all other projects on the site) from SourceForge’s sfx code base to the new Apache Allura-based code base. This migration was an automated operation conducted for all projects, and this platform change did not augment data in the Project Web service or File Release System.
We therefore conclude that no content has been removed from the nmap project page. Look and feel of this page has changed over time, but the underlying data remains has remained unchanged by staff.
The lack of audit trail data further confirms that no changes have occurred on this project.
Concern
‘In an e-mail to Ars, Lyon said, “Sourceforge did not communicate with me prior to seizing the account. They have communicated with me many times in the past about participating in these monetization strategies, and I always declined.”’
Business Analysis
Was nmap or nmap.mirror ever subject to bundled offers?
No.
Was the nmap project (1508) seized at any point?
No. See above analysis. A separate mirror of nmap releases was made on the nmap.mirror project. This is exactly as stated by steelgrass’s comment on the above Ars Technica article where he notes “Unlike the Gimp’s Windows distribution site it doesn’t look like they have taken over anything – they’ve just providing a mirror”
Would the bundling program have entertained the idea of including nmap or nmap.mirror?
The current SourceForge bundling program specifically excludes software designed for information security professionals, such as nmap, even in cases where those projects would gladly opt-in. Why? It doesn’t make good business sense.
- All of our bundled offers are opt-in.
- Infosec professionals do not generally wish to install secondary offers.
- Low opt-in rate results in low conversion rate.
Was a monetization opportunity offered to nmap in the past?
Yes. This was related to advertising program. This was not related to our bundled offers program, DevShare, which did not exist at the time of those communications.
> All of our bundled offers are opt-in.
The GIMP team claims they explicitly opted out in 2013, and yet you distributed the installer with offers under DevShare program. Please explain that.
Don’t act so self-righteous Sourceforge… You wouldn’t have to defend yourself against such claims if you didn’t start doing budleware (aka malware) in the first damn place!
What about your promise that you would never bundle malware without the developer’s consent?
First, thank you for your detailed clarification on this matter.
This is interesting timing, because I have been writing an article related to the following statement:
> Infosec professionals do not generally wish to install secondary offers.
In my article, I point out that Infosec professionals that choose open source tools tend to do so because it gives them a chance to audit the code which is executed. So far, it seems like the SourceForge installer has remained closed source.
I wondered as long as your willing to provide such detail clarification, if you could help further clarify about the SourceForge ad-offering installer:
(1) Can a project listed on SF as “License: GPL” then opt-in to the SF bundled offers program and still keep the same exact status for the stated license?
(2) Is there anyplace where the source code to the SourceForge bundled offer installer is made available under an OSI accepted license?
(3) Would SF consider it to be satisfying a mission towards open transparency for projects with a status of “License: GPL” offered an executable which is a mixture of open source and close source?
(4) Does SF see room for improving transparency regarding it’s DevShare Program? If it does, what changes are planned in the short term?
Did it occur to you, at any point, that if you need to produce this lengthy of an explanation (and play so many semantic games) to justify what you did, that what you did might be, you know, shady?
On a related note, have you considered what happens when you burn so much of your goodwill that no one feels compelled to provide you with the free mirrors that make your service possible? Is that ad money enough to replicate all those fat university pipes you’ve been leeching off of?
Stop stealing other people’s work! Noone’s interested in your “help” with “mirrors”. SF == scumbags. You’ve hit the new low. Hope this site dies soon.