#1372 Issue closed: Make ReaR safe against blanks or special characters in file and directory names¶
Labels: enhancement, documentation, needs sponsorship,
minor bug, no-issue-activity
jsmeix opened issue at 2017-06-01 08:56:¶
In general ReaR is not safe against whitespace characters
or other special characters or non-ASCII characters
in file and directory names and other names and values
that matter for ReaR (e.g. file and directory names that
are only in the backup should not matter for ReaR).
Cf. https://github.com/rear/rear/issues/580
jsmeix commented at 2017-06-09 10:08:¶
Meanwhile I think it is in practice not worth the effort
to make all the scripts in ReaR safe against blanks
in file names and other values that matter for ReaR.
Reasoning:
ReaR is written in bash and meant to be easily
adapted and enhanced by its users.
Adaptions and enhancements by ReaR users
should be o.k. for ReaR when they work
as usual bash scripts do.
ReaR works how bash works and
bash separates values based on $IFS and
$IFS is by default 'space' 'horizontal tab' and 'new line'.
Therefore for ReaR 'space' 'horizontal tab' and 'new line'
are separators for values and using that separators inside
a single name or value just calls for failures.
Because ReaR is meant that those who use ReaR
are the same as those who adapt and enhance ReaR,
it is in practice impossible to enfore bash scripting rules
so that all is safe against blanks or special characters
in names and values that are used in the scripts.
In particular I will never ever find the time to check
all the scripts in ReaR neither will I find the time to
verify each user contribution whether or not it is safe
against blanks or special characters in names and values.
If someone else will do it - perfectly fine for me - I set
"needs sponsorship" for this part.
But I think it should be documented (which I could do)
that for ReaR 'space' 'horizontal tab' and 'new line' are
separators for values and using that separators inside
a single name or value just calls for failures - I set
"documentation" for this and assign it to me.
schlomo commented at 2017-06-09 10:17:¶
I try to point out in PRs when I think that a variable lacks quoting in
a dangerous way. As test takes only single arguments it is actually
very important to quote there and AFAIK we do so in most or all cases.
IMHO the problem is mostly related to URLs. Since we call them URLs we should consider to also support URI-encoded content of these variables which would probably solve that issue as well.
And finally, I would hope that one of the users who actually has the problem would contribute a PR fixing the files that are relevant to them.
jsmeix commented at 2017-06-09 11:25:¶
Some time ago I had "fun" with URI-encoding
and got almost toast in encoding hell.
I would appreciate GitHub pull requests
that implement such functionality properly in ReaR.
But I won't do that myself (except my employer forced me
because such functionality in ReaR was considered by my
employer to be more important than other things ;-)
For the fun of 'test' it is sometimes very important to not quote there
# foo="" ; test "$foo" && echo foo set || echo foo not set foo not set # foo=" " ; test "$foo" && echo foo set || echo foo not set foo set # foo=" " ; test $foo && echo foo set || echo foo not set foo not set
depending on what empty or blank values actually mean
e.g. whether or not a blank value means the variable is actually set.
github-actions commented at 2020-07-26 01:34:¶
Stale issue message
[Export of Github issue for rear/rear.]