Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Deprecate all emacswiki packages. #2342
Comments
milkypostman
added
feature
recipes
labels
Jan 3, 2015
|
Amen. |
|
Will you provide somewhere the complete list of the future deprecated packages ? |
|
Could deprecated packages be pulled from emacsmirror instead? I've talked to Drew Adams, and he wants to keep |
For that see #2128. I believe that while pretty much everyone around here actually involved in the mirroring and packaging of elisp thinks that the wiki no longer is a good place to distribute libraries, dropping support for it is seen more as a long time goal. Just doing it now is also an option, but I don't think the hope that this would cause the remaining libraries to be migrated to some vcs repository sooner, is really justified.
We've all been there. |
dunn
added a commit
to dunn/melpa
that referenced
this issue
Dec 26, 2015
dunn
added a commit
to dunn/melpa
that referenced
this issue
Dec 26, 2015
jeffgran
added a commit
to jeffgran/melpa
that referenced
this issue
Jan 5, 2016
glyph
commented
Feb 10, 2016
|
Apropos of the last commit referenced above, it looks like the deprecation is already done - is this issue just waiting for the last existing emacswiki recipe to actually be deleted? |
tarsius
self-assigned this
Mar 12, 2017
|
I've assigned this to myself as a way to keep track of it. This does not necessarily mean I will do something. |
tarsius
added
policy
and removed
feature
recipes
labels
Mar 12, 2017
|
This has come up on reddit again. That doesn't really change anything, but somehow it pushed me closer to advocating a clear cut. Ultimately this is up to @purcell and @milkypostman. Also I think that even if you decide to drop support for the Emacswiki, we shouldn't rush anything. (But we shouldn't let it sit for another two years either.) I'm going to produce some data on which non-wiki packages would be affected by this. Might take me a while until I get to that though, because I want to address some related issues in |
|
I think I posted before I want to remove all emacswiki packages because of this exact threat. When I do need a package from emacswiki I manually download it, I don't use melpa because I am concerned about this. I'm happy to have them removed. It seems that now is indeed the time. The percentage of emacswiki packages is low. If we remove them and people complain, I'm sure we can work it out. I.e., have someone move the package to github or other dvcs. |
|
I'm not sure that I even have any wiki-sourced packages installed, because the very idea repulses me. ;) But as a member of the community, I would appreciate them being removed for the good of all of us. I definitely think we should be proactive rather than waiting for something bad to happen. Let's just bite the bullet, and anyone who really needs wiki-sourced packages can 1) keep using what they have installed, or 2) install them manually. I really don't want MELPA to be the subject of an LWN security article someday... |
|
Here's a first table listing wiki packages that non-wiki packages depend on. It does not include any indirect dependers and it is based on automatically extracted dependency information, not the |
|
ok, this reminds me, we should leave all the 'Drew Adams' packages. he has
a deal with the emacswiki folks that his package pages are locked. but we
should verify. this doesn't fall under our motivation for doing this though.
possibly we should mirror those packages. tarsius would have to say though.
…
|
I would strongly prefer that, especially if the mirrors were manually updated. I realize that's a chore, but I feel like leaving anything pulling from any kind of wiki is just a bad idea on principle, even if they say they have locked the pages in some way. What if the wiki were compromised someday? I guess the same could be said for any server being pulled from, even GitHub, but I still feel that wikis are generally not well engineered compared to other software and are just more risky. (I realize I'm just a noisy back seat driver here, so I will watch silently if you're tired of my chiming in.) |
tarsius
added a commit
that referenced
this issue
Apr 5, 2017
|
I have added 15 of these packages to the Emacsorphanage, updated the Emacsmirror to mirror from there, and updated Melpa to import from there too. For more information about the Emacsmirror and the Emacsorphanage see https://emacsmirror.org. For information about packages in the orphanage see https://emacsmirror.net/stats/emacsorphanage.html (but note that I have not updated that yet since adding these packages). Most of these package did not see any changes in several years. A few were modified about a year ago by someone other than the author/maintainer. If some edits one of these packages on the Emacswiki going forward, then Melpa and the Emacsmirror won't pick up those changes - but that's kind of the point. If someone (including the person who previously maintained it (to some extend) on the Emacswiki) would like to maintain one of these packages, then they should contact me. These repositories contain the full history though in most cases with bad commit messages. Someone(tm) should review these packages for security risks they may already contain. |
|
Thank you for doing that, Jonas! |
alphapapa
referenced this issue
in emacs-helm/helm
Apr 5, 2017
Closed
Move helm-browse-menubar to separate package? #1740
tarsius
added a commit
that referenced
this issue
Apr 5, 2017
|
Did the same for three more packages. Here is an updated table: |
|
And here is a table of all packages from the wiki, sorted by author. |
|
I have searched github for authors listed in the above table (click on the arrow to see it).
Please consider moving your package(s) listed in the above table from the Emacswiki to Github. The reason we are asking you do this, is that anyone can edit your package(s) on the Emacswiki and that poses a security risk. For more information about that read this thread and https://www.reddit.com/r/emacs/comments/63e8hu/are_emacs_package_repositories_a_security_risk/. All you have to do is go to I will take care of the rest. (Of course you will then have to push to that repository when you improve your package.) Please do this even if you consider your package to be obsolete/unmainted/... Someone liked it enough to have it added to Melpa. That doesn't necessarily mean that it should be kept in Melpa, so please add a comment here in case you think we should remove it. If you just happen to have the same name as the author of one of these packages, then please excuse the noise. I have not contacted Andy Stewart, Alex Henning, Joe Bloggs, Karl Chen, Kevin Rodgers, Michael Cook, Ryan Davis, Scott Frazer, or Trey Jackson, because each of these names is shared by more than one person who has an account on github. |
So out of the about four people who have made and are still making considerable contributions to Melpa, two don't actually use it. (I am the other one for the reasons given here). I hope that users who are concerned about "Melpa doing it wrong", realize how much work we are already putting into this even without performing security best practices. In some cases even without directly benefiting from that work ourselves. Not saying we shouldn't improve that, just that progress might be slower than the "severity of the issue" might warrant in the eye of those who don't actually do the work. |
|
sorry, i wrote my response quickly and intended to say: I don't use melpa's
*EmacsWiki* packages for this reason. I use MELPA for other things. As if I
didn't use MELPA i would be using git submodules to manage the packages and
feel they are roughly equivalent.
…
|
|
That last sentence sounds a bit ambiguous in my ears too. Do you use submodules for packages that you don't install using Melpa? (If so, then I recommend that you give my |
|
no i just download them to a subdirectory. they are very few and just the
wiki ones. borg seems like a cool idea.
…
|
|
The current situation is crappy, and I'm all in favour of fixing it aggressively by eliminating the emacswiki packages and letting the community pick up the pieces. But an alternate angle would be to ask the Emacswiki maintainers to lock all source code to specific users. Then the situation would arguably be no worse for Emacswiki packages than for arbitrary github packages. (Similarly, we could ask that the emacswiki send an http response header or other indication that a retrieved source file is locked, and then we would only build packages that are thus flagged.) Also, while I absolutely support addressing this specific issue, I feel like it is only a small part of eliminating the "malicious package" security threat faced by Emacs users: we just don't have good security oversight or practices in our community right now, and without them no user is going to get any useful degree of assurance about the safety of their Emacs packages without manually inspecting every new package before they install it. |
glyph
commented
Apr 6, 2017
This seems like a pretty good step to take to me. The major issue here, the one that really unambiguously needs to be addressed, is the fact that there are places in the pipeline where an attacker can just jump in without even executing an attack; they can just use emacswiki as designed, and it'll happily inject their exploits into legit downloads. It's OK to be relatively lax, and to let users trust a potentially nebulous and arbitrary group of maintainers; it's not OK to trust everyone in the world, because that's an opening big enough that any attacker can drive right in. Forcing everything to be explicitly authenticated to some specific, authorized set of people (who can of course explicitly authorize others!) is a reduction of attack surface from 7.49 billion potential attackers to the much smaller set of infosec-sophisticated people who can execute targeted attacks against individuals. I don't know exactly what that number is, but I would be comfortable guessing it's at least 4 orders of magnitude smaller. |
|
I think we're all in violent agreement. Who would like to pick up my above suggestion with Alex Schroeder, who no longer appears to be on github? We'd need to first establish that source-file editor locking is indeed implemented on emacswiki, and then request either pervasive locking or a lock-indicator HTTP response header. (For the curious, Emacswiki appears to use Oddmuse with a published config which it might be sufficient to patch lightly for our purposes here.) |
sbelak
commented
Apr 6, 2017
|
Moved mine to https://github.com/sbelak/sentence-highlight |
purcell
added a commit
that referenced
this issue
Apr 6, 2017
|
Thanks @belak, I've applied that change to our recipe. |
kensanata
commented
Apr 6, 2017
|
I'm still here!
Adding a header to locked pages would be easily enough to add. But the general dream I have is a web of trust setup. I trust myself and Steve, Steve signed off on a particular file, then I'll accept it as safe. Using GPG signatures. And I'm not just talking about signed or signed-off commits, I mean a public directory of signatures to accompany a repository like Melpa.
…
|
|
Doh, sorry - I was mis-spelling your github name! Agree that signatures and web of trust are the way to go. Signed package have been something we've wanted to move towards for ages (see ongoing discussion at #1749), so I sense an opening here to start moving ahead on that. Could we do the header thing soon, to help address the immediate issue, and continue discussion of signatures in parallel? |
kensanata
commented
Apr 6, 2017
|
Sure. Do you want to suggest a header?
|
arnima-github
commented
Apr 6, 2017
|
Hi, I'm the author of dos-mode Therefore, the old dos-mode is obsolete and has no value. Instead of forking it, I suggest removing its source code from EmacsWiki (and GitHub). I just emptied the obsolete code from https://emacswiki.org/emacs/dos.el. Can we remove the dos.el page altogether? Of slightly more value is a summary page comparing Dos-related packages |
@kensanata How about |
purcell
added a commit
that referenced
this issue
Apr 7, 2017
kensanata
commented
Apr 7, 2017
|
Is the username important? I don't track who actually locks a page, only who edits a page. As the name is optional, Anonymous is the default.
I would also make it into something that works for every wiki, so perhaps generalizing:
X-Page-Locked: (true|false)
X-Last-Edit-By: (.*)
But as I said, the last edit by is not secured by anything. I'd probably do without.
--
Typed on a tiny keyboard. Sorry for being terse.
…
|
|
Aha, okay - so anybody can edit a locked page, even a source code page, as long as they are logged in? How does a page become locked, and what does that mean for its editability later? |
|
Just a note: if the wiki-locking thing works, it will be necessary to ensure that the TLS connection to the wiki is valid, because if an attacker were able to force the connection to plain HTTP, he could manipulate the headers. These kinds of "downgrade attacks" have been common, and since so much SSL/TLS software that's still in the wild fails to validate certificates and protect against downgrading (e.g. Emacs 24, recent versions of Python), I would say that anything which relies entirely on TLS is not to be entirely trusted. SSL/TLS is so complicated and so easy to get wrong that software often does, and that typically leaves software further up the stack completely oblivious to the broken security. |
kensanata
commented
Apr 7, 2017
|
No, an admin can lock a page but I don't log the admin that does the locking (and there are more than one). That is, X can edit a page, and I can lock it, but in the header I can only tell you that the page is locked and that X was the last person to edit it. I cannot tell you that Alex locked it.
In all cases, people can simply pick any name they want when editing pages, so the name should never be used to verify anything.
A locked page can be edited by anybody with one of the editor or admin passwords. No username required. These passwords can be passed along from person to person. This is good for resilience but bad for security. I cannot make assurances to the effect that only Drew is editing his pages. I might have given the password to a friend, this the friend now has admin privileges, and the friend can set their username to be Drew, and the only suspicious thing you might see is that my friend and Drew don't share the same IP.
This is better than nothing, but it's not security. :)
--
Typed on a tiny keyboard. Sorry for being terse.
…
|
|
I appreciate Alex's candor. I don't think we should rely on locked wiki pages. :( |
kensanata
commented
Apr 7, 2017
|
Definitely right regarding the https security. Last time I checked I had good SSL Labs scores, so that's one thing. I should also post a fingerprint somewhere else, I guess.
|
tarsius
added a commit
to emacsmirror/epkgs
that referenced
this issue
Apr 9, 2017
kensanata
commented
Apr 19, 2017
|
Just to verify: No need for me to implement anything regarding HTTP headers
because Emacs Wiki packages will get dropped anyway?
…
|
pkkm
commented
Jun 9, 2017
|
Is there an easy way to make package.el refuse to install packages from the wiki? I think it would be a good solution for the security-conscious until the issue is resolved. |
|
@pkkm This used to work; https://github.com/milkypostman/dotemacs/blob/master/init.el#L19 I don't think that works anymore, but I do believe you could do the same approach but just look at the detailed description instead of the name. I haven't played with that for a while. |
pkkm
commented
Jun 17, 2017
|
I haven't had success with looking at the package description. Looking at the homepage works, but it's not reliable (some packages, e.g. (defadvice package--add-to-archive-contents
(around ignore-wiki-packages (package archive) activate)
(let* ((package-extra-info (package--ac-desc-extras (cdr package)))
(package-homepage (cdr (assoc :url package-extra-info))))
(unless (and package-homepage
(string-match-p
(rx "http" (? "s") "://" (? "www.") "emacswiki.org/" (+ anything) ".el")
package-homepage))
ad-do-it)))Would it be hard to make MELPA add the fetcher to package metadata? |
|
Eeehhhh.... You can just kill todochiku. It's many years old. If there is a complaint, I'll fire it on a github. |
|
@jonnay I interpret that as "it's obsolete". So in accordance with #4384 (comment) I am removing |
tarsius
added a commit
that referenced
this issue
Jun 23, 2017
microamp
added a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
microamp
added a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
microamp
added a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
microamp
added a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
microamp
added a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
snogglethorpe
commented
Aug 19, 2017
|
Hi,
I'm replying belatedly, as I just came cross this message stuffed into an
obscure corner of my email... (sorry!)
I'll move my little bits of code from my emacswiki page into github because
why not? Easier for me to use anyway.
However I do wonder: are there any _limits_ on what code is considered "at
risk of exploitation"?
The code I have on emacswiki is very small, more like "self-contained code
snippets" than any sort of package.
Maybe the fact that they're self-contained means that people might copy
them blindly, and in that sense, small size isn't a good protection against
malicious modification (fitting an exploit in there might be a bit
difficult though).
But is _any_ code safe to include on emacswiki? If my 10-line bits of code
are "too large," what about 5 lines? 2 lines? 1 line?
This seems a serious point because (often very small) code snippets and
examples are such an important part of Emacs culture; to not allow them at
all would seem a huge blow. The ease and approachability of
extension-via-coding, even for the rawest of beginners, and the ease of
talking about and sharing code, is an inherent part of what makes Emacs
Emacs.
Maybe it's context? Many such code snippets in a wiki are meant for people
to _read_, rather than simply use, so they _need_ to actually be in the
text; a reference to github doesn't really work. Because people are
reading them, you'd hope any malicious modification would be noticed by the
reader. But... you can't really _rely_ on that, right?
Am I just worrying about nothing?
Thanks,
…
|
|
This is why we want to deprecated all Emacswiki packages. I personally
don't install them through `package.el` for exactly this reason. Even one
line of elisp is exploitable. While a malicious repository owner could also
inject malicious code into their library, it would be very clear. With
EmacsWiki, because editing is anonymous, it would be much harder to provide
accountability for the change. So no, there isn't really a limit in my very
personal opinion.
On Fri, Aug 18, 2017 at 7:48 PM, Miles Bader <notifications@github.com>
wrote:
…
|
|
@snogglethorpe Size isn't relevant, because anyone can edit the code on Emacswiki and replace it with anything. A one-line The issue isn't size but access control and verification. |
|
@snogglethorpe EmacsWiki is fine as a place for random snippets that people paste into their init-files. However, it is completely unacceptable as an upstream source for a package manager. I believe that you are concerned about the loss of the EmacsWiki environment as a place to put snippets, which is not something that would happen if we stopped people putting packages on EmacsWiki. |
tarsius
referenced this issue
in emacscollective/epkg
Aug 20, 2017
Closed
Is it possible to search unpackaged files from emacsmirror/emacswiki.org? #6
tarsius
removed their assignment
Sep 5, 2017
|
@kensanata you probably overlooked this above because you were primarily invited to this discussion as the maintainer of the Emacswiki, but two of your own packages are still being imported from the wiki.
Assuming these should remain available, could you please move them to separate repositories on github? Thanks! |
kensanata
commented
Sep 25, 2017
|
Sure! Sadly, I won't get to it until the end of October since I'm away from my laptop. :)
|
milkypostman commentedJan 3, 2015
We should avoid all emacswiki packages in MELPA.
At this point we should also avoid adding further wiki packages.