From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id mJDTEuXjvl/FGAAA0tVLHw (envelope-from ) for ; Wed, 25 Nov 2020 23:08:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id gEqkDuXjvl+DeAAAB5/wlQ (envelope-from ) for ; Wed, 25 Nov 2020 23:08:21 +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 3B30D9404FF for ; Wed, 25 Nov 2020 23:08:15 +0000 (UTC) Received: from localhost ([::1]:38838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki3tW-0005hJ-6H for larch@yhetil.org; Wed, 25 Nov 2020 18:08:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki3sW-0005Zh-EH for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 18:07:12 -0500 Received: from static.rcdrun.com ([95.85.24.50]:43159) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki3sT-0000OJ-AM for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 18:07:12 -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 00000000002C0007.000000005FBEE39A.00005F8A; Wed, 25 Nov 2020 23:07:06 +0000 Date: Thu, 26 Nov 2020 02:07:00 +0300 From: Jean Louis To: Tim Cross Subject: Re: Security issues in Emacs packages Message-ID: References: <877dqbhtgf.fsf@ucl.ac.uk> <87zh36d1xn.fsf@web.de> <875z5uxzev.fsf@gmail.com> <87v9dt7wfa.fsf@gmail.com> <87mtz56omv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87mtz56omv.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: fKpCgCmyKLTN * Tim Cross [2020-11-26 01:47]: > I think you missed my point. There is no benefit in MELPA adopting > signed packages because there is no formal code review and no vetting of > the individuals who submit the code. Do you think it is really their reason? Or maybe you are developer in MELPA? There is still difference if package comes from MELPA or from third party archive, definitely signing would say this package was signed by MELPA and other package was not signed by trusted key, so who is that? Is the MD5SUM same as original? It would give some initiative to investigate. Packages are not audited that is so. I think audit can be quick by using grep for some dangerous commands, I have already found rm -rf as example command in one of packages, not as malicious one. One could search for (shell-command and verify such and similar functions. > If you have no controls in place over the contents of what is being > signed, the value of the signatures as a security measure is > drastically reduced. Yes, the valid signature may provide some > assurances as to where the package originated, but that means little > if the contents could be anything. What you explain is logical to me, users though need better information. One big DANGER should be given to users. > As it stands, the signing of ELPA packages only provides assurance that > they are packages assembled by GNU. These signatures do not provide any > real assurance regarding the content of the packages other than they are > GPL's and do not recommend or encourage the use of non-free > software. There is no absolute. Signing says about origins. Mirrors are placed anywhere in the world, including behind Internet. It is one way for users to verify origin and if source has been changed. > The question is what level of trust should you assume. With ELPA, all > you can really trust is that the package has a GPL license and does not > recommend/require the use of non-free software. There is little trust > that the package does not do something malicious or includes code which > may compromise the user's security. to provide that level of assurance, > you would need formal code reviews, which is not feasible given > available resources. Last month I could see that several packages were here and there improved by developers so they do look into code and how much they do I cannot know. > I think it is important users are aware of this > limitation. Furthermore, I ask the question "Does having signed > packages imply a level of expected assurance which is higher than it > really is?" In other words, do users expect that a package is > completely safe just because it was downloaded from an official GNU > ELPA repository? Download numbers on MELPA tells me that answer should be rather positive, any package is safe to be installed. See numbers. Information is no enough to teach users. More attention is necessary. > Last time I looked, ELPA also supported 'external' packages where the > data is retrieved from an external git repository. I think org is one > such package. Majority of GNU ELPA packages are external how I know about it, but authors decide WHEN to upload them. > > 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. > > > > Why? This is not normal. Git repositories contain all versions, both > production and development. What is production and what is development > is managed through branches and tags. Anyone who wants can clone the > ELPA git repository. How I see practically, people hack on git master branches and main branch need not be considered release ready. Git hosting websites then have special section for releases. Git branch is not a release according to what I know, it is revision control system or version control system. Git often looks pretty different than release as package. Of course everybody can clone. Point is that software is no ripe. Maybe somebody else knows if Git can tell that software is ripe, what I know it is not so. Author has to say when it is ripe for release. > > 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. > > this is wrong. In melpa you specify either a commit (SHA) or a branch or > both. The repository owner has control over this. MELPA doesn't just > pull data from the repository because there has bene an update. You can > configure things so that whenever data is committed to a release branch, > it is pulled, but this is under the control of the repository owner. It > isn't that different to ELPA where the maintainer will either push new > data to the ELPA repository (or ask someone with write permission to > pull it from their repository). OK it is great that it is so. Are you maybe author doing it? Is there any reference that authors are doing so? I have MELPA downloaded you could tell me how do I see that author is deciding if package is for release? > You imply authors do not have control over when new releases are made. > This is not the case. They have full control. Sure they have for themselves. Do they have it for MELPA? > The situation with ELPA is not much better. Yes, the authors are > required to sign over copyright, but what does that really tell you > about the author. How much vetting is done to verify those copyright > assignments? How much vetting is done to verify the identities of those > people? More importantly, how much of the code is formally reviewed? Valid questions! > The assumption that because a package is from ELPA it is safe is > wrong. Safer, not safe. Assumption by majority is that any packages from anywhere are safe. Downloads prove it. > So how big a risk are ELPA packages in reality? This is a difficult > thing to quantify. Yes, I do think there is lower risk with ELPA than > MELPA because even informal review is better than no review. Side note: ELPA is protocol, GNU ELPA is repository. MELPA ELPA should be rather more correct name. I can see all those points and I would like there is better code review. > > 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 automatic pulling is not the issue. As long as there is no formal > review of code in packages, any method used is vulnerable. So is there automatic pulling? I compare automatic pulling and building to author's decision on when a package would be issued. Jean