Package: cryptsetup
Version: 2:1.1.2-1
Severity: minor
Tags: patch
Hi Jonas.
Attached are several patches (agains svn), that would all fix typos (IMO).
Seems that you're using British English, so I've change two or three AmEng
words, too.
Cheers,
Chris.
Index: NEWS
===================================================================
--- NEWS (revision 792)
+++ NEWS (working copy)
@@ -1,6 +1,6 @@
cryptsetup (2:1.1.2-2) unstable; urgency=low
- Cryptdisks init scripts changed their behaviour for failures at starting and
+ cryptdisks init scripts changed their behaviour for failures at starting and
stopping encrypted devices. cryptdisks init script now raises a warning for
failures at starting encrypted devices, and cryptdisks-early warns about
failures at stopping encrypted devices.
@@ -110,7 +110,7 @@
cryptsetup (2:1.0.4+svn16-1) unstable; urgency=high
The --key-file=- argument has changed. If a --hash parameter is passed, it
- will now be honored. This means that the decrypt_derived keyscript will in
+ will now be honoured. This means that the decrypt_derived keyscript will in
some situations create a different key than previously meaning that any swap
partitions that rely on the script will have to be recreated. To emulate the
old behaviour, make sure that you pass "--hash=plain" to cryptsetup.
@@ -140,7 +140,7 @@
cryptsetup (2:1.0.3-4) unstable; urgency=low
Up to now, the us keymap was loaded at the passphrase prompt in the boot
- process and ascii characters were always used. With this upload this is
+ process and ASCII characters were always used. With this upload this is
fixed, meaning that the correct keymap is loaded and the keyboard is
(optionally) set to UTF8 mode before the passphrase prompt.
@@ -149,7 +149,7 @@
correct keymap loaded.
Additionally, all four fields are now mandatory in /etc/crypttab. An entry
- which does not contain all fields will be ignored. It is recommented to
+ which does not contain all fields will be ignored. It is recommended to
set cipher, size and hash anyway, as defaults may change in the future.
If you didn't set any of these settings yet, then you should add
@@ -160,7 +160,7 @@
cryptsetup (2:1.0.2+1.0.3-rc2-2) unstable; urgency=low
- The crypttab 'retry' has been renamed to 'tries' to reflect upstreams
+ The crypttab 'retry' has been renamed to 'tries' to reflect upstream's
functionality. Default is 3 tries now, even if the option is not given.
See the crypttab.5 manpage for more information.
Index: README.initramfs
===================================================================
--- README.initramfs (revision 792)
+++ README.initramfs (working copy)
@@ -16,7 +16,7 @@
The installation will then take care of all the details and perform the
necessary configuration for you, meaning that you should not have to
read the rest of this document to get a machine with an encrypted
-root fs up and running.
+rootfs up and running.
However, if you are not planning to perform a new installation from scratch,
the following information might be useful to you.
@@ -24,7 +24,7 @@
3. Requirements
---------------
-In order to boot from an encrypted root fs, you need an initramfs-image
+In order to boot from an encrypted rootfs, you need an initramfs-image
which includes the necessary kernel modules and scripts to setup
the root device after the kernel has been initialized, but before the rest
of the operating system is booted.
@@ -70,7 +70,7 @@
NOTE: the initramfs scripts default to using the sha256 hash function while
the plain cryptsetup binary defaults to using the ripemd160 hash function.
-In order to ensure that the crypto setup works in a consistant manner, you
+In order to ensure that the crypto setup works in a consistent manner, you
should make sure that the hash function is specified in the /etc/crypttab file
if you are using regular dm-crypt (with LUKS the hash function to use is stored
in the LUKS header).
Index: README.openct
===================================================================
--- README.openct (revision 792)
+++ README.openct (working copy)
@@ -18,7 +18,7 @@
smartcard devices by openct.
First of all, you should plug in your crypto token into USB or whatever
-interface it uses and initalize the reader with the following command (as root):
+interface it uses and initialise the reader with the following command (as root):
# openct-control init
@@ -33,8 +33,8 @@
If you do not see any reader listed, you have a problem and should read again
about the supported hardware on <http://www.opensc-project.org/openct/> and make
sure you have the required support (e.g. USB) compiled into your kernel needed
-to connect to your token. If you use a precompiled kernel from Debian,
-everything is already built kernelwise and you probably only need to load the
+to connect to your token. If you use a pre-compiled kernel from Debian,
+everything is already built kernel-wise and you probably only need to load the
module.
In case you want to erase your previously used smartcard, you can do that by
@@ -46,7 +46,7 @@
# pkcs15-init --create-pkcs15
-Caution: You are beeing asked about the 'Security Officer PIN' and the 'User
+Caution: You are being asked about the 'Security Officer PIN' and the 'User
unblocking PIN'. Although both of these pins are optional and can be left empty,
you should never do this: In case the personal user pin is typed wrong for a
given number (mostly three times), the smartcard is locked and can only be
@@ -55,7 +55,7 @@
only be unlocked with the security officer pin, which is the most superior pin
in this hierarchy. With an unset (empty) security officer pin or user unblocking
pin, depending on the smartcard, an attacker can have unlimited tries to crack
-your personal user pin, or, an attacker can simply make the smarcard unusable as
+your personal user pin, or, an attacker can simply make the smartcard unusable as
it cannot be unlocked anymore at all.
To create a new identity on the smartcard, do the following:
@@ -77,7 +77,7 @@
# pkcs15-init --store-data data.txt --auth-id 01
As of the time of writing, openct version 0.6.12 is available and does not
-support labeling different data objects. Once this gets fixed in openct
+support labelling different data objects. Once this gets fixed in openct
upstream, you can store multiple data objects to the smartcard (create them by
appending '--label foo' to the above command and replace foo with the label you
want to use).
@@ -99,12 +99,12 @@
sda5_crypt /dev/sda5 none luks,keyscript=/lib/cryptsetup/scripts/decrypt_openct
At the moment all data objects have the same label 'pkcs15-init'. Once openct
-supports labeling data objects, you can pass the respective label to openct with
+supports labelling data objects, you can pass the respective label to openct with
the key parameter in /etc/crypttab like this:
sda5_crypt /dev/sda5 none luks,keyscript=/lib/cryptsetup/scripts/decrypt_openct,key=foo
-For the time beeing, 'pkcs15-init' is passed to openct when no key is specified.
+For the time being, 'pkcs15-init' is passed to openct when no key is specified.
Don't forget to backup key.txt to a save place and remove the temporary files
afterwards:
@@ -112,10 +112,10 @@
# shred -uz key.txt data.txt
Caution: cryptsetup as of version 1.0.5-1 does not support fallback to passphrase
-if smartcard authentification fails (bee it three times wrong pin or not
+if smartcard authentication fails (bee it three times wrong pin or not
compatible/not detected smartcard reader). That means, that for testing
purposes, it is recommended to keep an initrd image in /boot available which
-does *not* use openct or opensc for authentification, so that you can change
+does *not* use openct or opensc for authentication, so that you can change
your bootloader configuration on the fly if something does not work out as
expected. Therefore, copy your current initrd (the .bak backups from
initramfs-tools can maybe get overwritten by update-initramfs during the setup
@@ -123,7 +123,7 @@
# cp /boot/initrd.img-`uname -r` /boot/initrd.img-`uname -r`.temp
-If you have completed all the steps upto now, you can update your initramfs
+If you have completed all the steps up to now, you can update your initramfs
image with:
# update-initramfs -u -k `uname -r`
Index: README.opensc
===================================================================
--- README.opensc (revision 792)
+++ README.opensc (working copy)
@@ -116,7 +116,7 @@
exit 0
fi
-If you have completed all the steps upto now, you can update your
+If you have completed all the steps up to now, you can update your
initramfs image with:
# update-initramfs -u -k `uname -r`
Index: README.remote
===================================================================
--- README.remote (revision 792)
+++ README.remote (working copy)
@@ -16,7 +16,7 @@
the default when the busybox package is installed) to have busybox installed
into the initramfs, and should not contain DROPBEAR=n, which would disable
installation of dropbear to initramfs. If set to DROPBEAR=y, dropbear will
-beinstalled in any case; if DROPBEAR isn't set at all, then dropbear will only
+be installed in any case; if DROPBEAR isn't set at all, then dropbear will only
be installed in case of an existing cryptroot setup.
The host keys used for the initramfs are dropbear_dss_host_key and
@@ -88,7 +88,7 @@
"echo -ne \"secret\" >/lib/cryptsetup/passfifo"
This example assumes that you have an extra known_hosts file
-"~/.ssh/known_hosts.initramfs" which hold's the cryptroot system's host-key,
+"~/.ssh/known_hosts.initramfs" which holds the cryptroot system's host-key,
that you have a file "~/id_rsa.initramfs" which holds the authorized-key for
the cryptroot system, that the cryptroot system's name is
"initramfshost.example.com", and that the cryptroot passphrase is "secret"
