On Sun, 2023-06-04 at 13:31 -0400, Mike Gilbert wrote:
> This allows users to maintain the saved config file in some other
> location.
>
If so, the symlink should point to a superuser-only location to avoid
creating any new vulnerabilities. We can't fix the general problem, but
we could at least
These variables are usually defined as:
$ fgrep RELEASE_WITH_DEBUGINFO /usr/lib64/qt5/mkspecs/common/gcc-base.conf
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += $$QMAKE_CFLAGS_OPTIMIZE -g
QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO +=
$$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
This allows users to maintain the saved config file in some other
location.
Also drop the recursive (-R) option; this cp command is only executed
when we are restoring a single regular file.
Closes: https://bugs.gentoo.org/907696
Signed-off-by: Mike Gilbert
---
eclass/savedconfig.eclass | 4
Michael Orlitzky writes:
> If so, the symlink should point to a superuser-only location to avoid
> creating any new vulnerabilities. We can't fix the general problem, but
> we could at least mention in the docs that symlinks will (now) be
> followed and that users should be careful if they want
On Sun, 2023-06-04 at 20:46 +0200, Arsen Arsenović wrote:
>
> I believe that the target directory of this cp can be considered
> equivalent in terms of access to any superuser-only directory, so I'm
> not sure I see the problem with this change.
It silently changes something that was safe (but
On Sun, Jun 4, 2023 at 2:03 PM Michael Orlitzky wrote:
>
> On Sun, 2023-06-04 at 13:31 -0400, Mike Gilbert wrote:
> > This allows users to maintain the saved config file in some other
> > location.
> >
>
> If so, the symlink should point to a superuser-only location to avoid
> creating any new