eessppeelllloo/cryptsetup
1
0
Fork 0
mirror of https://gitlab.com/cryptsetup/cryptsetup.git synced 2025-12-11 10:50:01 +01:00
Code Issues Packages Projects Releases Wiki Activity

Add 1.6.2 release notes.

Browse Source 
Remove some TCRYPT comments from man page (FAQ is better for this).
This commit is contained in:
Milan Broz
2013-07-27 22:59:40 +02:00
parent d67548adfe
commit 154731306b
2 changed files with 29 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/v1.6.2-ReleaseNotes Normal file
View File

@@ -0,0 +1,25 @@
Cryptsetup 1.6.2 Release Notes
==============================
Changes since version 1.6.1
* Print error and fail if more device arguments are present for isLuks command.
* Fix cipher specification string parsing (found by gcc -fsanitize=address option).
* Try to map TCRYPT system encryption through partition
(allows to activate mapping when other partition on the same device is mounted).
* Print a warning if system encryption is used and device is a partition.
(TCRYPT system encryption uses whole device argument.)
* Disallow explicit small payload offset for LUKS detached header.
LUKS detached header only allows data payload 0 (whole data device is used)
or explicit offset larger than header + keyslots size.
* Fix boundary condition for verity device that caused failure for certain device sizes.
* Various fixes to documentation, including update FAQ, default modes
and TCRYPT description.
* Workaround for some recent changes in automake (serial-tests).

26
man/cryptsetup.8
View File

@@ -429,29 +429,11 @@ device not the system partition as the device parameter.
To use hidden header (and map hidden device, if available),
use \fB\-\-tcrypt\-hidden\fR option.
\fBNote:\fR There is no protection for a hidden volume if
the outer volume is mounted. The reason is that if there
\fBNOTE:\fR There is no protection for a hidden volume if
the outer volume is mounted. The reason is that if there
were any protection, it would require some metadata describing
what to protect in the outer volume and the hidden volume would
become detectable. This is not a cryptsetup limitation, it is
a limitation of how hidden volumes are implemented in TrueCrypt.
The way to deal with this is not to mount the outer volume after
a hidden volume has been created in it.
This, in turn, causes the problem that after a while all
time-stamps in the outer volume become old and it becomes obvious
that it is unused. This may cause suspicion in itself.
An alternative is to protect the area of the hidden volume
from write access using the Device Mapper, e.g. by mapping it
to the zero or error target. This corresponds to the protection
mechanism present in TrueCrypt, but can cause filesystem
annomalies and error messages in the system logs that reveal
the presence of the hidden volume. For that reason, TrueCrypt
sets both outer and hidden volume to read-only once a write
that would have damaged the hidden volume is intercepted.
They claim this preserves plausible deniability, but that
claim seems doubtful, because it also limits possible
changes to the outer volume and may result in truncated
and damaged files.
what to protect in the outer volume and the hidden volume would
become detectable.
.PP
\fIopen\fR \-\-type tcrypt <device> <name>