Remove all Emacswiki packages #5008
Conversation
|
I'm strongly in favour of this, and it certainly makes sense to just bite the bullet and do it. However, it will dramatically impact the day-to-day experience of many people who rely on certain very popular packages that are not available elsewhere. So I think we need to publicise this ahead of time and give a timeline. It would also be really helpful if @kensanata would be willing to end-of-life the hosting of code on Emacswiki on a compatible timeline - is that something you'd consider, Alex? |
|
Additionally, this will presumably cause a bunch of other packages to become uninstallable, as a result of depending on packages in this list. |
A half-way step to this would be to block the "raw" view of files on the emacswiki, so that files could be viewed in an html wrapper, but not easily downloaded in their original form. |
|
While this is a positive step for security, it's really annoying to suddenly find that your dotfiles no longer properly work on a new computer (arguably when you need them to work the most, since you're busy setting other stuff up). Would it be possible to freeze and copy the emacswiki packages to github or similar git hosting, instead of deleting them entirely? I guess that would raise the issue of who would maintain the packages then... |
We have already frozen those: #2342 (comment) ff. Maybe there are new ones, I'll check.
Could you give me a list of the download counts? We could freeze the most popular ones like we have done for the ones being depended on by non-wiki packages. |
If your dotfiles depend on software downloaded from a wiki, they're already broken. Better to be broken in a way that is obvious than one that is hidden. If this doesn't get merged what's to stop someone from just deleting them from the emacswiki directly instead? |
Is this sufficient? - https://melpa.org/download_counts.json |
Yes. I forgot that exists - it was late 😉 |
|
I think we should immediately stop updating any packages from the wiki, which can be easily done by editing |
tarsius
force-pushed
the
ex-wiki
branch
2 times, most recently
from
1b53bc5
to
73d476f
Compare
The Emacswiki is completely unsuitable as a source of automatically generated and widely distributed packages. Anyone can edit any package on the Emacswiki without even having to create an account. This is a huge security risk for the whole community. And addressing that is much more important than to avoid inconveniencing some users by removing their favorite packages. Also see #5008.
|
I have updated the statistics at https://emacsmirror.net/stats/emacswiki.html. |
This line is not very accurate at least: yaoddmuse is a soft dependency, company works just fine without it. |
I am aware of that. From #2342 (comment):
Despite these limitations I still think this information is useful. |
|
I have updated the table. Soft dependencies are now marked as such. |
|
Looking at the dependencies as seen by MELPA (using https://melpa.org/recipes.json and https://melpa.org/archive.json), gives a similar picture (this obviously does not include soft dependencies):
The greatest (and by far the most important) discrepancy is that The only other differences are that This obviously does not list all indirect dependencies (which would include everything that depends on |
|
Opened an issue on the evil repo for the goto-chg problem. |
|
@purcell Would you accept if I forked that package under the emacs-evil organization, modified it so that it works correctly with Evil and replaced the existing MELPA package with it? This would obviously require that it stays a drop-in replacement that works correctly both with and without |
That's because the
I would very much welcome that. Actually I think that I have proposed that to the previous maintainer (or maybe I just intended to do it, or only talked about it here). |
Yes, definitely. |
|
OK, done. @tarsius Don't forget removing |
The Emacswiki is completely unsuitable as a source of automatically generated and widely distributed packages. Anyone can edit any package on the Emacswiki without even having to create an account. This is a huge security risk for the whole community. And addressing that is much more important than to avoid inconveniencing some users by removing their favorite packages. Also see #5008.
The Emacswiki is completely unsuitable as a source of automatically generated and widely distributed packages. Anyone can edit any package on the Emacswiki without even having to create an account. This is a huge security risk for the whole community. And addressing that is much more important than to avoid inconveniencing some users by removing their favorite packages. Also see #5008.
|
I think the hosting of code on Emacs Wiki is a small but positive feature. Distributing this code using a package manager might be something that requires an extra effort you are not willing to spend (and neither am I) but removing this feature would result in a net negative for me and that is why I don't think that is a good idea.
|
Like for the packages from the Emacswiki we can not rebuild these packages after having deleted them accidentally. In this case it is not because the code to do so no longer exists, but because the data no longer exists. Re melpa#4622. Also see melpa#5008.
The configuration contains packages that are no longer supported by melpa. melpa/melpa#5008 This included bookmarks , hl-line , redo , and tidy. I have copied those dependencies into the 3rd-party directory for now. I will look for melpa replacements later. This was a stop gap to fix the build problem I found today.
The Emacswiki is completely unsuitable as a source of automatically generated and widely distributed packages. Anyone can edit any package on the Emacswiki without even having to create an account. This is a huge security risk for the whole community. And addressing that is much more important than to avoid inconveniencing some users by removing their favorite packages. Also see melpa#5008.
Like for the packages from the Emacswiki we can not rebuild these packages after having deleted them accidentally. In this case it is not because the code to do so no longer exists, but because the data no longer exists. Re melpa#4622. Also see melpa#5008.
See melpa/melpa#5008. Also color-themes seems to be broken; as of this commit you need to $ mkdir .emacs.d/elpa/color-theme-20070910.1007/themes Otherwise startup will complain that directory 'themes' does not exist.
See melpa/melpa#5008. Also color-themes seems to be broken; as of this commit you need to $ mkdir .emacs.d/elpa/color-theme-20070910.1007/themes Otherwise startup will complain that directory 'themes' does not exist.
Esto debido a los ajustes en Melpa sobre archivos inseguros bajados desde la Wiki de Emacs melpa/melpa#5008
|
Gentleman I've just fixed the dependencies of exato so it only depends on evil now. All should be fine. |
zoom-frm was removed from MELPA in late 2017 (see melpa/melpa#5008).
zoom-frm was removed from MELPA in late 2017 (see melpa/melpa#5008).
EmacsWiki packages are not supported by melpa anymore. See melpa/melpa#5008
See: melpa/melpa#5008 Add org-plus-contrib.
These commits were removed in the parent commit (which see). Only remove packages that hard `require' a package from the Emacswiki at the top-level and that specify the dependency using the Package-Requires header keyword. There are some other packages that soft require such a package and/or only require it when some command is called and/or when some non-essential library is loaded, and that do not specify a dependency using Package-Requires. Also see #5008.
For security reasons Melpa does not distribute any packages that are maintained on the Emacswiki. For this package we are forced to make an exception because it is required by several non-emacswiki packages, which in turn are required by Spacemacs. The Emacsmirror imports this package like it mirrors any other package that is maintained on the Emacswiki, by extracting the history of the respective library and putting the result in the `master' branch of the respective repository on the Emacsmirror; in this case https://github.com/emacsmirror/highlight. Melpa then mirrors the `melpa' branch of that repository. Unlike the `master' branch, the `melpa' branch isn't semi-automatically updated. Instead some user has to open a pull-request asking me to "merge master into melpa". I'll then review the changes and merge. I expect this will only happen if there are breaking changes. Closes #6436. Re #5008.
|
@steckerhalter has announced in #6436 that he has stopped to update his mirror of This is how I am doing it (I have also added this as a comment in the recipe and as the commit message): For security reasons Melpa does not distribute any packages that The Emacsmirror imports this package like it imports any other Melpa then mirrors the |
zoom-frm was removed from MELPA in late 2017 (see melpa/melpa#5008).
Update 2018-01-24 - The Finale
Removal of Emacswiki packages has long been requested and planned, yet we've all hung on because the convenience of useful code that's insecurely managed and distributed has consistently exceeded the motivation to mitigate the risks: prominent Emacswiki authors have not taken action, while library and starter kit authors and end users (myself included) have cheerfully continued to depend on Emacswiki-sourced packages.
MELPA stopped building/updating all these packages a while ago, with the intention of removing them once we had a plan to minimise disruption. In the meantime, we continued to serve up our last-built versions. We'd have preferred to publicly sunset our continued hosting of them, but having accidentally deleted those historic (probably-outdated) packages yesterday, we now won't be restoring them. We apologise for the disruption that the sudden removal has caused (and will continue to cause), but this would likely have been the case even if we'd announced a sunset date weeks in advance, and we hope that you'll understand our decision.
In hindsight, MELPA should probably never have distributed Emacswiki-sourced packages. When MELPA was starting off, incorporating those packages helped MELPA's growth, to both the community's benefit and its cost. Thanks to everyone who pushed us to resolve this!
Now that we all know better, let's get on with fixing things and making the package ecosystem better and safer. If Emacswiki authors move their code to a MELPA-supported SCM, we can re-add those packages to MELPA. Some authors won't be willing to do that, so the community will have to decide how much it values that code, and how to get it distributed.
Whatever steps are necessary along the way, we - the MELPA maintainers - will be happy to advise.
-@purcell
Update 2018-01-24
All packages were accidentally deleted, including non-Emacswiki packages. Those are in the process of being restored, but for the Emacswiki packages that is not currently possible. That probably means that we make this final soon, but still waiting for Steve to weight in. The discussion about this begins further down.
Update 2017-09-16
Status Packages from the Emacswiki are still available from Melpa, but they are no longer being updates, because melpa/package-build#9 has been merged into Melpa.
TODO Here is a list of ongoing efforts to get packages of the Emacswiki:
Getting Drew to commit to (a) Git repository/-ies #5034 Getting Drew to commit to (a) Git repository/-iesUnlikely, we've tried for a decade.Original issue text
Since everyone here (#2342) agrees that the Emacswiki packages should be removed because they pose a huge security risk, let's just do it. We pretty much decided to do this years ago and we tried to get maintainers to move their packages. Waiting a few more years won't make any difference except that it leaves the community at risk.