From: Milan Broz Date: Sat, 27 Jul 2013 20:59:40 +0000 (+0200) Subject: Add 1.6.2 release notes. X-Git-Tag: upstream/1.6~8 X-Git-Url: http://review.tizen.org/git/?p=platform%2Fupstream%2Fcryptsetup.git;a=commitdiff_plain;h=154731306b67937cdcb7fdf1ad8867235bf2fd36 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 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 --- 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