x11-libs/vte writes scrollback to /tmp which can be (on) a partition on a harddrive and enable someone to use for example "strings /dev/sd*" on that and retrieve scrollback history even if that data is not stored in plain files. the issue is discussed here: https://bugzilla.gnome.org/show_bug.cgi?id=664611 https://bugzilla.gnome.org/show_bug.cgi?id=631685 https://bugzilla.xfce.org/show_bug.cgi?id=8183 Unless someone uses unlimited scrollback I guess the desired behavior is to write those data to RAM by default. This can be controlled by the TMPDIR environment variable ofc, however the _default_ location for that should not be /tmp. The attached patch from here ( https://bugzilla.gnome.org/attachment.cgi?id=206579 ) applies and works on 0.28.2 successfully and keeps scrollback history in RAM when /dev/shm is available. Mind that the TMPDIR variable does not work anymore after this patch. I did not test this on other versions yet.
Thank you for the report. I don't think using /dev/shm is the best option, but we will monitor the upstream bugs to see how they respond.
this is still unfixed there is another patch here: https://bug664611.bugzilla-attachments.gnome.org/attachment.cgi?id=209285
I don't use vte so I can't test. If GNOME team hasn't responded in this long, I'd suggest that you call maintaner timeout and apply whichever patch you think is best.
I haven't tested the second one and this would only fix slot :0. From what I read from the reporter it seems that Konsole is affected as well. I am not really sure how to proceed.
Reading the long discussion in upstream bugs, I am not convinced to apply that patch, as looks like upstream developers have strong disagreement about how to solve this :|
(In reply to Pacho Ramos from comment #5) > Reading the long discussion in upstream bugs, I am not convinced to apply > that patch, as looks like upstream developers have strong disagreement about > how to solve this :| It rather seems they don't really care about it.
so what to do?
I would do the same as Debian, opensuse and fedora: nothing until upstream doesn't move :/
(In reply to Pacho Ramos from comment #8) > I would do the same as Debian, opensuse and fedora: nothing until upstream > doesn't move :/ i don't see how that is a good idea
can we get a vote on what to do here?
x11-libs/vte:2.91, which is the backend terminal library used by gnome-terminal, has been crypting this content for a while now via gnutls (since end of 2014 at least, so since the March/April 2015 stable release at the very least). But on Gentoo only when USE=crypt is enabled on vte (it is IUSE=+crypt), because some users desire to disable this encryption. The security conscious do it when their /tmp is tmpfs or encrypted and swap is encrypted, so it'd be extra work without clear benefits. The security unconcious are able to shoot security in the foot with disabling that USE flag, but hey, that's what they asked then. The temp files are created without being visible on the filesystem, but I'm sure that doesn't stop them being visible in the swap, but at least with vte[crypt], it should be encrypted via some algorithm I don't want to look up right now.
This looks like more hardening than a security bug. However, upstream did fix the users request in a later release as mentioned by leio in the previous comment. https://bugzilla.gnome.org/show_bug.cgi?id=664611 "The scrollback files' contents are encrypted now (using AES 256 GCM), will be released in vte-0.39.2. So marking this bug as fixed." So if any users are concerned with this, and did not take their own hardening measures, then they will receive it as 0.40.x is already stable in tree.
