From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id wJLKCiIdvl+dDAAA0tVLHw (envelope-from ) for ; Wed, 25 Nov 2020 09:00:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id uNKgBiIdvl/eMQAAbx9fmQ (envelope-from ) for ; Wed, 25 Nov 2020 09:00:18 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3AFBA9404C5 for ; Wed, 25 Nov 2020 09:00:17 +0000 (UTC) Received: from localhost ([::1]:59170 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khqes-0007KK-HF for larch@yhetil.org; Wed, 25 Nov 2020 04:00:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khqe2-0007Jq-6B for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 03:59:22 -0500 Received: from static.rcdrun.com ([95.85.24.50]:36867) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khqdz-00034Y-Jn for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 03:59:21 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C1AE2.000000005FBE1CE4.00005288; Wed, 25 Nov 2020 08:59:16 +0000 Date: Wed, 25 Nov 2020 11:23:27 +0300 From: Jean Louis To: Tim Cross Subject: Security issues in Emacs packages Message-ID: References: <87ft4zhyuo.fsf@disroot.org> <877dqbhtgf.fsf@ucl.ac.uk> <87zh36d1xn.fsf@web.de> <875z5uxzev.fsf@gmail.com> <87v9dt7wfa.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87v9dt7wfa.fsf@gmail.com> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.51 X-TUID: lBDos3hPNcSC * Tim Cross [2020-11-25 10:01]: > > Jean Louis writes: > > > * Tim Cross [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?