From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Patches for elpa-admin Date: Fri, 15 Apr 2022 10:40:08 -0400 Message-ID: References: <874k2x8jhb.fsf@posteo.net> <87czhiddc7.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39357"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: ELPA Maintainers To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 15 16:41:14 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 1nfN8L-000A4k-Lm for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 16:41:13 +0200 Original-Received: from localhost ([::1]:60376 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfN8K-00080x-GY for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 10:41:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfN7U-0007L2-H2 for emacs-devel@gnu.org; Fri, 15 Apr 2022 10:40:20 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47312) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfN7N-0004Cr-LJ for emacs-devel@gnu.org; Fri, 15 Apr 2022 10:40:16 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 80F1D100184; Fri, 15 Apr 2022 10:40:11 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F405110013B; Fri, 15 Apr 2022 10:40:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1650033610; bh=PBDPZUxtDfb+TTY3JbszruFl0PkvH8ThyJLD1+yIlNs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Lt/UZNJ1NqbnZa0kgcdrMwwQMayJMgQgZog7UcHHifMz9F5dMPtqcI7x+ZMY1fylm e2ePPMPlQEJxk259EWlTajSyjt9C81wx20J3QCs/A/X6Q/fCt0JmXpVfOB9FJluAtN Nl7CkykvpE2rn6GMt3oBbFQzbNQR3pI8gg5N9jFgRnuTf/2Q+hoO2gp55b8hN9b1Os fk/wlxPyRaYF0danqkGQspC+510xbfXO6HSxM7s8l8QY7Bis/DyZHjTyqTgDDx+1Gr +5PpYWiSA9iPTDmj6qGwI/cjrRH8p48jdUvja9FpT1ickZ/Xb2mSeFAMYO3mjlS4fW R/zBNsxaQB3BQ== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CCF6812023B; Fri, 15 Apr 2022 10:40:09 -0400 (EDT) In-Reply-To: <87czhiddc7.fsf@posteo.net> (Philip Kaludercic's message of "Fri, 15 Apr 2022 07:18:16 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:288442 Archived-At: >> I think this list is "a bit over the top", but feel free to keep it. >> OTOH, I think "markdown" should come first since that's what's used on >> `elpa.gnu.org`. > > On that topic, what program is markdown? On Debian there seem to be a > number of alternatives: > > $ apt-file search /usr/bin/markdown | grep /markdown$ > discount: /usr/bin/markdown > libtext-markdown-perl: /usr/bin/markdown > markdown: /usr/bin/markdown It's `markdown` :-) > Considering that more often than not what we are actually rendering is > "GitHub flavoured markdown" (https://github.github.com/gfm/), it might > make sense to use an implementation that takes this into consideration. There are indeed a few pages which rely on features not supported by `markdown` :-( `elpa.gnu.org` mostly uses `markdown` because I have no idea which implementation is better/worse, so I went with the "obvious" choice. >> I think this optimization is not worth its cost. > The reason I had to add this was that if using Guix, I cannot rely on > `elpa--markdown-executable' to find what is installed, since that is > evaluated on the host system. Oh, right, I see, sorry. But I guess this argues against auto-discovering which executable to use and just rely on an `elpaa-markdown-program` configuration variable instead (and catch an execution error, for graceful degradation). >> To be honest, I'm not thrilled about adding support for more container >> systems to `elpa-admin.el` because it's not its focus. The containers >> are important on `elpa.gnu.org` because I'm a bit paranoid about running >> arbitrary software on a central server that could conceivably be >> a target for an attack. But for most other uses it seems that setting >> `elpaa--sandbox` to nil will do the job just fine if you don't want to >> install `bwrap`. > > It is not only that, it is also the dependencies that someone might or > might not have installed when wanting to contribute to ELPA. By using > Guix, the right tools are automatically provided, which could also be > extended for non-sandbox elpa--call invocations. The error messages > generated if something goes wrong (e.g. missing makeinfo/install-info, > imagemagick), can be hard to parse, and this approach just circumvents > the issue entirely. You mean to help the users get their local build to work even when they don't have all the needed packages installed? Or do you mean to help the users get their local build to fail when they rely on packages not available in `elpa.gnu.org`? Or both? Maybe this can be obtained more reliably with a `guix shell` call wrapping the whole Emacs invocation rather than only wrapping the sandboxed subprocesses? [ You might be able to specify the same Emacs version as the one installed on `elpa.gnu.org`. ] >> More interesting would be to add support for this kind of sandboxing in >> Emacs itself (so ELisp's Flymake support can use it); and some years >> from now `elpa-admin.el` will then be able to ditch its own sandboxing. > I have actually been looking into implementing a TRAMP backend that > would tunnel all communication through a Guix shell. I think in that > case Flymake should be able to make use of that. That sounds nice. We'd need a solution that can be made to work "everywhere", so the API should be sufficiently generic that it can make use of various sandboxing systems. >>> I understand why org can be dangerous, but markdown shouldn't be able >>> to have any side effects?) >> Yes, and 640kB should be enough for everyone. > Ok, I see. BTW, if we do opt for a more fanciful markdown processor, I wouldn't be surprised to hear that some of them do "funny" things like follow some of your symlinks (e.g. to give you warnings if they point nowhere) ;-) > I will wait a bit to implement the changes i mentioned. Looking forward to them, thanks. Stefan