[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#530784: partman-crypto: preseeding of the dm-crypt passphrase failed



Hello,
yes you're right. My patch is a quick hack and not good enought for the
debian distribution ...
I will try to rewrite it for better handle the multi crypted partitions.

A question for that. Is it possible do get a true or false value
without any user input in the debian-installer?
I think like

...
if [ preseed_${partition} eq false ]
  set passphrase_${partition} ""
  ...
fi

get passphrase_${partition}
set preseed_${partition} to false
...

So if no preseeding is wanted for this the behavour is the same as
befor. Otherwise the passphrase is read once and deleted afterwards
if an error occured and the script is called a second time for the
same partition.
But i don't want a question for the user about preseeding the
passphrase. It makes no sense to it.

Respectfully

Gabriel Sailer


Frans Pop schrieb:
> On Friday 10 July 2009, Gabriel wrote:
>> The 'problem' with this way of preseeding is, if you want to use
>> two seperate crypted partitions you cannot use two different
>> passphrases.
> 
> Why do you say "cannot"? Wouldn't both partitions just get the same 
> passphrase with your changes? I don't think that is desirable at all, but 
> I think that is what would happen.
> OTOH, I'm not sure that you can even specify a recipe with two encrypted 
> partitions...
> 
> But this is a very important comment, not only for preseeding. Your patch 
> will make partman crypto behave quite differently from its current 
> behavior when multiple partitions/devices are encrypted interactively.
> In that case the fields really should be reset before the questions are 
> asked a second time.
> 
> I also still think that the emptying of the passwords is done as a 
> security measure.
> 
> One option could be to instead reset the template (value and seen flag) 
> *after* the question has been asked and the value has been used. That 
> would still allow to preseed for a single encrypted partition, but would 
> 
> They should also be reset on error, so that you don't end in an endless 
> loop.
> 
> All and all, IMO this change is fine as an ad-hoc change if you really 
> want to preseed a single encrypted partition, but I don't think it is 
> suitable for inclusion in the package in its current form. I would also 
> prefer to see comments from the original authors of partman-crypto before 
> this patch is committed.
> 
> Cheers,
> FJP
> 



Reply to: