Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upDeprecate all emacswiki packages. #2342
Comments
milkypostman
added
feature
recipes
labels
Jan 3, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Amen. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
syl20bnr
Jan 7, 2015
Contributor
Will you provide somewhere the complete list of the future deprecated packages ?
|
Will you provide somewhere the complete list of the future deprecated packages ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
PythonNut
Jan 10, 2015
Contributor
Could deprecated packages be pulled from emacsmirror instead? I've talked to Drew Adams, and he wants to keep icicles on emacswiki.
|
Could deprecated packages be pulled from emacsmirror instead? I've talked to Drew Adams, and he wants to keep |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Jan 11, 2015
Member
Will you provide somewhere the complete list of the future deprecated packages ?
M-x rgrep RET :fetcher wiki RET
Could deprecated packages be pulled from emacsmirror instead?
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.
I've talked to Drew Adams, and he wants to keep icicles on emacswiki.
We've all been there.
tarsius
commented
Jan 11, 2015
•
edited
Edited 1 time
-
tarsius
edited Mar 31, 2017 (most recent)
edited
-
Mar 31, 2017 (most recent)
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. |
added a commit
to dunn/melpa
that referenced
this issue
Dec 26, 2015
added a commit
to dunn/melpa
that referenced
this issue
Dec 26, 2015
added a commit
to jeffgran/melpa
that referenced
this issue
Jan 5, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
glyph
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?
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
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Mar 12, 2017
Member
I've assigned this to myself as a way to keep track of it. This does not necessarily mean I will do something.
|
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 comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Apr 5, 2017
Member
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 epkg and the Emacsmirror first (since there I am the maintainer, not just a somewhat regular contributor).
tarsius
commented
Apr 5, 2017
•
edited
Edited 1 time
-
tarsius
edited
Apr 5, 2017 (most recent)
edited
-
Apr 5, 2017 (most recent)
|
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
milkypostman
Apr 5, 2017
Member
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 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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
alphapapa
Apr 5, 2017
Contributor
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...
alphapapa
commented
Apr 5, 2017
•
edited
Edited 1 time
-
alphapapa
edited Apr 5, 2017 (most recent)
edited
-
Apr 5, 2017 (most recent)
|
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... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Apr 5, 2017
Member
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 Package-Requires header.
| Dependee (27) | Author | Depender | Fetcher | Author |
|------------------+------------------------+-------------------------------+---------+-------------------------|
| dirtree | Ye Wenbin | prosjekt | github | Austin Bingham |
| ert-expectations | rubikitch | caskxy | github | Hiroaki Otsu |
| ert-expectations | rubikitch | coverage | github | Kieran Trezona-le Comte |
| ert-expectations | rubikitch | creds | github | Antoine R. Dumont |
| ert-expectations | rubikitch | req-package | github | Edward Knyshov |
| faces+ | Drew Adams | floobits | github | Geoff Greer |
| filesets+ | Drew Adams | helm-filesets | github | Graham Clark |
| findr | David Bakhash | jump | github | Eric Schulte |
| fit-frame | Drew Adams | anything-project | github | |
| font-lock+ | Drew Adams | all-the-icons | github | Dominic Charlesworth |
| frame-fns | Drew Adams | floobits | github | Geoff Greer |
| hexrgb | Drew Adams | jabber | git | |
| hexrgb | Drew Adams | on-screen | github | Michael Heerdegen |
| hexrgb | Drew Adams | paper-theme | github | Göktuğ Kayaalp |
| hide-lines | | syslog-mode | github | Harley Gorrell |
| highlight | Drew Adams | cider-eval-sexp-fu | github | Sylvain Benner |
| highlight | Drew Adams | eval-sexp-fu | github | Takeshi Banse |
| highlight | Drew Adams | evil-extra-operator | github | Dewdrops |
| highlight | Drew Adams | evil-search-highlight-persist | github | Juanjo Alvarez |
| highlight | Drew Adams | nrepl-eval-sexp-fu | github | Takeshi Banse |
| highlight | Drew Adams | php-boris-minor-mode | github | steckerhalter |
| highlight | Drew Adams | sonic-pi | github | Joseph Wilk |
| http-post-simple | Tom Schutzer-Weissmann | org-readme | github | Matthew L. Fidler |
| http-post-simple | Tom Schutzer-Weissmann | tumble | github | Federico Builes |
| key-chord | | buffer-flip | github | Russell Black |
| key-chord | | use-package-chords | github | justin talbott |
| lacarte | Drew Adams | helm | github | Thierry Volpiatto |
| levenshtein | Aaron S. Hawley | cmake-ide | github | Atila Neves |
| levenshtein | Aaron S. Hawley | ten-hundred-mode | github | |
| look-mode | | look-dired | github | Joe Bloggs |
| menu-bar+ | Drew Adams | floobits | github | Geoff Greer |
| multi-term | Andy Stewart | elscreen-multi-term | github | wamei |
| multi-term | Andy Stewart | helm-mt | github | Didier Deshommes |
| multi-term | Andy Stewart | navorski | github | |
| shell-command | TSUCHIYA Masatoshi | anything | git | Tamas Patrovics |
| shell-history | rubikitch | anything | git | Tamas Patrovics |
| showtip | Ye Wenbin | sdcv | github | Andy Stewart |
| sr-speedbar | Sebastian Rose | ppd-sr-speedbar | github | Robert Dallas Gray |
| sr-speedbar | Sebastian Rose | projectile-speedbar | github | Anshul Verma |
| strings | Drew Adams | ergoemacs-mode | github | David Capello |
| thingatpt+ | Drew Adams | el-spice | github | Vedang Manerikar |
| transpose-frame | S. Irie | nu-mode | github | |
| w32-browser | Emacs Wiki, Drew Adams | nsis-mode | github | Matthew L. Fidler |
| yaoddmuse | | company | github | Nikolaj Schumacher |
| yaoddmuse | | org-readme | github | Matthew L. Fidler |
tarsius
commented
Apr 5, 2017
•
edited
Edited 1 time
-
tarsius
edited
Apr 5, 2017 (most recent)
edited
-
Apr 5, 2017 (most recent)
|
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
milkypostman
Apr 5, 2017
Member
|
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.
…On Wed, Apr 5, 2017 at 10:53 AM, Jonas Bernoulli ***@***.***> wrote:
Here's a first table listing wiki packages that non-wiki packages depend
on. It does not include any indirect dependencies and it is based on
automatically extracted dependency information, not the Package-Requires
header.
| Dependee (27) | Author | Depender | Fetcher | Author |
|------------------+------------------------+-------------------------------+---------+-------------------------|
| dirtree | Ye Wenbin | prosjekt | github | Austin Bingham |
| ert-expectations | rubikitch | caskxy | github | Hiroaki Otsu |
| ert-expectations | rubikitch | coverage | github | Kieran Trezona-le Comte |
| ert-expectations | rubikitch | creds | github | Antoine R. Dumont |
| ert-expectations | rubikitch | req-package | github | Edward Knyshov |
| faces+ | Drew Adams | floobits | github | Geoff Greer |
| filesets+ | Drew Adams | helm-filesets | github | Graham Clark |
| findr | David Bakhash | jump | github | Eric Schulte |
| fit-frame | Drew Adams | anything-project | github | |
| font-lock+ | Drew Adams | all-the-icons | github | Dominic Charlesworth |
| frame-fns | Drew Adams | floobits | github | Geoff Greer |
| hexrgb | Drew Adams | jabber | git | |
| hexrgb | Drew Adams | on-screen | github | Michael Heerdegen |
| hexrgb | Drew Adams | paper-theme | github | Göktuğ Kayaalp |
| hide-lines | | syslog-mode | github | Harley Gorrell |
| highlight | Drew Adams | cider-eval-sexp-fu | github | Sylvain Benner |
| highlight | Drew Adams | eval-sexp-fu | github | Takeshi Banse |
| highlight | Drew Adams | evil-extra-operator | github | Dewdrops |
| highlight | Drew Adams | evil-search-highlight-persist | github | Juanjo Alvarez |
| highlight | Drew Adams | nrepl-eval-sexp-fu | github | Takeshi Banse |
| highlight | Drew Adams | php-boris-minor-mode | github | steckerhalter |
| highlight | Drew Adams | sonic-pi | github | Joseph Wilk |
| http-post-simple | Tom Schutzer-Weissmann | org-readme | github | Matthew L. Fidler |
| http-post-simple | Tom Schutzer-Weissmann | tumble | github | Federico Builes |
| key-chord | | buffer-flip | github | Russell Black |
| key-chord | | use-package-chords | github | justin talbott |
| lacarte | Drew Adams | helm | github | Thierry Volpiatto |
| levenshtein | Aaron S. Hawley | cmake-ide | github | Atila Neves |
| levenshtein | Aaron S. Hawley | ten-hundred-mode | github | |
| look-mode | | look-dired | github | Joe Bloggs |
| menu-bar+ | Drew Adams | floobits | github | Geoff Greer |
| multi-term | Andy Stewart | elscreen-multi-term | github | wamei |
| multi-term | Andy Stewart | helm-mt | github | Didier Deshommes |
| multi-term | Andy Stewart | navorski | github | |
| shell-command | TSUCHIYA Masatoshi | anything | git | Tamas Patrovics |
| shell-history | rubikitch | anything | git | Tamas Patrovics |
| showtip | Ye Wenbin | sdcv | github | Andy Stewart |
| sr-speedbar | Sebastian Rose | ppd-sr-speedbar | github | Robert Dallas Gray |
| sr-speedbar | Sebastian Rose | projectile-speedbar | github | Anshul Verma |
| strings | Drew Adams | ergoemacs-mode | github | David Capello |
| thingatpt+ | Drew Adams | el-spice | github | Vedang Manerikar |
| transpose-frame | S. Irie | nu-mode | github | |
| w32-browser | Emacs Wiki, Drew Adams | nsis-mode | github | Matthew L. Fidler |
| yaoddmuse | | company | github | Nikolaj Schumacher |
| yaoddmuse | | org-readme | github | Matthew L. Fidler |
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACUsgTfmKn-SqJFZ4jrgqI1G_z5Do6qks5rs7jfgaJpZM4DN8bO>
.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
alphapapa
Apr 5, 2017
Contributor
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.)
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.) |
added a commit
that referenced
this issue
Apr 5, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Apr 5, 2017
Member
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.
tarsius
commented
Apr 5, 2017
•
edited
Edited 1 time
-
tarsius
edited
Apr 5, 2017 (most recent)
edited
-
Apr 5, 2017 (most recent)
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Thank you for doing that, Jonas! |
alphapapa
referenced this issue
Apr 5, 2017
Closed
Move helm-browse-menubar to separate package? #1740
added a commit
that referenced
this issue
Apr 5, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Apr 5, 2017
Member
Did the same for three more packages. Here is an updated table:
| Dependee (12) | Author | Depender | Fetcher | Author |
|---------------+------------+-------------------------------+---------+----------------------|
| faces+ | Drew Adams | floobits | github | Geoff Greer |
| filesets+ | Drew Adams | helm-filesets | github | Graham Clark |
| fit-frame | Drew Adams | anything-project | github | |
| font-lock+ | Drew Adams | all-the-icons | github | Dominic Charlesworth |
| frame-fns | Drew Adams | floobits | github | Geoff Greer |
| hexrgb | Drew Adams | jabber | git | |
| hexrgb | Drew Adams | on-screen | github | Michael Heerdegen |
| hexrgb | Drew Adams | paper-theme | github | Göktuğ Kayaalp |
| highlight | Drew Adams | cider-eval-sexp-fu | github | Sylvain Benner |
| highlight | Drew Adams | eval-sexp-fu | github | Takeshi Banse |
| highlight | Drew Adams | evil-extra-operator | github | Dewdrops |
| highlight | Drew Adams | evil-search-highlight-persist | github | Juanjo Alvarez |
| highlight | Drew Adams | nrepl-eval-sexp-fu | github | Takeshi Banse |
| highlight | Drew Adams | php-boris-minor-mode | github | steckerhalter |
| highlight | Drew Adams | sonic-pi | github | Joseph Wilk |
| lacarte | Drew Adams | helm | github | Thierry Volpiatto |
| menu-bar+ | Drew Adams | floobits | github | Geoff Greer |
| strings | Drew Adams | ergoemacs-mode | github | David Capello |
| thingatpt+ | Drew Adams | el-spice | github | Vedang Manerikar |
| yaoddmuse | | company | github | Nikolaj Schumacher |
| yaoddmuse | | org-readme | github | Matthew L. Fidler |
tarsius
commented
Apr 5, 2017
•
edited
Edited 1 time
-
tarsius
edited
Apr 5, 2017 (most recent)
edited
-
Apr 5, 2017 (most recent)
|
Did the same for three more packages. Here is an updated table: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Apr 5, 2017
Member
And here is a table of all packages from the wiki, sorted by author.
| Author (44) | Package |
|-------------------------------+-------------------------|
| | ac-dabbrev |
| | aok |
| | batch-mode |
| | better-registers |
| | csv-nav |
| | dropdown-list |
| | eldoc-extension |
| | fuzzy-format |
| | fuzzy-match |
| | goto-chg |
| | jira |
| | list-processes+ |
| | point-undo |
| | redo+ |
| | sqlplus |
| | summarye |
| | wimpy-del |
| | yaoddmuse |
| Adrian Kubala | buffer-stack |
| Alex Schroeder | disk |
| Alex Schroeder | typing |
| André Riemann | centered-cursor-mode |
| André Riemann | fliptext |
| Andy Stewart | auto-install |
| Andy Stewart | chm-view |
| Andy Stewart | dired-sort |
| Andy Stewart | irfc |
| Arni Magnusson | dos |
| Benjamin Rutt | backup-each-save |
| Benjamin Rutt | top-mode |
| Binu Jose Philip, Drew Adams | w32browser-dlgopen |
| Chris Stucchio | multi-eshell |
| Christoph Conrad | highlight-current-line |
| Davis Herring | unbound |
| Dino Chiesa | rfringe |
| Dino Chiesa | tfs |
| Dino Chiesa, Alex Henning | thesaurus |
| Drew Adams | apropos-fn+var |
| Drew Adams | apu |
| Drew Adams | autofit-frame |
| Drew Adams | browse-kill-ring+ |
| Drew Adams | cmds-menu |
| Drew Adams | col-highlight |
| Drew Adams | crosshairs |
| Drew Adams | cursor-chg |
| Drew Adams | cus-edit+ |
| Drew Adams | dired+ |
| Drew Adams | dired-details+ |
| Drew Adams | dired-sort-menu+ |
| Drew Adams | doremi |
| Drew Adams | doremi-cmd |
| Drew Adams | doremi-frm |
| Drew Adams | doremi-mac |
| Drew Adams | eyedropper |
| Drew Adams | face-remap+ |
| Drew Adams | facemenu+ |
| Drew Adams | faces+ |
| Drew Adams | files+ |
| Drew Adams | filesets+ |
| Drew Adams | find-dired+ |
| Drew Adams | finder+ |
| Drew Adams | fit-frame |
| Drew Adams | font-lock+ |
| Drew Adams | frame-cmds |
| Drew Adams | frame-fns |
| Drew Adams | grep+ |
| Drew Adams | header2 |
| Drew Adams | help+ |
| Drew Adams | help-fns+ |
| Drew Adams | help-mode+ |
| Drew Adams | hexrgb |
| Drew Adams | hide-comnt |
| Drew Adams | highlight |
| Drew Adams | highlight-chars |
| Drew Adams | hl-defined |
| Drew Adams | hl-line+ |
| Drew Adams | hl-spotlight |
| Drew Adams | icicles |
| Drew Adams | icomplete+ |
| Drew Adams | imenu+ |
| Drew Adams | info+ |
| Drew Adams | isearch+ |
| Drew Adams | isearch-prop |
| Drew Adams | lacarte |
| Drew Adams | lib-requires |
| Drew Adams | macros+ |
| Drew Adams | mb-depth+ |
| Drew Adams | menu-bar+ |
| Drew Adams | misc-cmds |
| Drew Adams | misc-fns |
| Drew Adams | modeline-char |
| Drew Adams | modeline-posn |
| Drew Adams | mouse+ |
| Drew Adams | mouse3 |
| Drew Adams | naked |
| Drew Adams | narrow-indirect |
| Drew Adams | novice+ |
| Drew Adams | oneonone |
| Drew Adams | palette |
| Drew Adams | pp+ |
| Drew Adams | pp-c-l |
| Drew Adams | pretty-lambdada |
| Drew Adams | replace+ |
| Drew Adams | reveal-next |
| Drew Adams | second-sel |
| Drew Adams | showkey |
| Drew Adams | simple+ |
| Drew Adams | strings |
| Drew Adams | subr+ |
| Drew Adams | synonyms |
| Drew Adams | thing-cmds |
| Drew Adams | thingatpt+ |
| Drew Adams | thumb-frm |
| Drew Adams | tool-bar+ |
| Drew Adams | ucs-cmds |
| Drew Adams | window+ |
| Drew Adams | zones |
| Drew Adams | zoom-frm |
| Drew Adams, Lennart Borgman | wid-edit+ |
| Drew Adams, Thierry Volpiatto | bookmark+ |
| Francis J. Wright | dired-sort-menu |
| Igor Sikaček | awk-it |
| Jan Rehders | hideshowvis |
| Joe Bloggs | bs-ext |
| Jonathan Arkell | todochiku |
| Kahlil (Kal) HODGSON | plsql |
| Kahlil (Kal) HODGSON | swbuff-x |
| Kahlil (Kal) HODGSON | tidy |
| Kai Grossjohann | message-x |
| Karl Chen | apache-mode |
| Kevin Rodgers | auto-capitalize |
| Kevin Rodgers | igrep |
| Kumar Appaiah | muttrc-mode |
| Martin Rudalics | speck |
| Mathias Dahl | hide-region |
| Michael Cook | cygwin-mount |
| Miles Bader | echo-bell |
| Rafal Jedruszek | highlight-tail |
| Rick Bielawski | anchored-transpose |
| Rick Bielawski | column-marker |
| Rob Giardina | dired-details |
| Ryan Davis and Phil Hagelberg | project-local-variables |
| Scott Frazer | etags-select |
| Scott Frazer | etags-table |
| Seiji Zenitani | smart-compile |
| Simon Belak | sentence-highlight |
| Taiki SUGAWARA | highlight-cl |
| Taiki SUGAWARA | vline |
| Takeshi Banse | el-swank-fuzzy |
| Trey Jackson | framemove |
| Vinicius Jose Latorre | ascii |
| Vinicius Jose Latorre | blank-mode |
| Yoshida Masato | gnus-spotlight |
| khiker | ruby-block |
| rubikitch | lispxmp |
| rubikitch | minor-mode-hack |
| rubikitch | recentf-ext |
| rubikitch | screenshot |
| rubikitch | sequential-command |
| rubikitch | sticky |
| rubikitch | usage-memo |
tarsius
commented
Apr 5, 2017
•
edited
Edited 1 time
-
tarsius
edited
Apr 5, 2017 (most recent)
edited
-
Apr 5, 2017 (most recent)
|
And here is a table of all packages from the wiki, sorted by author. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Apr 5, 2017
Member
I have searched github for authors listed in the above table (click on the arrow to see it).
- @adrian-kubala
- @kensanata
- @arnima-github
- @christopherconrad22
- @DinoChiesa
- @sheijk
- @jonnay
- @kumanna
- @snogglethorpe
- @rgiar
- @zenitani
- @sbelak
- @buzztaiki
- @hchbaw
- @yoshida-masato
- @khiker
- @rubikitch
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 https://github.com/emacsmirror/<YOUR-PACKAGE> and click on Fork and then drop a note here. This will preserve the history of your package. Please state whether you are okay with me replacing the file on the wiki.
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.
tarsius
commented
Apr 5, 2017
•
edited
Edited 2 times
-
tarsius
edited
Dec 15, 2017 (most recent)
-
tarsius
edited
Jun 23, 2017
edited
-
Dec 15, 2017 (most recent) -
Jun 23, 2017
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Apr 5, 2017
Member
@milkypostman I don't use melpa because I am concerned about this [security thread].
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.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
milkypostman
Apr 5, 2017
Member
|
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.
…On Wed, Apr 5, 2017 at 1:13 PM, Jonas Bernoulli ***@***.***> wrote:
@milkypostman <https://github.com/milkypostman> I don't use melpa because
I am concerned about this [security thread].
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
<https://emacsair.me/2016/05/17/assimilate-emacs-packages-as-git-submodules/>
).
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACUsn5-QpoaxgKgr1p7xgbZfilubScnks5rs9nRgaJpZM4DN8bO>
.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Apr 5, 2017
Member
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 borg package manager a try.)
|
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
milkypostman
Apr 5, 2017
Member
|
no i just download them to a subdirectory. they are very few and just the
wiki ones. borg seems like a cool idea.
…On Wed, Apr 5, 2017 at 1:29 PM, Jonas Bernoulli ***@***.***> wrote:
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 borg <https://github.com/emacscollective/borg>
package manager a try.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACUsjlMCKff27eW8dEHRj36nMIaGXJFks5rs92hgaJpZM4DN8bO>
.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
purcell
Apr 6, 2017
Member
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.
purcell
commented
Apr 6, 2017
•
edited
Edited 1 time
-
purcell
edited Apr 6, 2017 (most recent)
edited
-
Apr 6, 2017 (most recent)
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
glyph
Apr 6, 2017
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 only agree to build packages that are thus flagged.)
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.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
purcell
Apr 6, 2017
Member
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.)
|
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.) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
sbelak
commented
Apr 6, 2017
|
Moved mine to https://github.com/sbelak/sentence-highlight |
added a commit
that referenced
this issue
Apr 6, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Jun 23, 2017
Member
@jonnay I interpret that as "it's obsolete". So in accordance with #4384 (comment) I am removing todochiku.
|
@jonnay I interpret that as "it's obsolete". So in accordance with #4384 (comment) I am removing |
added a commit
that referenced
this issue
Jun 23, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
pushed a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
pushed a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
pushed a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
pushed a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
pushed a commit
to microamp/melpa
that referenced
this issue
Jul 24, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
snogglethorpe
Aug 19, 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,
…-miles
On Thu, Apr 6, 2017 at 2:57 AM, Jonas Bernoulli ***@***.***> wrote:
I have searched github for these authors.
@adrian-kubala <https://github.com/adrian-kubala>, @kensanata
<https://github.com/kensanata>, @arnima-github
<https://github.com/arnima-github>, @christopherconrad22
<https://github.com/christopherconrad22>, @DinoChiesa
<https://github.com/DinoChiesa>, @sheijk <https://github.com/sheijk>,
@jonnay <https://github.com/jonnay>, @kumanna <https://github.com/kumanna>,
@snogglethorpe <https://github.com/snogglethorpe>, @rgiar
<https://github.com/rgiar>, @zenitani <https://github.com/zenitani>,
@sbelak <https://github.com/sbelak>, @buzztaiki
<https://github.com/buzztaiki>, @hchbaw <https://github.com/hchbaw>,
@yoshida-masato <https://github.com/yoshida-masato>, @khiker
<https://github.com/khiker>, @rubikitch <https://github.com/rubikitch>:
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 https://github.com/emacsmirror/<YOUR-PACKAGE>
and click on Fork and then drop a note here. This will preserve the
history of your package. Please state whether you are okay with me
replacing the file on the wiki.
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAYTWn6qHex_dP_j5Z_pL-QHcom6Fit1ks5rs9XtgaJpZM4DN8bO>
.
--
Cat is power. Cat is peace.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
milkypostman
Aug 19, 2017
Member
|
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:
… 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,
-miles
On Thu, Apr 6, 2017 at 2:57 AM, Jonas Bernoulli ***@***.***>
wrote:
> I have searched github for these authors.
>
> @adrian-kubala <https://github.com/adrian-kubala>, @kensanata
> <https://github.com/kensanata>, @arnima-github
> <https://github.com/arnima-github>, @christopherconrad22
> <https://github.com/christopherconrad22>, @DinoChiesa
> <https://github.com/DinoChiesa>, @sheijk <https://github.com/sheijk>,
> @jonnay <https://github.com/jonnay>, @kumanna <
https://github.com/kumanna>,
> @snogglethorpe <https://github.com/snogglethorpe>, @rgiar
> <https://github.com/rgiar>, @zenitani <https://github.com/zenitani>,
> @sbelak <https://github.com/sbelak>, @buzztaiki
> <https://github.com/buzztaiki>, @hchbaw <https://github.com/hchbaw>,
> @yoshida-masato <https://github.com/yoshida-masato>, @khiker
> <https://github.com/khiker>, @rubikitch <https://github.com/rubikitch>:
> 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 https://github.com/emacsmirror/
<YOUR-PACKAGE>
> and click on Fork and then drop a note here. This will preserve the
> history of your package. Please state whether you are okay with me
> replacing the file on the wiki.
>
> 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.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#2342 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-
auth/AAYTWn6qHex_dP_j5Z_pL-QHcom6Fit1ks5rs9XtgaJpZM4DN8bO>
> .
>
--
Cat is power. Cat is peace.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACUspUQIlDXtAr9bBboH5d_Y3_oRAvyks5sZjDGgaJpZM4DN8bO>
.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
alphapapa
Aug 20, 2017
Contributor
@snogglethorpe Size isn't relevant, because anyone can edit the code on Emacswiki and replace it with anything. A one-line defsubst on Emacswiki that is automatically packaged and made available could be replaced with a multi-line function that does anything to the user's computer, and it could be automatically packaged and then installed by unsuspecting users before anyone notices, and they would be exploited.
The issue isn't size but access control and verification.
|
@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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
raxod502
Aug 20, 2017
Contributor
@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.
|
@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
Aug 20, 2017
Closed
Is it possible to search unpackaged files from emacsmirror/emacswiki.org? #6
tarsius
removed their assignment
Sep 5, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Sep 25, 2017
Member
@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.
- disk
- typing
Assuming these should remain available, could you please move them to separate repositories on github?
Thanks!
|
@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! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kensanata
Sep 25, 2017
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. :)
|
tarsius
added
the
emacswiki
label
Oct 2, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
glyph
commented
Nov 12, 2017
|
October seems to have come and gone :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kensanata
commented
Nov 16, 2017
added a commit
that referenced
this issue
Nov 16, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Thanks @kensanata - updated in e6e7569. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
josteink
Nov 16, 2017
Contributor
I've updated code for a package currently hosted on Emacs-wiki, and I can't see the changes resulting in a new package for the latest MELPA builds.
Is this related to Emacswiki now being deprecated? Does that apply to existing packages using that recipie too?
Or could there be other reasons too? (For reference, this is the package I'm talking about).
|
I've updated code for a package currently hosted on Emacs-wiki, and I can't see the changes resulting in a new package for the latest MELPA builds. Is this related to Emacswiki now being deprecated? Does that apply to existing packages using that recipie too? Or could there be other reasons too? (For reference, this is the package I'm talking about). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Yes. Also see melpa/package-build#9. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
josteink
Nov 16, 2017
Contributor
Thanks for the quick reply. That’s very informative.
Has anyone had any thoughts on what a good migration path from Emacswiki should look like, on a wider scale?
Am I now forced to “git” this code and become “official” maintainer for yet another abandoned package?
Or is someone planning to create a wider Github-organization where a bigger collective of co-maintainers from the Emacs-community can help out, without forcing individual users to take/claim ownership?
Is this being discussed anywhere? If so I’d love some pointers and links :)
|
Thanks for the quick reply. That’s very informative. Has anyone had any thoughts on what a good migration path from Emacswiki should look like, on a wider scale? Am I now forced to “git” this code and become “official” maintainer for yet another abandoned package? Or is someone planning to create a wider Github-organization where a bigger collective of co-maintainers from the Emacs-community can help out, without forcing individual users to take/claim ownership? Is this being discussed anywhere? If so I’d love some pointers and links :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Nov 16, 2017
Member
Is this being discussed anywhere? If so I’d love some pointers and links :)
Click on the emacswiki label.
Click on the |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
josteink
Nov 16, 2017
Contributor
Never mind. I see you have made some great efforts, and I see batch-mode being superseded by bat-mode supplies by Emacs core.
I guess all my needs are covered, all my issues resolved and I have no further questions.
Thanks for taking time to respond anyhow!
|
Never mind. I see you have made some great efforts, and I see batch-mode being superseded by bat-mode supplies by Emacs core. I guess all my needs are covered, all my issues resolved and I have no further questions. Thanks for taking time to respond anyhow! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
milkypostman
Jan 24, 2018
Member
i have inadvertently deleted all emacswiki packages. so we may as well delete the recipes???
|
i have inadvertently deleted all emacswiki packages. so we may as well delete the recipes??? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
syl20bnr
Jan 24, 2018
Contributor
@milkypostman did you also delete all the other packages :-D Currently MELPA is listing 757 packages only and there are a lot of unavailable packages when installing Spacemacs.
|
@milkypostman did you also delete all the other packages :-D Currently MELPA is listing 757 packages only and there are a lot of unavailable packages when installing Spacemacs. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
syl20bnr
commented
Jan 24, 2018
•
edited
Edited 2 times
-
syl20bnr
edited Jan 24, 2018 (most recent)
-
syl20bnr
edited
Jan 24, 2018
edited
-
Jan 24, 2018 (most recent) -
Jan 24, 2018
|
Just saw the tweet
;-) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
Jan 24, 2018
Member
i have inadvertently deleted all emacswiki packages. so we may as well delete the recipes???
Since #5008 is specifically about that, I am taking the discussion there (starting at #5008 (comment)).
Since #5008 is specifically about that, I am taking the discussion there (starting at #5008 (comment)). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
The recipes for wiki packages are no more. |
tarsius
closed this
Jan 25, 2018
added a commit
to shackra/emacs
that referenced
this issue
Mar 29, 2018
added a commit
to kai2nenobu/.emacs.d
that referenced
this issue
Apr 2, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
wyuenho
May 20, 2018
Contributor
Ahhhh I just realized zoom-frm was dropped from Melpa as a result of this. If I file a PR to fetch from emacmirror for zoom-frm, will this be accepted?
|
Ahhhh I just realized zoom-frm was dropped from Melpa as a result of this. If I file a PR to fetch from emacmirror for zoom-frm, will this be accepted? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tarsius
May 20, 2018
Member
No. The reason the Emacswiki packages were dropped from Melpa is that anyone can edit any package on the Emacswiki, which is a security "risk" (aka no security at all). Getting these packages indirectly through the Emacsmirror doesn't change anything about that. (Also see the forth message above and follow the link).
|
No. The reason the Emacswiki packages were dropped from Melpa is that anyone can edit any package on the Emacswiki, which is a security "risk" (aka no security at all). Getting these packages indirectly through the Emacsmirror doesn't change anything about that. (Also see the forth message above and follow the link). |
milkypostman commentedJan 3, 2015
We should avoid all emacswiki packages in MELPA.
At this point we should also avoid adding further wiki packages.