Johannes Meixner

Obviously the check that each file which is included in the ReaR recovery system must pass this function happens during "rear mkrescue" for the original file on the original system...

Now back to SUSE work - I have no time for discussions here.

When an intruder has a root shell all is lost. I think protections in programs against malicious users are based on the assumption and precodition that those users do not...

ReaR should not and must not source user-controlled files. That's the whole point of this issue: To avoid that by accident ReaR may read or (partially) execute a file from...

Currently the only "line of defense" is the file name. E.g. /etc/os-release is hopefully safe to be read. But we have no runtime check that ensures a file actually (still)...

See also https://github.com/rear/rear/issues/3259 which is the more generic "parent" issue. This one here is more a derived "child" issue.

@FilippoBonazziSUSE you may have a look at https://github.com/rear/rear/issues/3259#issuecomment-2220432936

Possibly we have some kind of "all-clear" signal for ReaR: I think meanwhile I found sufficient evidence which shows that "all other software" behaves basically same as ReaR currently does....

@FilippoBonazziSUSE regarding your https://github.com/rear/rear/issues/3260#issuecomment-2220864142 ``` ... minimise the number of scripts that are sourced (I understand there are currently 43). ``` Not exactly. According to https://github.com/rear/rear/pull/3203#issuecomment-2063439858 I found 43 places...

@schlomo regarding my https://github.com/rear/rear/issues/3260#issuecomment-2227956786 Don't get your hopes up too soon! I only meant that currently ReaR is not worse than "all other software" BUT I fear that basically "all...