Re: Patches for elpa-admin

[Philip Kaludercic <philipk@posteo.net>]

Stefan Monnier <monnier@iro.umontreal.ca> 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