On Mon, 2007-06-18 at 16:50 -0500, Bruno Wolff III wrote: > On Mon, Jun 18, 2007 at 16:51:55 -0400, > Jeremy Katz <katzj@xxxxxxxxxx> wrote: > > On Mon, 2007-06-18 at 14:07 -0500, Bruno Wolff III wrote: > > > On Mon, Jun 18, 2007 at 12:55:31 -0400, > > > Jeremy Katz <katzj@xxxxxxxxxx> wrote: > > > > Is this where I chime in with something about keymaps and locales again? > > > > I'm thinking probably so... ;-) > > > > > > That is certainly a problem. But for some people running encryption through > > > a block device that respects things such as write barriers, is going to be > > > more attractive than some of the other solutions. > > > > As an English speaker, sure. What if you only speak Japanese? If we're > > only solving the problem for those that speak English, then (and > > apologies for shouting...) WE'RE NOT SOLVING THE PROBLEM. People use > > Fedora world-wide and we need to actually have our features work within > > that context. > > I would see a pause with some strange prompt and figure it is waiting for > me to enter something and that it must be my password. And many would just think that something was broken. > I think waiting for a complete solution is not the way to proceed. There are > several different steps involved with the solution. If some of the steps > have workable solutions, getting them included in the distribution will > help get them tested and allow other people to build upon the previous work. > It might be hard to recruit people to do some of the things that will be > eventually needed until there is some base functionallity for them to play > with. > > You don't have to advertise full disk encryption for the masses as soon as > there is some support for booting with an encrypted root partition. If the idea is to actually _support_ full disk encryption in Fedora, then it has to be everywhere. In the installer. On upgrades (at least for the Fedora n+1 release :-). In the documentation. Otherwise, we're doing ourselves a great disservice by talking out of one side of our mouth saying it's supported but on the other claiming "well, maybe not so much". > > > Heck, for key maps there probably aren't so many that you can't try multiple > > > possibilities after getting the password. > > > > There are at least 30-40 that we allow in the installer alone at the > > console. find -type f /lib/kbd/keymaps/i386 | wc -l gives around 140. > > I don't think that trying either is really that practical. > > 40 probably isn't too many to make trying them all impractical. I expect > that it will take less than a second to try each one even with measures > to slow down password guessing. That's not nice for suspend resume, but > wouldn't be a deal breaker for initial boots. If it takes less than a second, then that means the measures to slow down password guessing are pretty bad ;-) You want an exponential backoff that gets pretty slow pretty fast or it becomes way too easy to brute force. And even for initial boots, another of the goals for Fedora 8 is actually making things faster. Why would we make two features work directly against each other? > > > The password prompts being in the > > > wrong locale, might look ugly, but should be servicable. > > > > Not for use within some countries... that's why translations are a big > > deal > > > > > People using the > > > grub menu have to deal with that now as far as I know. > > > > The goal is that you never _see_ the grub menu. Also, one of the things > > that's being worked on with grub2 is the infrastructure to have some > > support for i18n/l10n. We really shouldn't be adding new things that > > don't take it into account. Especially if they're going to be highly > > visible new features. > > We should be able to use some of the ideas that get used in grub2. They > are going to have to solve essentially the same problem (fonts and keymaps > without the bloat of X). Similar problems, but pretty different constraints and available things to make use of. eg, in the bootloader there are real mode graphics modes as an option. Those aren't available once we're into userspace. And things that use fbcon (eg, bterm or kon) have tended to cause more problems than they've helped. Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
