From: Jean Louis <email@example.com> To: Tim Cross <firstname.lastname@example.org> Cc: email@example.com Subject: Security issues in Emacs packages Date: Wed, 25 Nov 2020 11:23:27 +0300 Message-ID: <X74Uf2iUgrdFwe70@protected.rcdrun.com> (raw) In-Reply-To: <firstname.lastname@example.org> * Tim Cross <email@example.com> [2020-11-25 10:01]: > > Jean Louis <firstname.lastname@example.org> writes: > > > * Tim Cross <email@example.com> [2020-11-24 23:40]: > >> If people are really concerned about security, they should look first at > >> their use of repositories like MELPA. There is no formal review or > >> analysis of packages in these repositories, yet people will happily > >> select some package and install it. > > > > Interesting that you are one who mentions that. There are just few > > people ever mentioned it. > > > > I am still in process of the review of MELPA packages and its > > system. There are many security issues. > > > > Package signing is one example. It does not offer much of security > > when packages are signed automatically, but it raises level of > > security. > > > > MELPA packages and archive-contents are not PGP signed, while GNU ELPA > > packages are signed. > > > > IMO signing of packages is irrelevant when there is no formal review > process or even any formal process to verify the credentials of > signatures. In fact, just adding signing would likely be > coutner-productive as it would give the impression of some sort of > security where there is none. When user receives a signed package from GNU ELPA, that means it comes from GNU ELPA. If signed package is then distributed by mirrors or other websites users who enable package signature verifications will know that package still comes from GNU ELPA, and not from Chinese distributor. If the package is tampered the signature verification will not allow installation of the package. Variable package-check-signature is not enabled by default and it is due to similar issue just as local variables. Users who seek to verify the credential of the signatures can do so in human non-automated way as that is also how GnuPG instructions advise users to do so. The GPG/PGP keys are in ~/.emacs.d/elpa/gnupg/ and users can contact GNU ELPA maintainers and verify the signature. M-x package-install will automatically verify signatures if the option package-check-signature has been enabled. That it does add to security shows the fact that GNU/Linux distributions do sign packages. There is difference if the package comes from trusted source or not trusted source. > Basically, anyone can upload anything to MELPA. Maintainers verifies the package initially for certain conventions, after that, how I have understood it, packages are automatically pulled from Git. The more authors give packages to MELPA the more insecurity probability is raised. GNU ELPA how I understand it, I may be wrong, works like this: 1) packages are uploaded to GNU ELPA 2) then automatically signed by GNU ELPA PGP keys 3) offered for distribution The point number (1) is human, not automated. Author decides when is the package ripe for distribution and what is "release". Git repository is never release and not meant to be "release". Git is for collaborative development and users are made blind that it is some kind of release while it is not. One shall always assume that Git repository contains development versions not ready for public. MELPA pulls those packages, correct me if I am wrong, automatically from Git repositories without regard if the package is actually release. That does not align or respect the established Emacs conventions how packages should be released, if they are multi files they should be in .tar file otherwise .el and there are version numbers that MELPA fiddles with and makes possible conflicts and introduces confusions. In GNU ELPA authors decide when package is release ready and when it should be released. In MELPA authors only apply for their packages to be pulled out automatically and offered for distribution. Both repositories could be compromised but probability is becoming larger and larger that by automatic pulling of packages something worse happens. MELPA cannot know possibly who is behind authors who offer those packages for distribution and who has access or who may do something malicious. Some new similar package like angry-police-captain could serve for potential attacks. #+TITLE: <2020-10-23 Fri 18:28> WTF angry-police-captain #+AUTHOR: Jean Louis - This should scrap information from a third party unknown website and show it in minibuffer. Function does not work, and yes, it is just one function inside. Good example of nonsensical "packages". *Deleted* While similar packages can be made for entertainment they can be also used to track users and save data that should not be saved. Update to this package would not be checked by MELPA, and users who have enabled it would continue using it. And package could suddenly start doing something else. Author of the package could know how many users are using it as package is actually fetching from their website. By fetching the information from website the website can know many things about those users such as their locations, operating system and versions, etc. and could invoke specific malicious stuff for those specific users including send different information to users by their different location or other attributes. For that reason MELPA's automatic pulling of packages and race to offer "large package repository" is rather by its design detrimental for future. I hope it will change, but currently that is unlikely. > The only way anyone would find out that an uploaded package has > malicious code is if someone does a code review and spots the > malicious payload. Even once they find that, there is little chance > of being able to attribute the actions to any individual because no > real identity vetting is conducted. MELPA is the wild west. Thank you for saying your observation. > The new non-GNU repository has bene setup precisely due to both the > licensing issue and the fact many MELPA packages recommend/encourage the > use of non-free software/services. While non-GNU will improve this > situation, I don't believe there are any plans to actively review the > code in the packages. For my personal uses I am reviewing packages and constructing list of required packages that I may use and subset of my group would use. There also exist possibility of annotation of packages or one could make a feedback by users so that more things can be discovered about packages. > So, like MELPA, all you really have to go on is package > reputation. You cannot have any high level of confidence a package > does not contain malicious code other than an expectation that if it > is used by a sufficiently large enough number of users, it is > unlikely. Interpreting statistics is not for everyone. It would be nice that users give a human feedback which can be used for package reputation. If one counts "download statistics" that is incorrect to be used for reputation. If let us say imaginary, a package about angry-police-captain would contain some malicious code, then if user cannot differentiate what is reputation and download, then number of 1000+ downloads would be quite convincing to load the package. Download number is now used for reputation as it is currently the only attribute that may be obtained. > this is not an issue unique to Emacs. You only have to look at the > issues both Google's play store and Apples app store have had in the > past to see what the risks are. Of course, I know that. That is why there is no Google on any of my mobile phones as they run LineageOS operating system. I would switch to Replicant would I have access to supported hardware. All our clients and staff members are warned not to use the Google. Do you think MELPA authors would act on these comments to change something?
next prev parent reply other threads:[~2020-11-25 9:00 UTC|newest] Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-21 0:33 One vs many directories Texas Cyberthal 2020-11-21 5:13 ` Ihor Radchenko 2020-11-21 7:56 ` Jean Louis 2020-11-21 8:31 ` Texas Cyberthal 2020-11-21 9:29 ` Marvin ‘quintus’ Gülker 2020-11-21 10:21 ` Jean Louis 2020-11-21 15:00 ` Texas Cyberthal 2020-11-21 16:08 ` Jean Louis 2020-11-21 15:03 ` Dr. Arne Babenhauserheide 2020-11-21 15:45 ` Texas Cyberthal 2020-11-21 17:12 ` Jean Louis 2020-11-21 18:01 ` Texas Cyberthal 2020-11-21 18:57 ` Jean Louis 2020-11-22 6:36 ` Ihor Radchenko 2020-11-22 7:20 ` Jean Louis 2020-11-22 8:32 ` Ihor Radchenko 2020-11-22 8:56 ` Jean Louis 2020-11-21 22:36 ` Dr. Arne Babenhauserheide [not found] ` <CAMUm491Psp0u5JKyGROP6M=UfAcvOLTtOKAD1rOearV+KxgYdQ@mail.gmail.com> [not found] ` <firstname.lastname@example.org> 2020-11-23 9:50 ` Texas Cyberthal 2020-11-23 13:17 ` Jean Louis 2020-11-23 14:16 ` Ihor Radchenko 2020-11-23 18:08 ` Is Org really so simple? Jean Louis 2020-11-23 20:41 ` Tom Gillespie 2020-11-24 5:06 ` Jean Louis 2020-11-26 3:08 ` Ihor Radchenko 2020-11-26 8:57 ` Jean Louis 2020-11-29 7:20 ` Ihor Radchenko 2020-11-29 16:22 ` Jean Louis 2020-11-26 18:07 ` Dr. Arne Babenhauserheide 2020-11-26 23:09 ` David Rogers 2020-11-27 0:43 ` Tim Cross 2020-11-27 2:56 ` Jean Louis 2020-11-23 16:07 ` One vs many directories Texas Cyberthal 2020-11-23 19:20 ` Jean Louis 2020-11-24 7:55 ` Ihor Radchenko 2020-11-28 16:16 ` Jean Louis 2020-11-28 16:33 ` Christopher Dimech 2020-11-25 6:57 ` Texas Cyberthal 2020-11-25 9:51 ` Jean Louis 2020-11-25 10:39 ` Texas Cyberthal 2020-11-25 11:02 ` Jean Louis 2020-11-26 16:04 ` Texas Cyberthal 2020-11-26 17:31 ` Jean Louis 2020-11-27 9:00 ` Texas Cyberthal 2020-11-27 10:45 ` Jean Louis 2020-11-28 8:18 ` Texas Cyberthal 2020-11-28 10:09 ` Jean Louis 2020-11-29 6:18 ` Texas Cyberthal 2020-11-29 6:53 ` Jean Louis 2020-11-30 7:35 ` Texas Cyberthal 2020-11-30 7:50 ` Ihor Radchenko 2020-11-30 10:25 ` Texas Cyberthal 2020-11-30 10:57 ` Jean Louis 2020-11-30 12:27 ` Ihor Radchenko 2020-11-30 12:28 ` Ihor Radchenko 2020-11-30 19:00 ` Jean Louis 2020-12-02 2:56 ` Ihor Radchenko 2020-12-02 6:14 ` Jean Louis 2020-12-02 7:23 ` Ihor Radchenko 2020-11-21 16:55 ` Jean Louis 2020-11-21 22:48 ` Dr. Arne Babenhauserheide 2020-11-22 0:48 ` Jean Louis 2020-11-22 2:47 ` briangpowell 2020-11-22 17:55 ` Jean Louis 2020-11-21 6:12 ` Palak Mathur 2020-11-21 9:04 ` Jean Louis 2020-11-21 6:36 ` Jean Louis 2020-11-21 7:17 ` Texas Cyberthal 2020-11-21 9:53 ` Jean Louis 2020-11-21 10:15 ` Tim Cross 2020-11-21 11:18 ` Jean Louis 2020-11-21 14:44 ` Texas Cyberthal 2020-11-21 15:45 ` Jean Louis 2020-11-23 5:40 ` Ihor Radchenko 2020-11-24 9:00 ` Jean Louis 2020-11-24 9:45 ` Eric S Fraga 2020-11-24 9:51 ` Jean Louis 2020-11-24 11:42 ` Eric S Fraga 2020-11-24 13:13 ` Diego Zamboni 2020-11-24 13:49 ` Jean Louis 2020-11-24 17:02 ` Jean Louis 2020-11-24 18:50 ` Dr. Arne Babenhauserheide 2020-11-24 18:58 ` Jean Louis 2020-11-25 6:39 ` Tim Cross 2020-11-25 12:38 ` Local variables insecurities - " Jean Louis 2020-11-25 13:05 ` Eric S Fraga 2020-11-25 13:13 ` Jean Louis 2020-11-25 13:58 ` Eric S Fraga 2020-11-25 14:07 ` Jean Louis 2020-11-25 20:54 ` Tim Cross 2020-11-25 22:09 ` Jean Louis 2020-11-26 2:06 ` Tom Gillespie 2020-11-26 5:06 ` Jean Louis 2020-11-26 5:31 ` Jean Louis 2020-11-26 6:18 ` Tom Gillespie 2020-11-26 9:10 ` Jean Louis 2020-11-26 11:44 ` Detlef Steuer 2020-11-26 12:06 ` Jean Louis 2020-11-26 5:34 ` Greg Minshall 2020-11-26 5:49 ` Jean Louis 2020-11-26 8:39 ` Christian Moe 2020-11-25 8:10 ` Dr. Arne Babenhauserheide 2020-11-25 8:36 ` Local variables liberties Jean Louis 2020-11-24 20:11 ` One vs many directories Tom Gillespie 2020-11-24 20:39 ` Tim Cross 2020-11-25 4:54 ` Jean Louis 2020-11-25 5:54 ` Tim Cross 2020-11-25 7:01 ` Local variables issue - " Jean Louis 2020-11-25 5:06 ` Jean Louis 2020-11-25 7:00 ` Tim Cross 2020-11-25 8:23 ` Jean Louis [this message] 2020-11-25 9:07 ` Security issues in Emacs packages tomas 2020-11-25 9:26 ` Jean Louis 2020-11-25 10:41 ` tomas 2020-11-25 22:46 ` Tim Cross 2020-11-25 23:07 ` Jean Louis 2020-11-25 23:39 ` Tim Cross 2020-11-26 5:24 ` Jean Louis 2020-11-26 6:46 ` Tim Cross 2020-11-26 5:29 ` Greg Minshall 2020-11-26 5:53 ` Jean Louis 2020-11-26 6:35 ` Tim Cross 2020-11-26 12:27 ` Greg Minshall 2020-11-26 22:20 ` Tim Cross 2020-11-27 2:19 ` Jean Louis 2020-11-27 4:42 ` Greg Minshall 2020-11-25 4:44 ` One vs many directories Jean Louis 2020-11-25 10:19 ` org-sbe to automate some source block executions Jean Louis 2020-11-25 11:39 ` Ihor Radchenko 2020-11-25 15:06 ` Jean Louis 2020-11-25 11:46 ` One vs many directories Jean Louis 2020-11-25 13:07 ` Eric S Fraga 2020-11-25 13:14 ` Jean Louis 2020-11-25 13:12 ` Ihor Radchenko 2020-11-25 13:32 ` Jean Louis 2020-11-24 18:47 ` Dr. Arne Babenhauserheide 2020-11-24 18:54 ` Jean Louis 2020-11-25 8:14 ` Dr. Arne Babenhauserheide 2020-11-25 8:46 ` Jean Louis 2020-11-25 11:46 ` Ihor Radchenko 2020-11-26 12:47 ` Jean Louis 2020-11-26 13:27 ` Ihor Radchenko 2020-12-02 10:12 ` Jean Louis 2020-12-02 9:49 ` Jean Louis 2020-11-26 3:47 ` Ihor Radchenko 2020-11-26 3:32 ` Ihor Radchenko 2020-11-26 11:58 ` Jean Louis 2020-11-29 7:56 ` Ihor Radchenko 2020-11-29 17:57 ` Jean Louis 2020-11-21 13:41 ` Jonathan McHugh 2020-11-21 14:04 ` Jean Louis
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://orgmode.org * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=X74Uf2iUgrdFwe70@protected.rcdrun.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Org-mode mailing list This inbox may be cloned and mirrored by anyone: git clone --mirror https://orgmode.org/list/0 list/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 list list/ https://orgmode.org/list \ firstname.lastname@example.org public-inbox-index list Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.yhetil.org/yhetil.emacs.orgmode nntp://news.gmane.io/gmane.emacs.orgmode AGPL code for this site: git clone https://public-inbox.org/public-inbox.git