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: On using packages from ELPA - was Re: Loaded, but not yet working - Re: Loaded icicles, thanks Date: Tue, 17 Nov 2020 11:03:59 +0300 Message-ID: References: <0a3a95d5-c97b-4efb-ac5a-d4562a3d235a@default> <1259004e-3d8a-47d9-874a-c0b506ec1c3b@default> <5ec19618-1a97-49bd-afec-649b8fa2456c@default> 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="37235"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 17 10:49:03 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 1kexbi-0009ZJ-Px for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 10:49:02 +0100 Original-Received: from localhost ([::1]:53206 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kexbh-0005fE-Oa for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 04:49:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kexaE-0004DB-13 for emacs-devel@gnu.org; Tue, 17 Nov 2020 04:47:30 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:60155) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kexaB-00088j-KQ for emacs-devel@gnu.org; Tue, 17 Nov 2020 04:47:29 -0500 Original-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 00000000002C0010.000000005FB39C2D.00007315; Tue, 17 Nov 2020 09:47:24 +0000 Content-Disposition: inline In-Reply-To: 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/11/17 04:47:25 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:259281 Archived-At: I may copy this to emacs-devel so that in Emacs development we learn from it, if there are points to be learned. * Drew Adams [2020-11-14 20:00]: > I pointed out in the text I pointed you to that pulling from GIT is > not necessarily safe. Their point is that you can know that the > file is from the person who put it on GIT, because there's a > signature. I pointed out that nothing prevents someone from > providing malicious code on GIT. That is right, I am aware of that. There are already many cases of security breaches, including that source for Github is also leaked. Locking EmacsWiki pages by 2 people friendly to Emacs sounds to me much safer than pulling automatically packages from git repositories and injecting them semi-automatically into user space of maybe millions of users. As when users update packages that is semi-automatical, it is not fully automatical. And they blindly trust MELPA packages which in turn are not even signed. MELPA is a loop that automatically pulls new packages, builds them and provide to users. There is no human review process once package has been accepted to MELPA. They accept packages from anonymous authors without any consideration of their Even Github and many Git repositories there provide releases.tar.gz and that in general is classic package release method. git is for development, it is not for releases. Release packages may have difference in their structure. Demanding git only to provide package is kind of coercing programmers to change the common ways of providing releases. As git is for development and versioning, not for final releases. Release does not mean "development version". Not to me. Package release may be from date 2020-02-01 while development version may be from 2020-10-01 Demanding the public git repository to be the "package" is disrespecting the author's opinion on what should be released as package or not, as author most probably wish to release stable package and not development version. In that sense, and I may be wrong, MELPA is decreasing safety for millions of users as it misses the author's opinion if the package is ready or not for the release. Emacs packages are made by convention as described in Emacs Lisp file and it has been pretty much followed how I researched it for decades already. It is either .el or .tar package I hope that we will not adopt automated blind git pulling to GNU ELPA or new to come non-GNU ELPA. > My files are locked on the wiki. But that wasn't deemed safe > enough. I think also (and maybe it's only) that they didn't want to > bother with recipes for wiki libraries. Whatever the reason, that's > the way things are. > > > I think many authors like you, should have your own ELPA. You can as > > well make it on EmacsWiki in your directory if you follow > > guidelines. Then sign packages with your key, that is it. Packaging is > > explained in Elisp manual. > > No doubt I should at some point use GIT, but I'm an old > dog, set in my lazy ways. When I said: your own ELPA, I reference it to Emacs Lisp manual 41.5 Interfacing to an archive web server ========================================= A web server providing access to a package archive must support the following queries: archive-contents Return a lisp form describing the archive contents. The form is a list of ’package-desc’ structures (see ‘package.el’), except the first element of the list is the archive version. -readme.txt Return the long description of the package. .sig Return the signature for the file. Return the file. This will be the tarball for a multi-file package, or the single file for a simple package. So all your packages on EmacsWiki can as well be more conveniently distributed from Emacs Wiki where they could also ask for dependencies correctly. All what you need to do to construct above. File names you already have, README you can construct from pages already written, signatures ARE necessary and would increase safety feeling to users and archive-contents would tell about dependencies and all list of packages. Then all you tell to users is to update package-archives and include something like https://www.emacswiki.org/wiki/DrewAdams/elpa and users would get all list of packages and would download them through Emacs from EmacsWiki by using M-x package-install That way author: - has decided to publish packages, as person thinks packages are good for use, - package is thus not development version (nightly or weekly, etc. or for developers only) that is not ready for public, package is thus ready for public usage - packages are signed and verified that author or maintainer decided to publish them, increasing safety, lessening doubts Is there a function that automates construction of package-desc structure?