From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Proposal to include obligatory PGP verification of packages from any repository Date: Mon, 19 Oct 2020 15:43:35 +0300 Message-ID: <20201019124335.GC19325@protected.rcdrun.com> References: <20201012050418.GZ2923@protected.rcdrun.com> <20201013052736.GE31408@protected.rcdrun.com> <20201016130235.06218dae@argon> <87eelvplvh.fsf@posteo.net> <10bdf4ea-e365-cc3d-ec03-4348946fadbe@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15327"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: mve1@runbox.com, "Philip K." , rms@gnu.org, thibaut.verron@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 19 14:44:42 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUUWo-0003sD-DX for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 14:44:42 +0200 Original-Received: from localhost ([::1]:55284 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUUWn-0005Eb-Fq for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 08:44:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUUVr-0004Ii-W3 for emacs-devel@gnu.org; Mon, 19 Oct 2020 08:43:44 -0400 Original-Received: from static.rcdrun.com ([95.85.24.50]:54411) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUUVp-00080L-Bn; Mon, 19 Oct 2020 08:43:43 -0400 Original-Received: from localhost ([::ffff:41.202.241.51]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002A0B42.000000005F8D89FA.00005895; Mon, 19 Oct 2020 12:43:38 +0000 Content-Disposition: inline In-Reply-To: <10bdf4ea-e365-cc3d-ec03-4348946fadbe@yandex.ru> Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 08:43:39 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] 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-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258108 Archived-At: This is related to MELPA subject and future Emacs repositories. PROPRIETARY JAVASCRIPT ON MICROSOFT GITHUB ISSUE: ================================================= I just guess that Github.com cannot be used with LibreJS, as I have tried it, LibreJS report problems, this means all developers and contributors to MELPA are automatically subjugated by Microsoft Github, which is and was not the point of Emacs as free software part of free operating system. Additionally Github.com does not support many browsers, they publicly say so, which in turn means that many users of free software browsers from free software distributions are unable to access Github.com, users of Github are supposed to use Firefox or Chrome or Microsoft Browsers, while I am using Icecat and Iceweaseal-UXP from Hyperbola GNU/Linux-libre -- so my experience with Github.com is narrowed, I cannot access large parts of the website. Developers using MELPA are misguided by Microsoft Github, and MELPA is only following the popularity trend. Thus developers or old and new contributors for reasons of getting included in MELPA are forced to use non-free Javascript and browsers that are mostly not available on free software distributions. MELPA is telling users on its website that it is extensible, but please "contribute your recipes via github, and we'll build the packages", they are tageting Github, and thus lead Emacs users to use non-free Javascript on Github. This is contradictory to purposes why free software systems have been created. There is https://savannah.nongnu.org then there is Trisquel hosting, they would easily add Emacs packages without problem https://devel.trisquel.info/users/sign_in then there are other non-free Javascript and friendly free software hosting providers. Could you maybe ask MELPA to switch to some free software hosting sites for code, that way website would be accessible without using proprietary Javascript. That would be right direction to go for MELPA. It is good if we make incentive to those people who contribute to MELPA to switch their hosting from Microsoft Github with proprietary Javascript and their policies to some of free software hosting providers, but what is really best is that MELPA switches to free software hosting code providers. AVOIDING EMACS PACKAGES WRAPPING PROPRIETARY SOFTWARE: ====================================================== This is other issue, it could be solved (as already somebody mentioned) with one package to be developed in GNU ELPA, named similar to "freedom-check" or even better as a built-in package that would warn Emacs users about usage of non-free software or any other freedom issues, it could ask user to disable those packages discovered on system that are wrapping non-free software. The package "freedom-check" would be for Emacs what is LibreJS on browsers and what is "your-freedom" on Hyperbola GNU/Linux-libre and other free software distributions. It could disable or remove the packages that were installed to wrap proprietary software. Additionally, it could disable repositories that do not care about users' freedom and would tell users why is it so. It would be good direction if such package is developed and then beside being distributed on GNU ELPA, also injected in MELPA, as it would be innovative package in users' interest, thus fully complying with MELPA principles. Let us not forget that inclusion of packages wrapping proprietary software represents large security risk as well, not only that it subjugates users or bring about a moral dillema. OTHER SECURITY ISSUES ON MELPA: =============================== For me largest security problem on MELPA is that Github.com is run by Microsoft, we have no idea what principles they share beyond commercial principles, and the more Emacs packages are hosted on Microsoft Github, the more probability is there for mischievous conduct or security breaches. Same can be said for hosting providers that value free sofware, security breaches are possible, but then we would know that people maintaining the server do care of users enough, to prevent mischievous conduct. A package can be thus accepted in MELPA and become approved, then later continuously updated, meaning without any control or supervision, and then automatically offered to users. Backdoor can be injected into users' Emacs and run on their computers. If I am wrong on how MELPA works, you may tell me, that is what I understood from their website. SO FAR I KNOW there is no system of signing packages and verification of such. I have verified MELPA git, and I cannot find that they are using GnuPG or gpg or other system that packages were really made by the author they claim to be made. This may be true at GNU ELPA too, I did not verify it, but I know at that GNU ELPA is not automatically built and offered to users blindly without verification (I at least believe they are verified). 1. Github.com may not even know if somebody cracks some developer's account and changes few packages to misbehave, if they would be alerted, they would not maybe act in the best interest of the free software project, they would act in their own best interest. 2. MELPA managers do approve only GNU GPL or GPL compatible software to be included, they do not however continually verify or control the software, in fact they pull it by using recipes and build it automatically and offer automatically to users. Users in turn accept blindly packages, even though there is no mechanism to make sure that package was made by the author that was approved by MELPA. Let us say MELPA could maintain the list of public keys of authors, and then accept only packages that are signed by those same authors, before having them built, this would increase security this security issue, but not solve it, if packages are not verified by human. 3. Other issue is that users cannot trust MELPA only, as packages should be distributable from MELPA to other repositories, so each single package should be verifiable by user as well. It is written in the Emacs manual: 41.4 Creating and Maintaining Package Archives, that: Maintaining a public package archive entails a degree of responsibility. When Emacs users install packages from your archive, those packages can cause Emacs to run arbitrary code with the permissions of the installing user. (This is true for Emacs code in general, not just for packages.) So you should ensure that your archive is well-maintained and keep the hosting system secure. One way to increase the security of your packages is to “sign” them using a cryptographic key. If you have generated a private/public gpg key pair, you can use gpg to sign the package like this: gpg -ba -o FILE.sig FILE But it is not implemented into Emacs to verify packages being signed, so my proposal is that Emacs get obligatory verification of a package if such package is arriving from any repository and to warn user if package was not signed. This would give initiative to MELPA to start thinking about security issues. That is one of reasons why Hyperbola GNU/Linux-libre and other GNU/Linux distributions package some major Emacs packages, as that way the package maintainers verify the package before it is included in the free software distribution. In the same manner Emacs should have a built-in package installation procedure (that can be circumvented by users' configuration) to verify all packages being installed by default. Jean