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: Patches for elpa-admin Date: Fri, 15 Apr 2022 15:37:33 +0000 Message-ID: <87k0bq9x36.fsf@posteo.net> 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="10870"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ELPA Maintainers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 15 17:38:32 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 1nfO1o-0002es-ND for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 17:38:32 +0200 Original-Received: from localhost ([::1]:50900 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfO1n-0006nM-BJ for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 11:38:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57258) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfO0y-00065K-I1 for emacs-devel@gnu.org; Fri, 15 Apr 2022 11:37:40 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:39739) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfO0v-0006Vh-Ff for emacs-devel@gnu.org; Fri, 15 Apr 2022 11:37:40 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4EBEB240027 for ; Fri, 15 Apr 2022 17:37:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1650037055; bh=bXO1SD2+DdgMC2ZnDYp69abXnQZr2KCzrbl7Cf8gBKE=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=Lv6ELHz55OtjuHeZXEASbheni1Kdf3sfrQ84xGc1hv/7GHFqat0AeOOqmviT4GDbU gM7arqmf7Bj7PHsjS4NG6Vvg7UY4zmyGAk65VoJyEauGJUoMKVZbM+NP8Zg0go2H6T 1xoOsnbO65ibiJHqI8hUcGlQM/MBfXUuSSgysPt3KvbXhXcog25hIeg+irHBjoQK8p eh6mK5hQufwJDa4vsCjrfJ9MCiRRRe83U7+kI40Q3TKbvLBmb3pNuSzzTGK3LmDcLe raJxfJBMuSmzWtpYFNuHtrcpNIvJdGoMJ+jXmB4XDFuYLDxjP3F4IT7hIvXaPcsXj8 YH6KXMnADFbAA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Kg0np2YVJz6tmN; Fri, 15 Apr 2022 17:37:34 +0200 (CEST) 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 In-Reply-To: (Stefan Monnier's message of "Fri, 15 Apr 2022 10:40:08 -0400") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:288445 Archived-At: Stefan Monnier writes: >>> 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. One alternative would be "pandoc -f gfm". One critical feature here are tables (https://github.github.com/gfm/#tables-extension-) that are just ignored by "markdown". An advantage is that pandoc can then also be used to render "plain text" for C-h P. >>> 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). Sounds good. >>> 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? I was thinking about the first thing, because I don't know what is and isn't provided on elpa.gnu.org (nor what I insinuating that elpa.gnu.org should switch to Guix-containers). > 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`. ] If one were to use the package definitions from https://git.sr.ht/~pkal/guix-emacs-historical, all you would need for this would be to invoke make like $ make -e EMACSBIN="guix shell -L path/to/guix-emacs-historical/ emacs-minimal@26.1 -- emacs" >>> 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'll start a new thread on the mailing list if I ever manage to get something sensible to work. >>>> 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) ;-) Yeah, something like pandoc is feature-rich enough to warrant sandboxing. >> I will wait a bit to implement the changes i mentioned. > > Looking forward to them, thanks. > > > Stefan > -- Philip Kaludercic