Add 1.6.2 release notes.

Remove some TCRYPT comments from man page (FAQ is better for this).

diff --git a/docs/v1.6.2-ReleaseNotes b/docs/v1.6.2-ReleaseNotes
new file mode 100644 (file)
index 0000000..192f4a6
--- /dev/null
+++ b/docs/v1.6.2-ReleaseNotes
@@ -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).

diff --git a/man/cryptsetup.8 b/man/cryptsetup.8
index 8832088..b13a4c8 100644 (file)
--- a/man/cryptsetup.8
+++ b/man/cryptsetup.8
@@ -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>