On 2020-07-06 02:34:56 +0200, Guilhem Moulin wrote:
> On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote:
> > If you let the user run a script that controls the timeout, that
> > would be better. For instance, a typical setting when dropbear is
> > used to unlock the disk(s) would be to
On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote:
> On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote:
>> On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
>>> On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
The raison d'être of wait_for_dropbear() is to avoid
On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote:
> On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
> > On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
> >> The raison d'être of wait_for_dropbear() is to avoid handing the
> >> execution over to init(1) with a running ipconfig
On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
> On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
>> The raison d'être of wait_for_dropbear() is to avoid handing the
>> execution over to init(1) with a running ipconfig process or unclean
>> network stack. This is what the race
On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
> On Sun, 05 Jul 2020 at 12:08:41 +0200, Vincent Lefevre wrote:
> > On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote:
> >> That would introduce back the race condition described in #943459.
> >
> > I don't think so, as this would be equivalent
On Sun, 05 Jul 2020 at 12:08:41 +0200, Vincent Lefevre wrote:
> On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote:
>> That would introduce back the race condition described in #943459.
>
> I don't think so, as this would be equivalent to the current code when
> it reaches the 60-second timeout,
On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote:
> On Sat, 04 Jul 2020 at 00:54:53 +0200, Vincent Lefevre wrote:
> > I suppose that's
> >
> > wait_for_dropbear() {
> > […]
> > }
> >
> > Couldn't it also check whether the user has typed the passphrase,
> > and quit in this case?
>
> That
On Sat, 04 Jul 2020 at 00:54:53 +0200, Vincent Lefevre wrote:
> I suppose that's
>
> wait_for_dropbear() {
> […]
> }
>
> Couldn't it also check whether the user has typed the passphrase,
> and quit in this case?
That would introduce back the race condition described in #943459.
On 2020-07-04 00:30:04 +0200, Guilhem Moulin wrote:
> On Sat, 04 Jul 2020 at 00:18:59 +0200, Vincent Lefevre wrote:
> > Note that /usr/share/doc/dropbear-initramfs/README.initramfs
> > says at the end:
> >
> > This is non-blocking for the startup process, so when you are at the
> > console you
Control: reassign -1 dropbear-initramfs 2020.79-1
Control: retitle -1 dropbear-initramfs: init-bottom blocks for 1 minute when
there is no link
Control: severity -1 normal
On Sat, 04 Jul 2020 at 00:18:59 +0200, Vincent Lefevre wrote:
> Note that /usr/share/doc/dropbear-initramfs/README.initramfs
On 2020-07-03 16:12:49 +0200, Guilhem Moulin wrote:
> On Fri, 03 Jul 2020 at 12:53:17 +0200, Vincent Lefevre wrote:
> > I don't know really where the problem comes from, but it now takes
> > one minute to unlock the disk of my laptop with a passphrase. Well,
> > I'm not sure whether this comes
Control: reassign -1 cryptsetup-initramfs 2:2.3.3-1
Control: tag -1 + moreinfo
On Fri, 03 Jul 2020 at 12:53:17 +0200, Vincent Lefevre wrote:
> I don't know really where the problem comes from, but it now takes
> one minute to unlock the disk of my laptop with a passphrase. Well,
> I'm not sure
Package: cryptsetup
Version: 2:2.3.3-1
Severity: important
I don't know really where the problem comes from, but it now takes
one minute to unlock the disk of my laptop with a passphrase. Well,
I'm not sure whether this comes from cryptsetup or something that
comes just after it, but at least the
13 matches
Mail list logo
