When tomb exit with an aborted operation the exit code is still zero

this prevents GUI invoking it from exec( ) to understand the result

this need to be fixed and eventually a list of exit codes with different states can be made
the exit code number-to-string converted could even be a minor command, like "tomb strerror"

When setting the -n flag, which tells tomb to do not execute pre-hooks and post-hooks, the script ignores that and always execute hooks.

that is, tomb -s asd create tombname will go on without complaining, but the tomb will be empty (because dd can't write "asd" blocks)

This also reveals that errors are not handled correctly

This is because of permission on ext3. Re-mapping dinamically everything seems to be difficult AND unpractical; there is no mounting option to force everything to be owned by user X.

Simplest solution could be just using a user-less filestystem, like... FAT32

usually undertaker will output the key contents.
For GUI interaction, it would be good to just output its location, so that the user can confirm if he likes it or if he wants to choose another one.

This should be an option like '--print-path`

the use of steganography must be easier when opening the tomb.
something like:

Swap can be dangerous, because crypted files can be swapped out unencrypted.
We should warn the user, suggesting to

1. swapoff, or
2. setup encrypted swap

For example an Ascii art image of boyska in a penis bouquet :D

tomb should make it easy to resize (increment, especially) a tomb; it should ask the user if he want to do this if opening an "almost-full" tomb (see #1)

Tomb should complain when it mounts a tomb which is almost full

This is a potential backdoor especially if Tomb doesn't checks the status of other LUKS specific key slots in a volume: a key can be added in the 2nd or 3rd slot without the user noticing, making the volume accessible with another key.

We need to check that all Luks slots are empty and allow the presence of only one key.

Or in case more keys are present then we need to make the user aware. However I'd be in favour of simplifying and removing the multiple slot functionality of Luks all in once, since it has some serious security drawbacks...

want to create the tomb steganographyng contextually the key

something like:

it is way too extreme to stop operations for the presence of swap; this behavior wasn't even discussed.

OTOH the swap vulnerability counts.

tomb runs as root so it could check for presence of a swap and execute swapoff/on -a

until this is implemented we cannot block the operation, but in case print out a warning.

Example here:
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Resizing_the_loopback_filesystem

yet this works only for ext2/3/4 and things get complicated as we start allowing more filesystem typess... however:

Resizing the loopback filesystem

First we should unmount the encrypted container:

umount /mnt/secret

cryptsetup luksClose secret

losetup -d /dev/loop0 # free the loopdevice.

After this we need to create a second file with the size of the data we want to add:

dd if=/dev/zero of=zeros bs=1M count=1024

You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers. Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!

cat zeros >> /bigsecret

Now we have to map the container to the loopdevice:

losetup /dev/loop0 /bigsecret

cryptsetup luksOpen /dev/loop0 secret

After this we will resize the encrypted part of the container to the maximum size of the container file:

cryptsetup resize secret

Finally we can resize the filesystem. Here is an example for ext2/3/4:

e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs

resize2fs /dev/mapper/secret

You can now mount your container again:

mount /dev/mapper/secret /mnt/secret

Make the temporary safe directory creation stronger: check if /dev/shm is already mounted, if not check if tmpfs is present in the kernel, else give a warning and maybe fail operation. The aim is to use tmpfs as it is possible on the system, possibly keeping all temporary unencrypted data in RAM.

Hibernating while a tomb is open is bad: it means that your key is written to disk.
We should close every tomb before hibernating.
This can be done using /etc/pm/sleep.d/99-tomb script which does this.

Also, if closing fails (because of pid locking it) we should choose between slamming and preventing hibernation.
Slamming is easier, but could be unintuitive for the user to "hibernate" and not finding his applications open on reboot.
Preventing hibernation seems to be possible, according to this post: http://askubuntu.com/questions/28328/how-can-i-disable-hibernate-completely-in-kubuntu

When trying to slam a tomb, tomb tries to kill all processes that keep the tomb open, but no check is performed to ensure that at least one pid is found.

anathema@nrv:/tomb_dev/Tomb/src$ ./tomb slam
[] Slamming tomb mytomb mounted on /media/mytomb.tomb
. Kill all processes busy inside the tomb
umount_tomb:kill:84: not enough arguments
[] Tomb mytomb closed: your bones will rest in peace.
anathema@nrv:/tomb_dev/Tomb/src$

here the code:
if [ $SLAM ]; then
notice "Slamming tomb $tombname mounted on $tombmount"
act "Kill all processes busy inside the tomb"
pidk=lsof -t "$tombmount"
for p in "$pidk"; do
pname=pidof $p
func "killing PID $p of $pname..."
kill -9 $p
done
else
notice "Closing tomb $tombname mounted on $tombmount"
fi

when decoding tomb key from image file, decode_key() overwrite an existing file:

steghide extract -sf ${imagefile} -p ${tombpass} -xf -
| awk '
BEGIN {
print "-----BEGIN PGP MESSAGE-----"
}
{ print $0 }
END {
print "-----END PGP MESSAGE-----"
}' > ${keyfile}

no check is made to ensure ${keyfile} already exist.

Colors are nice, but not every terminal handles them correctly.
For example, the VIM terminal buffer does not :D, nor will it be easy to parse output from tomblib with ansi escapes inside.

changing the password is sometimes needed, because the previous one could have been revealed some way.
This will also allow to have different key copies with different passwords.

The undertaker is strongly based on the idea of "scheme" (for example, http is the scheme for http://tomb.dyne.org/

When undertaker is requested a scheme that it doesn't know, it should check for the existance of the executable undertaker-$scheme.

This will allow us easier contribution for external software and easier dependency handling for "odd" schemes

# TODO: eliminate this function
get_arg_tomb $CMD2

present only in mount_tomb()

doesn't armonizes well with new optarg parsing

obsolete function to be removed

maybe a new feature or a simple tomb source script to pick up the key when you open a tomb from a remote server via ssh connection.

That's a really big one: writing a simple to use, almost-complete, secure GUI.
almost-complete means support for creating and opening. No esotheric options.
secure means that passwords are handled securely (pinentry)

Related: #59,#58

Try it using passowrd -fasd. print will understand it as -f (that is, format) =asd and will print asd.
You can now open your tomb using asd as password. This wasn't the expected behaviour, and weaken your password. It's possible that even worse things happen.

Check for unused vars and functions, fix some style bugs, clear indentation.

If you run tomb create -s 10 /tmp/foo > /dev/null, everything is fine.
Even if you run tomb create -s 10 /tmp/foo 2> /dev/null.
BUT if you run tomb create -s 10 /tmp/foo &> /dev/null, sudo will have errors when called by pinentry.

You can reproduce this bug even in an easier way:
sudo -S -v &> /dev/null
Actually, it's not the /dev/null part that matters; you can redirect it even to $HOME/errfile. The redirection itself is the problem.
It probably has something to do with the fact that sudo closes every file descriptor.

Even if it seems that this is not a grave bug, for me it is: I am coding the GUI, and I'd like to parse tomb stdout/stderr to read errors, so I "redirect" the output to some buffers.

We could workaround this using always stdout (or stderr, no difference) when --machine-parseable (see #58); this way the GUI is no more affected by this.
What about real solutions ?

Related: #60

when creating a tomb, this commands failed (on create_tomb() ):
chmod 0600 ${tombfile}
chown $(id -u $ME):$(id -g $ME) ${tombfile}

this should be:

chmod 0600 ${tombdir}/${tombfile}
chown $(id -u $ME):$(id -g $ME) ${tombdir}/${tombfile}

The Ultimate solution of the swap issue!

Create a temporary encrypted swap file on tomb opening.

This will make it easy the integration with GUIs (see #60)
The support is almost there, because functions like notice, act or error are quite good at this.

A good enhancement could be progress
It should behave like this:
[%] CREATION Creating the key
That is: an identifier, a keyword and a message. This is good for the progressbar while creating the key, which could take a long time. Don't know if it is for anything else

This is of course a minor feature.

the escaping need a more efficent implementation

were founded the problem:

$ tomb open -k 'copia\ di\ tomba.tomb.key' tomba.tomb
[*] Commanded to open tomb di
[!] file not found: di
[!] operation aborted.

In this way is confusing.
Must be something like: "Insert tomb steganography password"

Suppose you create a tomb named 'foo', and put the key on a USB key.
Then you create another tomb named 'foo' (again) and put it on the same USB key.
Result: you have trashed the first key!

Tomb allows for creation of too small tomb that the underlying file system cannot use.

e.g. tomb create -s1 is valid, but won't work. (Ext2 needs at least 4M)

the mount points are removed also if not temporary created
deps in autoconf

the option --ignore-swap need to be added to tomb-open options

it would be nice to delete the tomb command from shell history

is not nice that the tomb's mountpoint persist on /media/...

if the line 6:

local HOME=$(grep $ME /etc/passwd | sed "s/^${ME}:.:.:.:.:([/a-z]):.$/\1/" 2>/dev/null)

give a two line output the result is not as expected

Would be nice to add notify-send support: if notify-send is installed, tomb can automatically (or by flag) turn on notify over notify-send

will be confortable to choose the name and the location of the key creating the tomb

something like:

kill -9 can be bad sometimes. It would be better to do a kill -USR1 first, then wait one second to see if some process survived, and only if necessary kill -9

Sometimes fat32 can be better than ext3 (especially for moving the tomb on another computer). Sometimes it's the opposite (fat32 has a lot of limitations).

We should add an option --filesystem=FSNAME to the create subcommand, to let the user choose it.

EDIT: still requested XFS and FAT32

To be merged on the debian branch, cf. @e95cff2

There are mime packaging problems, but the patch is ready. This is just to remember ourselves to include it in tomb1.1

Use a lock file indicating the tomb is already mounted read-write
Default behaviour can be to mount read-only

This will let collective non-concurrent use of tombs on remote services (sshfs, clouds...)
still making sure only one user at a time is editing the Tomb.

nifty feature: inotify when lock is released and trigger mount -o remount,rw ....

We don't want to fetch keys just from a plugged usb-storage: also from an ssh shell, or a bluetooth device like a mobile phone.

Initially I've started to implement this inside tomb, but then quickly realized this complicates too much the core code and inserts latencies as well too many configurable aspects beyond its scope.

We can implement these features is an external auxiliary program, something to fetch keys: 'undertaker' might be a good name for it, it would be a specialized application to fetch keys via several different supported protocols....

the correct tomb invocation is: tomb [command] [options] [file] [place]

Also, the -k option do not accept argument, then the only way to use tomb is that the tomb file and key must be on the same directory and do not use the -k flag.

For gui interaction, polling is very useful. It is somehow implemented in tomb-open, for usb.
I propose implementation in undertaker, for ANY scheme. Just repeat calling the script until it finds a suitable key

This should be an option, --poll

They just seems not to work. Part of the problem is the awk expression

| awk '/^D/ { print $2 }'