Hello Jonathan,

Just to emphasise again that the team's code is working at the macro 
layer, and that the facilities for shell escape are controlled by the 
engines: as such the TeX Live list may be a better place to discuss some 
of this. That said, I'll cover what I understand in this area. (The 
cautious user will of course have shell escape entirely disabled.)

>> Once one allows unrestricted shell escape, all bets are off in terms of
> what
>> an arbitrary package can do.
> 
> Your implication is that "restricted shell escape" both
> 
>     1. reduces what an arbitrary package can do
>     2. improves security
> 
> Please provide some evidence for (1), by for example providing references
> to the source code and tests.

The point is that *restricted* shell escape only allows a pre-defined 
list of commands to be executed. As such, there is no possibility of 
calling, from within the TeX run, commands which have not been 
pre-authorised. As I understand it, the idea of providing restricted 
shell escape is that it gives the user some option between 'nothing at 
all' and 'complete access to the system'.

In my stock TeX Live 2018 set up, texmf.cnf has the following to say on 
restricted shell escape commands

% The programs listed here are as safe as any we know: they either do
% not write any output files, respect openout_any, or have hard-coded
% restrictions similar to or higher than openout_any=p.  They also have
% no features to invoke arbitrary other programs, and no known
% exploitable bugs.  All to the best of our knowledge.  They also have
% practical use for being called from TeX.
%
shell_escape_commands = \
bibtex,bibtex8,\
extractbb,\
gregorio,\
kpsewhich,\
makeindex,\
repstopdf,\
texosquery-jre8,\

% we'd like to allow:
% dvips - but external commands can be executed, need at least -R1.
% epspdf, ps2pdf, pstopdf - need to respect openout_any,
%   and gs -dSAFER must be used and check for shell injection with 
filenames.
% pygmentize - but is the filter feature insecure?
% ps4pdf - but it calls an unrestricted latex.
% rpdfcrop - maybe ok, but let's get experience with repstopdf first.
% texindy,xindy - but is the module feature insecure?
% ulqda - but requires optional SHA1.pm, so why bother.
% tex, latex, etc. - need to forbid --shell-escape, and inherit openout_any.

I know there have been discussions on the TL list about those commands 
in the 'allowed' list: it's certainly outside my area-of-expertise to 
comment on them in this regard.

> By the way, the usual meaning of "restricted shell escape" is as in
> https://en.wikipedia.org/wiki/Restricted_shell. This page tell us: The
> restricted shell is not secure.
> 
> The TeX/LaTeX community has a different meaning for "restricted shell
> escape". As you are using the term in this new way, please would you
> provide a definition.

As I say, it's the list of commands that can be called which is itself 
restricted. Again, I leave it others to detail whether a shell program 
is actually called at all here (sh or cmd.exe), or if a system call is 
made to run the requested command.

> Please also would you discuss:
> http://tex-live.tug.narkive.com/1iD2CkdT/security-issues-for-restricted-shell-escape

I note that this is from the early days of implementing a restricted 
version of shell escape. As quoted above, current texmf.cnf excludes 
many commands that are on the list in that thread.

All of this is somewhat moot for the question-at-hand: operations such 
as 'copy a file' or 'remove a file' will only ever be available when 
shell escape is unrestricted. The question then is what, if any, 
wrappers to provide to users who have decided to allow such calls.

Joseph