But once published, isn't such information already compromised for all practical purposes ?
I can understand the legal reason behind "pulling it down" (using someone else's IP, etc), but practically speaking the private information once published cannot really be "undone" (at best you can make it hard to find, and disassociate from yourself).
If it is only up for 1 hour, the chances that anyone malicious sees it is low.
If it is there forever, the chances that someone malicious eventually sees it approaches 100%.
"NuGet.org does not support permanent deletion of packages, because that would break anyone who is depending on it remaining available. This is particularly true when using the workflow that restores packages on build.
Instead, NuGet.org supports a way to 'unlist' a package, which can be done in the package management page on the web site. When a package is unlisted, it no longer shows up in search and in any package listing, both on NuGet.org and from the NuGet Visual Studio extension (or nuget.exe). However, it remains downloadable by specifying its exact version, which is what allows the Restore workflow to continue working.
If you run into an exceptional situation where you think one of your packages must be deleted, this can be handled manually by the NuGet team. e.g. if there is a copyright infringement issue, or potentially harmful content, that could be a valid reason to delete it."
(Source: http://docs.nuget.org/docs/Creating-Packages/Creating-and-Pu...)
CPAN packages can't really be uninstalled (http://stackoverflow.com/questions/2626449/how-can-i-de-inst...) and seem to be unnaturally prone to dependency hell.
The concern about running the entire test suite on module installation really isnt a problem if you think about. Additionally you are able to force the install if it fails on account of a test.
While that behavior feeds back into improved quality for responsive maintainers, it takes additional time during installation. When combined with point #1, it can make dependency chains seem more fragile.
Generally, if you've published a package, it's possible someone has downloaded it. If you take it down, that's going to be strange and unexpected behaviour for those people.
Someone has accidentally posted a package that contains a 2TB file, and now all mirrors have to sync it.
Someone accidentally puts their personal information in a package.
2TB file: That's .. nonsense. I assume guards are in place to prevent the oldest form of DOS attacks. If not, the guys at cargo.io will learn and .. make that go away?
Personal information: That looks like the only case where I sympathize with the guy uploading stuff. That said, this is how the net works? Publishing sensitive stuff to Github means that it might be out there forever (force pushing a new history doesn't mean that no one cloned the stuff before or just grabbed a zip of the current head).
For me its a win. I certainly can imagine some scenarios that might be painful, but .. that usually boils down to your third example, a developer error. The usual issue with 'removing packages' is that the user suffers. My gut feeling is that there are far more users that get 404s than developers that share their API keys.
* you push a revision which introduces a bug
* you push a release which introduces involuntary API breakage
* the new release has a glaring security issue
* release X relies on a third party which has changed (think: some web service) and therefore doesn't work anymore
Sure, you can push a newer release but you don't want _anyone_ to be using the old one.
I'm not saying yanking is good, but maybe a notification system "this package should not be used, upgrade to XXX" would be useful.
As you may be aware, there is limited support for versioning APIs using "go get" (Go's nearest equivalent of this). The developers of Go argue that the maintenance of your dependencies is your responsibility, and you should clone everything you need to your own environment. That gives you ultimate control, allowing you to pull and update them as you require, modify and bugfix as you see fit, and makes it hard, if not impossible, to end up relying on two packages with different versions.
If a project B depends on project A, then they must collaborate in some way to make sure that there are no breaking changes introduced between (minor) versions. If another project C also depends on A, then they must both use the same version of A if they are to be used together. The maintainers of A, B and C all have a duty to ensure that their code remains up-to-date and backwards compatible.
It seems that Rust values a different freedom. By specifying the exact version you require, there is no need to keep separate projects in sync. The flexibility comes at a cost; you may find you have different versions of many dependencies. Because they are not required to, maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date, requiring bugfixes in multiple places in your own codebase.
Clearly, some of the smartest minds in our industry disagree what the best tradeoff is. It is interesting to see the range of opinion though.
> By specifying the exact version you require,
This is only half true. It comes in two steps: you specify a _kind_ of version that you require, like
foo = "^1.2.0"
This also matters because...
> maintainers may neglect the tedious task of keeping their projects' dependencies up-to-date,
You just run 'cargo update' and it will re-calculate that dependency graph, and re-write out the lock file. You're as up to date as you can be. Of course, if that fix is only available in a range outside you've specified, that's different.
That's the last time where I heard about this wonderful idea that vendoring everything is a solution, because versioning is hard: https://www.kickstarter.com/projects/2066438441/haunts-the-m...
I'll take the solution where I can send a PR to the maintainer with updated dependencies over this sort of thing any day.
I should also state I fall on the extreme end of the spectrum. My belief is that the moment you depend on upstream package X it is wholly your responsibility to track changes and adapt your code accordingly. I don't believe software versioning does anything but encourage poor security, performance and general fragmentation.
I believe that before pushing your changes to a remote repo, you locally check that everything is stable, meaning there is no dev branch or stable releases just one true master branch!
If you don't want the bleeding edge then don't 'git pull'. simple!
The world goes boom! exponential overload!
... at least it get's really frustrating after a while, twice the space, twice the compilation time. And you'll know at least one of the libs has bugs lurking in it that have been fixed elsewhere except in that lib:(
Subtle things in dynamic linking may break applications when dependency versions are changed.
Static linking lets you bundle whatever version is known to work, including the most up to date versions.
Well, that's a problem waiting to happen. Infringing source? Malicious material? It's a publishing facility and so will be abused.
"Take care when publishing a crate, because a publish is permanent. The version can never be overwritten, and the code cannot be deleted. There is no limit to the number of versions which can be published, however."
That. Is. Awesome.