Re: [RFC] Alternative solution (was: r50470 - trunk/packages/kbd-chooser/debian)

Frans Pop wrote:
> As I was extremely tired last night I decided to quit the discussion until
> after some sleep.
>
> On Monday 17 December 2007, Joey Hess wrote:
> > Frans Pop wrote:
> > > Because a dpkg-reconfigure needs to ask the question even if a keymap
> > > is installed.
> >
> > if [ ! -e /etc/whatever_file ] || [ "$1" = reconfigure ]; then
> > # ask question
> > fi
>
> Having d-i write an /etc/whatever_file for this still seems very ugly to me.

Um, that's intended to be a standin for whatever is the name of the keymap file that d-i configures instead of console-* configuring.

> Does not change the fact that the probability of anyone abusing that "hole"
> is about 0 and the effects if they do so is about null. On a scale from 1
> to 100 I would personally rate this security issue at about -0.

The number of times that people have used this reasoning and then gone on to have their security not-a-hole used in combination with some other security not-a-hole to exploit a system is somewhat larger than zero. My feeling is that the security community in general agrees with me -- I suspect we'd have no difficulty in getting a CVE number assigned for this security hole, aside perhaps from it not yet having been shipped in any released software.

> That said, I totally agree that this is not something that should be
> implemented as a general mechanism and after some reflection I've come to
> the conclusion that your suggestion to set the "seen" flag is probably the
> best solution.

Why is it better than simply testing for the keymap file's existance?

> It would have been ever so nice if this discussion could have been taken
> place _before_ the other solution had been implemented.
> Lessons for the future:
> - if someone proposes a patch with an RFC and some reservations, please
> don't just upload the patch but allow some time for feedback
> - if someone posts an RFC it would be nice if more people took the trouble
> to read it, consider the issue and post their opinion; preferable with
> arguments (even if they agree) and alternatives (if they don't)

I read the RFC immediatly after reading the commit message. It's holidays and I don't have a lot of time. I also prefer to have as little to do with console-* as possible..

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

> +# Avoid displaying console-data's keymap policy question
> +cd_template=console-data/keymap/policy
> +cd_policy="Don't touch keymap"
> +if ! db_set $cd_template "$cd_policy"; then
> + db_register debian-installer/dummy $cd_template
> + db_set $cd_template "$cd_policy"
> + db_subst $cd_template ID $cd_template
> +fi
> +db_fset $cd_template seen true
> +debconf-copydb -p $cd_template configdb target_configdb

I'm not sure what the resulting console-data/keymap/policy entry looks like in /var/cache/debconf/config.db. Does it have a sane template, or does copydb make it have debian-installer/dummy as the template? That would break later reconfiguration. Does it have the right owner?

preseed's own base-installer script uses debconf-set-selections.

echo "console-data console-data/keymap/policy seen true" | \

        chroot /target debconf-set-selections

-- 
see shy jo

-- To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org