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 00:01:22 -0400 Message-ID: References: <874k2x8jhb.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="11187"; 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 06:02:53 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 1nfDAa-0002k7-Rg for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 06:02:53 +0200 Original-Received: from localhost ([::1]:36610 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfDAZ-0001Io-IJ for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 00:02:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60782) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfD9H-0008KT-BT for emacs-devel@gnu.org; Fri, 15 Apr 2022 00:01:31 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32152) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfD9E-0002eB-Fb for emacs-devel@gnu.org; Fri, 15 Apr 2022 00:01:30 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1D3F4100184; Fri, 15 Apr 2022 00:01:26 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EA085100006; Fri, 15 Apr 2022 00:01:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1649995283; bh=ZKBz0d+kV+Jrz1tohjS3Qhdt6tSk2sju/t/56Zcm+ms=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Uft4we6bb/qJAQs36aULrvoBgJcZLzj2YbzbnvgM6RLoqwT8zlFaY7+nDtB7u941i Pn9n2qhzsQ06nnf2cXblQFdHqcnQVtMFZmStEJOUB+PcoixZJKgct2yBHRd6D0gu8U /R9yjHfHIMr0nB6nSTk0YnK6ZccLxA6JWyMFLicJ516pg0ko1y2uqek5KSpf3hAsVG 27ITn5O2F3AkT35s/ZZ30SIHeOtyAA8EtsVsh4tgTDblNVZ6NdQGjI1LorHeJPkULP aW5owfnS1D/F9OCz8p/ozXTxwpR9oqqF3e0UTgFaLANNM4hw5cyVTMd9NIdq98jtRq mPgSd9Boy6sYQ== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B4BBF1201B2; Fri, 15 Apr 2022 00:01:23 -0400 (EDT) In-Reply-To: <874k2x8jhb.fsf@posteo.net> (Philip Kaludercic's message of "Wed, 13 Apr 2022 08:40:00 +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:288418 Archived-At: > The somewhat recent addition to render markdown caused an error when > building a package locally on my system, as the executable "markdown" > was not installed. So I gathered a number of implementations and > had had `elpaa--section-to-html' use whatever is installed: I wouldn't work that hard at it: I think the only important part of the behavior is either "reproduces faithfully what will happen on elpa.gnu.org" or "doesn't fail stupidly", so rather than try out all the possible alternatives the most important part is to fail gracefully. > +(defvar elpaa--markdown-candidates > + '("pandoc" "cmark" "marked" "discount" ;ideally > + "lowdown" "hoedown" "sundown" "kramdown" ;backup > + "markdown.pl" "markdown_py" "md2html.awk" ;fallback > + "markdown" ;despair > + )) 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`. > - (elpaa--call-sandboxed t "markdown" input-filename)) > + (elpaa--call-sandboxed t (elpa--markdown-executable) input-filename)) I think this is more than 80 columns, please wrap. > +(cl-defmethod elpaa--sandbox-args ((_mechaism (eql bwrap)) args) > + (let ((dd (expand-file-name default-directory))) ;No `~' allowed! > + (setq args (cl-list* "--bind" dd dd args))) > + ;; Add read-only dirs in reverse order. > + (dolist (b (append elpaa--sandbox-ro-binds elpaa--sandbox-extra-ro-dirs)) > + (when (file-exists-p b) ;`brwap' burps on binds that don't exist! > + (setq b (expand-file-name b)) > + (setq args (cl-list* "--ro-bind" b b args)))) > + (append (list "bwrap") elpaa--bwrap-args args)) > + > +(cl-defmethod elpaa--sandbox-args ((_mechaism (eql guix)) args) > + ;; Indicate the remaining arguments are the command to be executed. > + (append (list "guix") elpaa--guix-args (cons "--" args))) There's a typo "mechaism". More importantly, I understand that `elpaa--sandbox-ro-binds` doesn't need to be passed to `guix shell`, but I don't understand why `elpaa--sandbox-extra-ro-dirs` would not be needed either. > (defun elpa--markdown-executable () > (catch 'exists > + (when (eq elpaa--sandbox-mechanism 'guix) > + ;; When using Guix, we can ensure what markdown implementation > + ;; we want to use, so we just return a fixed one here. > + (throw 'exists "cmark")) > (dolist (cmd elpaa--markdown-candidates) > (when (executable-find cmd) > (throw 'exists cmd))) I think this optimization is not worth its cost. > This approach could also be extended to Nix/nix-shell, but I have no > experience with that tool. 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`. 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. > (On a related note, is it necessary to sandbox markdown rendering? It's necessary if (like me) you don't want to try and convince yourself that it's currently unnecessary nor want to depend on that fact remaining true in the future. > 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. > If these changes are fine, I can push them myself. Feel free, Stefan