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

Re: Templates for shim-signed



Hello Justin,
thanks for your ultra fast review.

On Sat, Nov 03, 2018 at 11:32:47AM +0000, Justin B Rye wrote:
> Helge Kreutzmann wrote:
> > shim-signed has several errors in debconf translations and pending
> > translations (cf. 910986 for details) which I intend to rectify.
> > 
> > I tried fixing the errors in the debconf template, for reference, the
> > original debconf templates are also attached.
> > 
> > I would be happy for review by native speakers befor sending out a
> > call for (updated) translations.
> 
> Okay, commentary inline, diff and revised version attached.
> 
> > Template: shim/title/secureboot
> > Type: text
> > _Description: Configuring Secure Boot
>                            ^UEFI
> Just for consistency.

Yes.

> > Template: shim/error/bad_secureboot_key
> > Type: error
> > _Description: Invalid password
> >  The Secure Boot key you've entered is not valid. The password used must be
> >  between 8 and 16 characters.
> 
> (Do we know that it was rejected on the basis of its length?  If it
> might be invalid for some other reason, it should say what kind of
> characters it wants.)

I'm not in the details of UEFI boot, so I'm leaving it as is.

> > Template: shim/disable_secureboot
> > Type: boolean
> > Default: true
> > _Description: Disable UEFI Secure Boot?
> >  If Secure Boot remains enabled on your system, your system may still boot but
> >  any hardware that requires third-party drivers to work correctly may not be
> >  usable.
> > 
> > Template: shim/enable_secureboot
> > Type: boolean
> > Default: false
> > _Description: Enable UEFI Secure Boot?
> >  If Secure Boot is enabled on your system, your system may still boot but
> >  any hardware that requires third-party drivers to work correctly may not be
> >  usable.
> > 
> > Template: shim/secureboot_explanation
> > Type: note
> > _Description: Your system has UEFI Secure Boot enabled
> >  UEFI Secure Boot is not compatible with the use of third-party drivers.
> >  .
> >  The system will assist you in toggling UEFI Secure Boot. To ensure that this
> >  change is being made by you as an authorized user, and not by an attacker,
> >  you must choose a password now and then use the same password after reboot
> >  to confirm the change.
> >  .
> >  If you choose to proceed but do not confirm the password upon reboot, Ubuntu
> >  will still be able to boot on your system but the Secure Boot state will not
> >  be changed.
> 
> That's only true if it was booting Ubuntu before!  This needs to be
> de-branded... and besides, we can't guarantee that the machine will
> succeed in booting without (e.g.) being struck by lightning!
> 
> So maybe:
> 
>   If you choose to proceed but do not confirm the password upon reboot, the
>   Secure Boot configuration will not be changed, and the machine will continue
>   booting as usual.

Woudln't it be better:
… booting as usual → booting as before


> >  If Secure Boot remains enabled on your system, your system may still boot but
> >  any hardware that requires third-party drivers to work correctly may not be
> >  usable.
> > 
> > Template: shim/secureboot_key
> > Type: string
> > _Description: Enter a password for Secure Boot, it will be asked again after a reboot:
> 
> Shouldn't this be "Type: password"?
> 
> The text doesn't need to be crammed into the short description.  As it
> is, this is confusing: I assume we're still talking about the password
> for authorising a change to the settings, but this could equally well
> be talking about a password to restrict booting.
> 
> Also, given that what's happening here is the administrator *setting*
> the password, it isn't going to be "asked again" after a reboot -
> that'll be the *first* time anyone's challenged to authenticate with
> it.
> 
>  Type: password
>  _Description: UEFI Secure Boot password
>   Please enter a password for configuring UEFI Secure Boot.
>   .
>   This password will be used after a reboot to confirm authorization for a
>   change to Secure Boot state.

Yes.

> > Template: shim/secureboot_key_again
> > Type: string
> > _Description: Enter the same password again to verify you have typed it correctly:
> 
> There's a standard format for these:
> 
>  Type: password
>  _Description: Re-enter password to verify
>   Please enter the same password again to verify that you have typed it
>   correctly.

Thanks.

> > Template: shim/error/secureboot_key_mismatch
> > Type: error
> > _Description: Password input error
> >  The two passwords you entered were not the same. Please try again.
> 
> Okay.
> -- 
> JBR	with qualifications in linguistics, experience as a Debian
> 	sysadmin, and probably no clue about this particular package

Greetings

         Helge

-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

Attachment: signature.asc
Description: Digital signature


Reply to: