When I first learned about #pass I liked its concepts very much.

But I found it disturbing that anybody with access to my filesystem could see for which sites/applications/organizations I store encrypted information: the filename in pass reflects the criteria I can search for when looking for an encrypted information about something.

I learned about the pass-tomb extension.

A tomb is an encrypted filesystem in a file. The tomb script helps to unify, simplify and extend the idea and make these filesystems in files manageable.

pass-tomb extends pass to put the files of pass into a tomb adding new subcommands to pass like pass open and pass close to open and close the tomb containing pass files.

The tomb is protected by the same gpg key as any of the files contained inside the pass file structure.

In a closed pass-tomb it's not possible to look at the filenames and directory structure of pass. The whole filesystem is encrypted and stored just in one file that only tells someone that I'm probably using pass-tomb.

When starting with pass-tomb I ran into two issues:

• running out of inodes
• pass-tomb (actually tomb) complaining about my zramswap on the #Librem5

running out of inodes

When a pass-tomb is created the default size is 10MB formatted using ext4. This results in 2048 inodes being available (each file, symlink, directory requiring one inode).

pass uses a directory structure to put passwords for the same subject into a subdirectory. Having about 930 passwords imported this worked fine.

But when I tried to initialize a git repository (also offered as a standard functionality by pass) I ran out of space which turned out to be out of inodes.

Since the number of inodes cannot be changed in an ext4 filesystem I needed to start over and made a bigger pass-tomb store with 30MB and manually formatted it to btrfs using mixed mode to avoid the problem of running out of inodes.

To use btrfs the size of the disk at least has to be 16MB (mixed mode). To get this size the tomb file needs to be created with a minimum of 18MB.

I also could have formatted it with ext4 and set the bytes-per-inode to be the same as the block size to get a maximum of inodes (one for each block containing 1024bytes).

I guess it's a question of taste whether one uses btrfs or ext4. If there are good arguments to do one or the other I'd be interested to read them.

I opened the following issues about this problem:

• https://github.com/roddhjav/pass-tomb/issues/41
• https://github.com/dyne/Tomb/issues/448

pass-tomb complaining about zramswap

Using unencrypted swap written to disk while working with tombs poses a risk: parts or all of the key of the tombs luks encryption or any of the content could end up on disk unencrypted.

Because of this tomb checks for swap devices, checks whether the devices found active are encrypted and if an unencrypted swap device is found refuses to run.

There is a message saying the the user can -f force to run anyway, but no explanation about what else might be forced.

On my #Librem5 I use a #zramswap to compress parts of its 3GB ram. This works very well, but makes tomb complain, because the swap is not encrypted.

Tomb doesn't know about zramswap and the fact that it is usually not written to disk - even though it could be written to disk.

I stumbled a few times over the missing -f when testing pass-tomb on my Librem5 and decided to look into the script. I found it very good readable and adjusted it to check any swap whether it lives on a zram device and whether the zram device is configured not to write to disk any of its content.

Now my pass-tomb does not complain anymore about unencrypted zramswap without writeback. I hope the changes will be merged into tomb to be available in the #PureOS tomb package sometimes.