This project has moved. For the latest updates, please go here.

Binary ./verac_gui/bin/veracrypt creates hidden folders in home directory (ubuntu)

Topics: Technical Issues, Users Discussion
Jul 2, 2016 at 6:57 PM
Edited Jul 2, 2016 at 6:59 PM
I downloaded and verified the latest version VeraCrypt version 1.17
Then unpacked it and did run ./verac_gui/bin/veracrypt also checking "never save history".

Now I discovered a hidden ~/.VeraCrypt folder storing configurations in an xml like:
<VeraCrypt><configuration><config key="BackgroundTaskEnabled">1</config><config key="BackgroundTaskMenuDismountItemsEnabled">1</config><config key="BackgroundTaskMenuMountItemsEnabled">1</config><config key="BackgroundTaskMenuOpenItemsEnabled">1</config>
How does this come? Is this necassary for the gui to run and what are the reasons behind it?
I do have veracrypt binaries/directory including the portable volume files to mount only on usb still these leftovers. I dont want to leave stuff on the system.
Jul 11, 2016 at 1:05 AM
Edited Jul 12, 2016 at 1:14 AM
Are you saying you ran an allegedly portable version of Veracrypt and it put
a config folder in your ~? Could it be that is left over from a previous conventional
installation of VC? Uninstalling, even "apt-get purge", often leaves config files. If a
"portable" version did that, it seems to me someone made a mistake in making it

Since you're using the "~/" notation I assume you are using a 'nix. Where did you
find a portable version for linux?
Jul 26, 2016 at 8:30 PM
Edited Jul 26, 2016 at 8:33 PM
Offical verified download VeraCrypt Linux Setup 1.17 from codeplex run on xenial xerus ubuntu 16.04 lts x64.

This page says extract instead of install:
So did I and placed the extracted binary on the usb stick. Now everytime when starting it creates the mentioned .VeraCrypt folder. Argl

If I remove the folder while the gui is running I get this message after exiting:
10:15:38 PM: Error: Failed to remove lock file '/home/user/.VeraCrypt-lock-user' (error 2: No such file or directory)
So it clearly shows an attempt to remove the folder (thus the error when missing), but obviously it does not work. Still there after exiting. Why do we create this folder in the first place?
Aug 16, 2016 at 3:07 PM
Thank you for the link, Foofoofoo. Interesting. Like many portable apps, then,
it still leaves some traces it was used, even if not intalled. Maybe it isn't
umounting like it should. I've found the processes gvfs-metadata and gvfs-trash
can interfere with dismounting VC volumes. You could try killing them and then
shutting down the VC. If that were the issue, I'd expect it to show an error
message about not being able to umount though. Or maybe it's a permission issue.
Do you have to escalate privs to rm the dir manually? If so, that's it.

Anyway, if you wanted to automate getting rid of these PARTICULAR traces
I think you could do so by putting a script or 2 on the portable media
where you put the VC. 2 approaches occur to me, 1 simpler, 1 more thorough:

For the following I've assumed the computer you're using has been booted
with a 'nix of some sort, since it clearly was in the example you gave.
Editing in hindsight, I realize it is just as likely to be
a Windows system. No matter. The same principles should work with a Windows
batch file instead of a bash script. If you try tinkering with these ideas, you
should probably implement in both bash (or better yet, sh) and batch and include
both on the media (funny how we use that word as if it were singular in this
context) so you can do it in either type of system.
    Wrap whatever command you use to start VC on the removable medium in a
    script. Don't use nohup, and don't put an "&" after it.
After that put:
rm -r -v ~/.VeraCrypt
or failing that
sudo rm -r -v ~/.VeraCrypt
You could use one line thus:
rm -r -v ~/.VeraCrypt || sudo rm -r -v ~/.VeraCrypt
(or if the system you're on isn't a 'buntu of some sort, you'll probably need to su
first and then rm.)
Use of sudo or su, of course, means you have to run it in a terminal. There
are other ways of course, but that is simpler.

I'll vouch for those commands on bash, which is probably your default shell, but
I think think they are posix and good on most shells.

Or if you want to be more thorough, use one of the wipe type programs instead
of rm. The additional security would be small and somewhat illusory in any case.
I'll come back to that.

Now, when you want to use VC, run the script rather than run it directly. When
you finish using VC and shut it down, the next command will run, and the VC
config dir in ~ will disappear.
    Again, use a script to wrap the command that starts the portable VC. But
    BEFORE that command put commands to:
set up a RAM-drive.
copy ~/ to it
rename ~/ to a backup filename
make a symlink ~/ to the copy in the RAM-drive
---alternately, you could actually mount the RAM-drive as ~/ - you could even
use something like read -p to give you a choice of method and wrap it in a
while/do/done loop that wouldn't finish until it verified that this was working.

THEN, would follow the VC command - again, no "nohup" and no following "&",
because you want the script to wait till you finish with VC before it procedes,
and the config file would be in the
RAM-drive and never get created to begin with.

AFTER the command that starts VC you'd put commands (that won't run
until you shut down VC) to remove the symlink and rename the backup to
the original name of ~/.

. . . . . . . .

Although the 2nd approach is slightly more secure than the 1st, in that it won't
leave a trace of the rm'ed ~/.Veracrypt dir or its contents which could be
recovered or at least proven to have existed with sufficient effort (it ain't easy),
and in that power failure or system crash won't leave the directory behind,
neither can be depended upon to not "leave stuff on the system".

A portable app is a polite way of using a program on someone
else's system without installing it. They may not want another menu entry.
They may not want to give it the drive space. They may not want the kids
to use the app. There may be a concern it will bork their system
(a more realistic concern on Windows systems, but they may not know that).
They may find bizarre config files for programs they don't use confusing, or
at least cluttering. Whatever. So not leaving them behind is a worthy goal.

BUT, it is NOT a realistic approach to security. You're likely to leave behind
things like thumbnails, recently-used-file lists, data cached in a software
drive buffer or in a page or swap file, in one of those system utilities that
indexes filesystems for fast retrieval, command histories, or Finagle-knows-what.
No approach like Window Washer or BleachBit can be depended upon for security
because they are aiming at a moving target. Things like that
change too fast to keep up with. Which is no big deal if you just want to recover
some drive space. But not to be counted upon for removing sensitive data.
Nor is any piecemeal approach that seeks to eliminate every possible info leak
by dealing with them one at a time. At best, security-wise, they are better than
nothing, and MIGHT get rid of something you want to get rid of, but not to
be depended upon.

For that matter there are remapped clusters in
the drive either because SMART (which is dumb if you ask me) thought they
looked flakey or because of wear leveling. And programs like WW and BB
can't deal with that even in principle. For that you need either a hidden OS or
a live disk. Either can be implemented in portable media. A hidden OS is going
to be easier on something like a usb drive, either conventional spinning rust or
one of those new solid state types. And its probably easier to do with Windows,
because there are step by instructions for that on this site. But live systems
are pretty easy on any 'nix and if you are looking to use VC SECURELY on other
people's computers, not just to avoid installing the app, that's the way to go.

One more thing you're probably aware of but Windoze people may read this too:
Don't get some paranoid notions because the files Foofoofoo refers to are
"hidden". "Hidden" is perhaps an unfortunate term like "imaginary" numbers.
Whether or not you see them depends on the preferences you set in your file
browser. It's a convenience thing. It's about visual clutter, not deception. Config
files like this are normally "hidden" or put in a hidden directory. That's standard
practice in any Unix-like (aka " 'nix ") OS AFAIK. If memory serves, Windows does
something pretty similar, or at least it used to.