Your message dated Sat, 16 Feb 2008 17:40:07 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Re: [Pkg-cryptsetup-devel] Bug#430158: closed by Jonas Meurer
<[EMAIL PROTECTED]> (closing because of inactivity)
has caused the Debian Bug report #430158,
regarding uswsusp and cryptoswap
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
430158: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430158
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: cryptsetup
Version: 2:1.0.4+svn29-1
Severity: wishlist
(a similar mail already went to [EMAIL PROTECTED])
I tried to use luks to encrypt swapspace for uswsusp, because this will
also encrypt normal swapping activity and not only hibernation. After
reading and experimenting with cryptsetup's initramfs hooks I found some
things:
The initramfs tries to limit the rate at which passwords can be entered
by invoking sleep 3 on failures. I generally appreciate this behaviour,
but in this case it would be cool if there was an easy way to disable
this feature (easy means not editing files under /usr).
In contrast to this high security the initramfs proposes normal booting
after several password failures. I don't see any advantage in this
behaviour. Assuming the user doesn't use cryptoroot this leads to an
easier way to get a running system as an attacker. If one really does
not want to resume there is an easier way than pressing enter all the
time: append noresume to kernel command line. This also has the
advantage, that a boot loader can be configured not to accept these
modifications without a password. I therefore suggest asking for
passwords until it is valid or a configurable behaviour.
Otherwise uswsusp seems to work great with cryptsetup and luks (i.e.
roughly out of the box with some googling, documentation would be
great[1]).
Greetings
Helmut
[1] I filled in a bit of the documentation gap:
http://subdivi.de/~helmut/luks-uswsusp.html
--- End Message ---
--- Begin Message ---
Version: 2:1.0.4+svn26-2
On 16/02/2008 Helmut Grohne wrote:
> > why don't you just raise the retries yourself in /etc/crypttab. As
> > mentioned above, infinitive retries are not supported, but you could set
> > tries=9999999, and i doubt that anybody will try to input the password
> > more than 9999999 times.
>
> No problem, I just tried. I set the number of tries to 9999, updated my
> initramfs and rebooted just to observe that after three tries the system
> would boot. Am I missing something?
Ok, now I got the problem. You're correct, that the tries option doesn't
work for the cryptsetup version in debian/stable (2:1.0.4+svn26-1).
That's due to a mistake in upstream development. This has been fixed in
the cryptsetup package version 2:1.0.4+svn26-2, but unfortunately this
didn't make it into etch. Please see bugs #414326 and #412064 for
further information.
I'm sorry for being so ignorant in the first case, but I simply didn't
get your point.
As you can see, this bug has been fixed for a long time, so I'm closing
the bugreport again. Unfortunately, this will never make it into etch,
which is due to debians stable release policy. If you insist on this
feature, I could prepare a backport of the current cryptsetup package
version 2:1.0.6~pre1+svn46-1 for backports.org. What do you think about
that?
greetings,
jonas
--- End Message ---
