I was thinking that an empty whitelist should implicitly *allow* all. The
presence of one or more variables in the whitelist is a signal that the
user cares and explicitly disallows anything not in the whitelist. I think
this is totally compatible with any existing grub.cfg, unless somebody has
s
On 16.09.2013 23:15, Jan Reiss wrote:
>
> Hi there,
>
> as more and more mainboards become dual bios compatible and are
> flashable online via flashrom.
> i thought it might be a good idea if grub could be compiled as option
> rom to be included into the standard bios firmware.
> Does anyone have
В Mon, 9 Sep 2013 08:34:10 -0700
Jonathan McCune пишет:
>
> > Now if you could come up with solution that maintains compatibility
> > with existing grub.cfg, that would be valid reason. But right now
> > grub.cfg must be changed anyway at which point just save untrusted
> > variables separately
В Thu, 19 Sep 2013 09:18:55 +0200
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> On 07.09.2013 11:33, Andrey Borzenkov wrote:
> > So just use another environment block for untrusted variables, that's
> > all. I do not see why any change in sources is required.
> Trouble is that right now we uncon
Go ahead
On 18.07.2013 18:10, Aleš Nesrsta wrote:
> Hi,
>
> after some debugging I have found bug(s) in handling of QHs related to
> EHCI low speed split interrupt transfers.
>
> Attached patch seems to solve problem described below (non-working USB
> keyboard attached to the same port where was
On 25.08.2013 15:05, Andrey Borzenkov wrote:
> +defaults to 32 for IPv4 address and 128 for IPv6 address. Router is
> identified
> +by @var{shortname} which can be used to remove it (@pxref{net_del_route}).
> +@end deffn
> +
Route, not router.
Other than this problem, go ahead.
signature.asc
De
Please update other install methods as well
On 07.09.2013 01:59, Jon McCune wrote:
> +pubkey_file_arg=""
> +if [ x"$pubkey_file_list" != x ]; then
> +for file in $pubkey_file_list; do
> + if [ ! -e "$file" ]; then
> +gettext_printf "Public key file %s not found.\n" "${file}" 1>&2
>
On 07.09.2013 11:33, Andrey Borzenkov wrote:
> So just use another environment block for untrusted variables, that's
> all. I do not see why any change in sources is required.
Trouble is that right now we unconditionally load all variables from
block, whether trusted or not. So by modifying untrust