From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS Date: Sat, 08 Oct 2022 16:20:30 +0000 Message-ID: <877d1aqoc1.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <20220214140020.04438C00891@vcs2.savannah.gnu.org> <87bkqmqpvb.fsf@posteo.net> <871qris3xb.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3999"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 08 18:21:38 2022 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 1ohCa2-0000qt-Fj for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Oct 2022 18:21:38 +0200 Original-Received: from localhost ([::1]:54466 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohCa1-0004MY-CF for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Oct 2022 12:21:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohCZ1-0002xI-8V for emacs-devel@gnu.org; Sat, 08 Oct 2022 12:20:35 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:40285) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohCYz-0000Xt-5O for emacs-devel@gnu.org; Sat, 08 Oct 2022 12:20:34 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id BAD9F240101 for ; Sat, 8 Oct 2022 18:20:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1665246031; bh=eTQNNg3zHi4a/GGCRzNnK7Vu6Hkt5a2EJBBV8rRDpJA=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=d8/VbDaHhfB9P+Cl4HsZNfHVG8+dOTi/57ELKpGjyNc7F3ZB3PRVrYM5X47+Dcz2w nihhiMn8u/kz8/L7pc3ZmqB6NSQ0ZI27vMdHajuYuW8OXdzNO6dcMf5XUPKwxK/a4p 8mTVSHPUCX+yEBDkyeOvQfveLmQ2JKR8tBCAnTQlXZHowj1BsiQAdOAKgTRmeUNXBZ i7zY69pAXxRommq90CCmKBmSFkaNb8HhFkuVeYxGcAtll6LXBBGj4/00yWWdYkQvc1 7icbHP+biiZWMxZVCaAqc65TkDsNBmYBIhgC/ClEhFL57ibpZsnJQSnbc8rnQWQRfS 0sTzDbCP8658A== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Ml9Q70Y38z6tnf; Sat, 8 Oct 2022 18:20:31 +0200 (CEST) In-Reply-To: <871qris3xb.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 08 Oct 2022 17:58:24 +0200") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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.29 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:297208 Archived-At: Lars Ingebrigtsen writes: > Philip Kaludercic writes: > >> - The ability to install a package directly from source using >> `package-vc-fetch' (aliased to `package-checkout'). This >> functionality is ideally VC generic. >> >> - The ability to update a package using `package-upgrade'[0] >> >> - Package metadata can either be inferred from the package URL (see >> `package-vc-heusitic-alist') or via explicit hints from an ELPA >> server. I plan to add the necessary features to GNU and NonGNU ELPA >> in time so that the heuristics can be avoided. >> >> - The ability to (i) contact, (ii) send bug reports and (iii) patches >> (using the new `vc-patch-prepare') to package maintainers. > > Sounds like great functionality, but I wonder whether the security > implications have been discussed? Today, we use GNU ELPA as a filter of > sorts and people rely on code there not being compromised. It seems to me that fetching a package from source is no more dangerous than fetching a tarball, seeing as the tarball is automatically generated from the repository. But I might be mistaken, in which case I'd be interested in what should be done to improve security. > I assume "hints from an ELPA server" is basically a list of links to git > repositories? The hints would be an entry in the package property list consisting of the following items: (VC-BACKEND REPOSITORY DIRECTORY BRANCH) Packages with either this metadata or that are caught by the heuristic are automatically proposed as completion options when invoking `package-vc-fetch'. Of course it is also possible to give an arbitrary URL, but at that point you should know what you are doing. > If that's the case, then we may well end up with pointing > users towards repos that have been compromised. Just so that we are on the same page, what are we talking about when using the term "compromised"? In what sense would this not affect a package that we fetch directly from source but not a tarball? > If we don't have such a list, then adding the basic functionality sounds > useful anyway -- that is, allowing users to say `M-x > package-install-from-repo' or something and then they type in the URL of > that repo -- that's fine, and leaves the security implications to the > user (where they already are today for people that install from external > repos). Yes. > But if we list these repos in `M-x list-packages', that's a very > different issue. No, the list-packages would still only list packages that are listed in the package archive + packages that have already been installed using `package-vc-fetch'.