From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vasilij Schneidermann Newsgroups: gmane.emacs.devel Subject: Re: Proposal to include obligatory PGP verification of packages from any repository Date: Mon, 19 Oct 2020 20:28:28 +0200 Message-ID: <20201019182828.GB1842@odonien.localdomain> References: <20201013052736.GE31408@protected.rcdrun.com> <20201016130235.06218dae@argon> <87eelvplvh.fsf@posteo.net> <10bdf4ea-e365-cc3d-ec03-4348946fadbe@yandex.ru> <20201019124335.GC19325@protected.rcdrun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25966"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Philip K." , rms@gnu.org, thibaut.verron@gmail.com, mve1@runbox.com, emacs-devel@gnu.org, Dmitry Gutov To: Jean Louis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 19 20:30:28 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 1kUZvP-0006bU-6G for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 20:30:27 +0200 Original-Received: from localhost ([::1]:38686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUZvO-0006g0-8k for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 14:30:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUZtn-0005sx-FH for emacs-devel@gnu.org; Mon, 19 Oct 2020 14:28:48 -0400 Original-Received: from mout-p-102.mailbox.org ([80.241.56.152]:26458) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1kUZth-0004eA-7L; Mon, 19 Oct 2020 14:28:45 -0400 Original-Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4CFQHj7218zQjbV; Mon, 19 Oct 2020 20:28:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id hkN3i0nfkkQi; Mon, 19 Oct 2020 20:28:29 +0200 (CEST) Mail-Followup-To: Jean Louis , Dmitry Gutov , mve1@runbox.com, "Philip K." , rms@gnu.org, thibaut.verron@gmail.com, emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <20201019124335.GC19325@protected.rcdrun.com> X-Rspamd-Score: -7.64 / 15.00 / 15.00 X-Rspamd-Queue-Id: 7AD94181E X-Rspamd-UID: 25dbb5 Received-SPF: pass client-ip=80.241.56.152; envelope-from=mail@vasilij.de; helo=mout-p-102.mailbox.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 14:28:34 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01 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:258139 Archived-At: --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As someone working in information security, I feel compelled to reply to this in detail as your email contains several claims I am not comfortable with being taken at face value. > 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. There is a difference between trying (enabling LibreJS and looking at how many scripts it blocked) and trying (enabling LibreJS and actually using the website while paying attention to how functional it is). Out of curiosity I've attempted the latter as it's a more meaningful test, using the latest version of Firefox Developer Edition on Arch: - Repositories can be created - Issues can be created - Forks can be created - Pull requests can be created, with the limitation that the merge preview is broken. This doesn't matter though as it's up to MELPA maintainers to review the pull request. - Account creation is broken. I can fill out the first screen (username, email address, password), then get stuck on the second screen as it relies on an external CAPTCHA service. I suspect I can complete the process by temporarily allowing the JS script and continue contributing to repositories, but haven't verified that part. My verdict so far: Github almost passes the test. If one does have an account already (from what I've seen you do), there is no excuse for you to not contribute. If one doesn't, they'll have to ponder whether whitelisting the CAPTCHA is worth it. > 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. =46rom a security perspective it's a bad idea to use any browser outside of the main stream as only the largest browser vendors manage keeping up to speed with security issues. While one can use a browser based on them, there will be issues. As a side point, Debian settled its trademark dispute with Mozilla and no longer offers rebranded versions of Firefox. Therefore Debian users will not face browser incompatibility problems and avoid such security issues. Something else worth trying is hub [1]. It seems to allow performing the expected contribution workflow from the command line. > 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. >=20 > 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. This is a regrettable aspect of MELPA (although I disagree with non-free JavaScript or security being a problem), I don't have expectations for it to change as MELPA's philosophy revolves around the central principle of going with the most convenient mode of operation for developers to publish their packages: - Use Github, the most popular gratis Git hosting service - Use Github's contribution workflow (forking and "pull requests") - Automatically fetch packages from developers (as opposed to having them submit/upload new versions) - Automatically rebuild packages after each detected commit - Remove support for unpopular alternative workflows to reduce maintenance effort (Emacswiki, Bazaar, CVS, Darcs, Fossil, Subversion) One does not share a package on MELPA to further the goals of the free software movement, one does so to reach as many Emacs users as possible with relatively little effort (which excludes GNU ELPA, we'll have to see whether the same holds true for non-GNU ELPA). > 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. Savannah does not strike me as an adequate alternative for people used to Github. For starters it requires approval of each project before it's publicly visible. I'll have to do a proper evaluation of it though before I can comment further on this aspect. Gitlab is the closest equivalent, though not perfect either. For minimalism and integration of an email-centric workflow sourcehut looks ideal, once it leaves its alpha status. > 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. >=20 > That would be right direction to go for MELPA.=20 >=20 > 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. As elaborated above, it is unlikely to happen. Adherence to GNU principles for non-GNU projects is not a priority. See also the MELPA maintainers' response to a thread you've created [2]. > 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. >=20 > 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. >=20 > 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. >=20 > 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. This is an interesting idea, though it will require continuous updates for best effect. Even if it doesn't prove to be effective in practice, having a detailed list of what exactly is a problem to one's freedoms would be a useful side effect for users caring about this. > 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. >=20 > 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. This argument does not follow. A code forge can have security issues, no matter whether its code can be freely audited or the political alignment of its owners. Merely being concerned about free software doesn't mean that security issues will be investigated and acted upon, neither does ownership by an entity pursuing different goals mean it will neglect security issues. I've briefly looked into Savannah's source code and found enough evidence of it not being securely designed and requiring an in-depth source code review. While talking to a security-related contact person I've been told that there was indeed a little-known security breach long time ago. Linus' law [3] seems a more appropriate hypothesis to explain this behavior, depending on the visibility and amount of people actively looking into a code forge, there will be more publicized security incidents and attempts to improve overall security of the project. Freedom and political alignment of the project are at best tangentially related. > 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. That is indeed correct, there is no further quality assurance after the initial submission. It takes a significant amount of time for that submission to be verified due to the few reviewers and given the sheer amount of packages (4750 packages at the time of writing), I do not see this working out with their current team. For comparison, Arch has "Trusted Users" responsible for their official packages, with anywhere between 5 and 90 packages assigned to each of them. Rest assured that they don't perform security audits, only basic quality assurance as packages are updated and bugs trickle in. Having the kind of work force a GNU/Linux distribution has is a luxury, not something to take for granted. That aside, how does this quality assurance look like for GNU ELPA? Is it users subscribing to a commit mailing list and looking out for anything suspect? Fewer releases overall? A basic level of vetting by asking for copyright assignment? I doubt that code is audited for every release either and that security issues are instead dealt with in a reactive instead of proactive manner (meaning, as soon as one is known of, appropriate measures such as a security release are taken). There is a lot more work to be done here, such as defining a comprehensive threat model to work with. Another important aspect: Say that non-GNU ELPA manages to catch up with MELPA in terms of package count, does the existing review system still work? Will new measures be necessary to guarantee security (for example by designing packages in terms of a more restrictive approach with permissions, sandboxing and whatnot)? I strongly suspect that they will be and merely mirroring MELPA packages won't suffice. > 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). As mentioned above, MELPA's principle of going with the most convenient option makes this a non-starter. Vetting package authors for their identity, requiring a GPG key and signed releases is something I'd rather expect for GNU ELPA than them. > 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. Github offers 2FA to protect accounts and has a dedicated security team reacting to incidents. I don't see signs of either for Savannah. The only point in favor of Savannah is it being relatively unknown and therefore of less interest to attackers, but I wouldn't rely on that as my only level of defense. That aside, it's not even necessary to hack an account to distribute malicious software. Popular package archives for other programming languages have seen attacks such as typo squatting [4]creating (uploading a package with a misleading name) and hostile maintainers [5] (where a package is transfered to a new maintainer who then abuses the trust created by the package by adding malicious code to it). I have to confess I've pondered creating a malicious package for demonstrating how easy it would be to sneak something in without anyone noticing, but I'm afraid it will only lead to more emails sowing Fear, Uncertainty and Doubt. Or people weaponizing the code, not sure is likelier. > 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. For this to be effective, one needs to build upon trust. I doubt the average Emacs user has thought in depth what package developers to trust and whether they should verify packages installed to come from them. And again, with MELPA's philosophy being one of convenience, I don't see that happening. > One way to increase the security of your packages is to =E2=80=9Csign= =E2=80=9D 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: >=20 > gpg -ba -o FILE.sig FILE >=20 > 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. Emacs does have basic verification already, but it is far from ideal. The failure case is not handled well at all, users are not told what to do when it fails verifying a package and are inclined to instead disable the mechanism once and for all. If an Emacs is too old to contain the appropriate GPG keys, the keyring will be needed to be updated outside of Emacs, a task that can fail for opaque reasons due to key servers being unreachable. There is initial work in form of the gnu-elpa-keyring-update package distributed via GNU ELPA, but it suffers =66rom a bootstrapping problem and needs to be installed *before* the keys become outdated. Until this issue is solved, I cannot imagine making this opt-out or even mandatory. For comparison, Arch ships its own package manager specific GPG keyring and updates it during each package update operation. [1]: https://github.com/github/hub [2]: https://github.com/melpa/melpa/issues/7185 [3]: "Given enough eyeballs, all bugs are shallow." [4]: https://incolumitas.com/2016/06/08/typosquatting-package-managers/ [5]: https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backd= oor/ --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAl+N2sMACgkQFmfJg6zC ifo2/gf+MG75GloKUUcW9Yvv/DYM8RyS256Ayy2pAxskDArVzj45lFimjS5TI+Le zWPS6sFrf696kexsH2XZxSqsQzaoOeMuYfN7UPMPQqubjWV1yEe76kLX2xpGIXFA zEVAMmmHb9rI32dj6tXNU/MevIVuBgc+BQSvLvosfh/bQtl+DxgE0tZQbEiwu+0Z +kfCEKU6PTKe7Z4qKkfOLJIV8pGOyOyOd0fksZKLYTvfIlVGKi089dCfqPZNWA7h Q/U3Ic1xUlojKlNcJkVNCk4AH1tUhTED/0l+xy3isKh46ry6fVYE7wCtbzu3ZFRd 8UxTkdo/MyyGEVTIT/s79tApMOLR+Q== =Laux -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ--