Re: Imminent bugfix release (1.97.1)

[Bean]

On Tue, Nov 10, 2009 at 5:34 AM, Vladimir 'phcoder' Serbinenko
 wrote:
> But now it has a technical problem: it may read post array definitions.
> If any of post-array memory is MMIO or absent reading from it may have
> peculiar consequences
>>     Also, because s1 and s2 have two differents roles, I think it would be
>> best to give them names that better suits them. ;)

Hi,

Right, I think it'd be better to use fixed size array, perhaps we can
define a type grub_password_t for it.

BTW, with fixed size array, the following algorithm should run exactly
the same amount of instruction each time:

typedef char grub_password_t[1024];

int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
  int r1 = 0;
  int r2 = 0;
  int i, *p;

  p = &r1;
  for (i = 0; i < sizeof (grub_password_t); i++, s1++, s2++)
{
  *p |= (*s1 ^ *s2);
  if (*s1 == '\0')
p = &r2;
}

  return (r1 != 0);
}


-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

LVM write support from grub2. Writing to environment block in core.img

[Roger Cruz]

I have a system where the boot partition is on top of an LVM.  I'm using the 
loadenv module to save state and remember the previously booted entry.  I have 
something like this:

if [ ${prev_saved_entry} ]; then  saved_entry=${prev_saved_entry}  save_env 
saved_entry  prev_saved_entry=  save_env prev_saved_entryfi
In examining why save_env is not writing to grubenv, I came across this LVM 
routine that says LVM writes are not supported.
static grub_err_t
grub_lvm_write (grub_disk_t disk __attribute ((unused)),
 grub_disk_addr_t sector __attribute ((unused)),
 grub_size_t size __attribute ((unused)),
    const char *buf __attribute ((unused)))
{
  return GRUB_ERR_NOT_IMPLEMENTED_YET;
}
Is there a plan to add this support?  Anyone currently working on it that I may 
get an early implementation from?  If not, is there a technical reason why this 
would be hard for someone (maybe me) to implement?

As a work-around, I'm considering using the environment block in core.img.  Are 
there routines that can be run at boot time to allow grub to change the 
variables there, perhaps using the same module (loadenv) and so it can be used 
as "save_env -f core.img"?  Anyone see any reasons why I shouldn't write to 
that space?

Thanks
Roger


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB2 partition numbers are 1-based now?

[Darron Black]

Darron Black wrote:

I'd like to make sure I'm not going crazy.

From the Ubuntu 9.10 installs I've done recently, I've noticed 
/dev/sda1 -> (hd0,1), /dev/sda2 -> (hd0,2), etc, etc.


At first I thought it was a bug with the grub.cfg generation...  since 
I was only getting the grub> prompt on boot and typing in the same 
line with (hd0,N-1) worked.  (I guess because the UUID overrode it?)
I investigated and noticed that the function that built the device 
name (on the wrong OS at the moment, so can't look it up) definitely 
did a + 1.


I've quickly searched the archive (probably somewhat clumsily) and I 
didn't turn up anything definitive.


So...  (hd0,N) partitions are officially 1-based now, right?   That's 
super confusing.  Could a note be added to the autogenerated 
grub.cfg?  :)



Darron




Nevermind.

I just did a fresh google search and turned up the archlinux wiki, which 
clearly shows partitions starting at 1 now.


I'm not sure why I couldn't find anything earlier.  It being 2am when I 
had the problem might have had something to do with it.


However, a quick mention in the grub.cfg would be nice.  :)


Darron



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Darron Black]

richardvo...@gmail.com wrote:

Hello,

I'd be concerned about (s1 != s2).  Depending on how efficiently this
compiles, could not branch prediction make this faster for match vs. not
match, etc?.  I'd be worried about all the ways (and future ways) compilers
might help us and introduce time differences.



I was avoiding suggesting new conditionals for that reason, but didn't
see the one already there.  Good find.

  

I'd feel most comfortable with the time delay, but why not stick to complete
artithmetic?



I agree.  But I think you've inverted the return value (strcmp returns
0 on perfect match).

  
Yeah, sorry.  That'd be a slightly larger security hole, eh? 

I meant to just show the "acc |= (*s1 ^ *s2);" line, but I decided to 
throw the rest in for context and didn't really check it.  I noticed 
that just AFTER sending.



int i;
int acc = 0;

for(i=0;i.  Just = / !=.
 However, my context being so new is quite limited.


Darron



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel





___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
  




___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[richardvo...@gmail.com]

> Hello,
>
> I'd be concerned about (s1 != s2).  Depending on how efficiently this
> compiles, could not branch prediction make this faster for match vs. not
> match, etc?.  I'd be worried about all the ways (and future ways) compilers
> might help us and introduce time differences.

I was avoiding suggesting new conditionals for that reason, but didn't
see the one already there.  Good find.

>
> I'd feel most comfortable with the time delay, but why not stick to complete
> artithmetic?

I agree.  But I think you've inverted the return value (strcmp returns
0 on perfect match).

>
>
> int i;
> int acc = 0;
>
> for(i=0;i {
>   acc |= (*s1 ^ *s2);
>
>   if (*s1 == 0)
>      break;
> }
>
> return (acc == 0);
>
>
> Also, these strcmp functions don't properly return < or >.  Just = / !=.
>  However, my context being so new is quite limited.
>
>
> Darron
>
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[richardvo...@gmail.com]

On Mon, Nov 9, 2009 at 4:46 PM, Duboucher Thomas  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Robert Millan a écrit :
>> On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
>>>      Well, the only way to solve that problem would be IMHO to add a limit
>>> to the size of s2, and use this maximum size as an end condition for the
>>> 'for' statement. Any better idea? :)
>>
>> We have a maximum line read size anyway.  If we do this, we might as
>> well make that limit global so that the macro can be shared with
>> this routine.
>>
>
> Sounds good to me. :)
> Any ideas for renaming s1 and s2?

correct_key and attempted_key

But there seems to still be potential for overflow on one of the
strings.  Are both strings in fixed-equal-length buffers?  That should
be clearly documented.


>
> Thomas.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkr4m8EACgkQBV7eXqefhqj9SgCgjHomnoIkzzu5WuTCZQVcB/8t
> cwcAn1EkevCL3PXGlIuhLzFPlER9fXD3
> =okR/
> -END PGP SIGNATURE-
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Darron Black]

Duboucher Thomas wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Millan a écrit :
  

On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:


Well, the only way to solve that problem would be IMHO to add a limit
to the size of s2, and use this maximum size as an end condition for the
'for' statement. Any better idea? :)
  

We have a maximum line read size anyway.  If we do this, we might as
well make that limit global so that the macro can be shared with
this routine.




Sounds good to me. :)
Any ideas for renaming s1 and s2?

Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4m8EACgkQBV7eXqefhqj9SgCgjHomnoIkzzu5WuTCZQVcB/8t
cwcAn1EkevCL3PXGlIuhLzFPlER9fXD3
=okR/
-END PGP SIGNATURE-


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
  

Hello,

I'd be concerned about (s1 != s2).  Depending on how efficiently this 
compiles, could not branch prediction make this faster for match vs. not 
match, etc?.  I'd be worried about all the ways (and future ways) 
compilers might help us and introduce time differences.


I'd feel most comfortable with the time delay, but why not stick to 
complete artithmetic?



int i;
int acc = 0;

for(i=0;iAlso, these strcmp functions don't properly return < or >.  Just = / 
!=.  However, my context being so new is quite limited.



Darron



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

GRUB2 partition numbers are 1-based now?

[Darron Black]

I'd like to make sure I'm not going crazy.

From the Ubuntu 9.10 installs I've done recently, I've noticed 
/dev/sda1 -> (hd0,1), /dev/sda2 -> (hd0,2), etc, etc.


At first I thought it was a bug with the grub.cfg generation...  since I 
was only getting the grub> prompt on boot and typing in the same line 
with (hd0,N-1) worked.  (I guess because the UUID overrode it?) 

I investigated and noticed that the function that built the device name 
(on the wrong OS at the moment, so can't look it up) definitely did a + 1.


I've quickly searched the archive (probably somewhat clumsily) and I 
didn't turn up anything definitive.


So...  (hd0,N) partitions are officially 1-based now, right?   That's 
super confusing.  Could a note be added to the autogenerated grub.cfg?  :)



Darron



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [patch] grub incorrectly identifies ext3 as fat

[Robert Millan]

On Sat, Oct 31, 2009 at 08:15:56PM +0100, Robert Millan wrote:
> On Sat, Oct 31, 2009 at 02:43:19PM -0400, Andrew Clausen wrote:
> > > Or we can attempt to read a given file when we expect it's there.  For
> > > example, if we're looking for /boot/grub/, we can tell "/boot/grub" to the
> > > filesystem layer, so that it will require it as a precondition.
> > 
> > I can see that that would work will for some use cases...
> 
> Most importantly, it's a net win.  If we know a file is there, there's no
> harm in requiring that the filesystem driver is capable of reading it.
> 
> It's a pity, because we already had this check, and we were forced to
> disable it.  Would you like to help us restore it?  I can give more details.

Btw, the grub-probe check has just been reenabled in our experimental
branch (see http://www.gnu.org/software/grub/grub-2-download.en.html).

Perhaps you could test it and report if it fixes your problem?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] turn grub-emu into a port

[Robert Millan]

On Sat, Oct 31, 2009 at 12:08:55AM +0100, Vladimir 'phcoder' Serbinenko wrote:
> Following hunk is a regression for me:
> -  return (tv.tv_sec * GRUB_TICKS_PER_SECOND
> - + (((tv.tv_sec % GRUB_TICKS_PER_SECOND) * 100 + tv.tv_usec)
> -* GRUB_TICKS_PER_SECOND / 100));
> +  GRUB_COMPILE_TIME_ASSERT (GRUB_TICKS_PER_SECOND == 100);
> +  return (tv.tv_sec * 100 + tv.tv_usec);
> Having virtual clock going at any rate is an advantage for debugging.
> Other than this I'm ok with this patch and you can merge it into
> experimental

Fixed and merged in exp.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Duboucher Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Millan a écrit :
> On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
>>  Well, the only way to solve that problem would be IMHO to add a limit
>> to the size of s2, and use this maximum size as an end condition for the
>> 'for' statement. Any better idea? :)
> 
> We have a maximum line read size anyway.  If we do this, we might as
> well make that limit global so that the macro can be shared with
> this routine.
> 

Sounds good to me. :)
Any ideas for renaming s1 and s2?

Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4m8EACgkQBV7eXqefhqj9SgCgjHomnoIkzzu5WuTCZQVcB/8t
cwcAn1EkevCL3PXGlIuhLzFPlER9fXD3
=okR/
-END PGP SIGNATURE-


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Robert Millan]

On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
>   Well, the only way to solve that problem would be IMHO to add a limit
> to the size of s2, and use this maximum size as an end condition for the
> 'for' statement. Any better idea? :)

We have a maximum line read size anyway.  If we do this, we might as
well make that limit global so that the macro can be shared with
this routine.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Duboucher Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
> Duboucher Thomas wrote:
>> Bean a écrit :
>>> Hi,
>>> This one work:
>>> int
>>> auth_strcmp (const char *s1, const char *s2)
>>> {
>>>   int result = 0;
>>>   while (1)
>>> {
>>>   result += (*s1 != *s2);
>>>   if (*s1 == 0)
>>> break;
>>>   s1++;
>>>   s2++;
>>> }
>>>   return (result != 0);
>>> }
>>> The trick is to compare the ending '\0' as well, so that partial match
>>> is not satisfied.
>>
>> Yep, I like this one, but I would prefer using an OR instead of an ADD
>> (with a highly hypothetical integer overflow :p) and because it's nicer
>> in terms of pure logic.
>> "The comparison beetwen s1 and s2 is false if *s1 is different from
>> *s2, or recursively if the comparison beetwen s1+1 and s2+1 is false"
>>
>> int
>> auth_strcmp (const char *s1, const char *s2)
>> {
>>   int ret = 0;
>>
>>   for (;;)
>>   {
>> ret |= (*s1 != *s2);
>>
>> if (*s1 == '\0')
>>   break;
>>
>> s1++;
>> s2++;
>>   }
>>
>>   return ret;
>> }
>>
> But now it has a technical problem: it may read post array definitions.
> If any of post-array memory is MMIO or absent reading from it may have
> peculiar consequences

Well, the only way to solve that problem would be IMHO to add a limit
to the size of s2, and use this maximum size as an end condition for the
'for' statement. Any better idea? :)

int
auth_strcmp (const char *s1, const char *s2)
{
  int ret, n;

  for (ret = n = 0; ret < PASSPHRASE_MAXSIZE; ret++)
  {
ret |= (*s1 != *s2);

if (*s1 == '\0')
  break;

s1++;
s2++;
  }

  return ret;
}

>> Also, because s1 and s2 have two differents roles, I think it would be
>> best to give them names that better suits them. ;)
>>
>> Thomas.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4jRQACgkQBV7eXqefhqhJ3gCeNLHYAeVSb0qQ4GLgxbVvlDV7
P3oAoIvTa2Y+6i6BY1vTaOXXMklLVN8p
=7x71
-END PGP SIGNATURE-


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Vladimir 'phcoder' Serbinenko]

Duboucher Thomas wrote:
> Bean a écrit :
> > Hi,
>
> > This one work:
>
> > int
> > auth_strcmp (const char *s1, const char *s2)
> > {
> >   int result = 0;
>
> >   while (1)
> > {
> >   result += (*s1 != *s2);
> >   if (*s1 == 0)
> > break;
>
> >   s1++;
> >   s2++;
> > }
>
> >   return (result != 0);
> > }
>
> > The trick is to compare the ending '\0' as well, so that partial match
> > is not satisfied.
>
>
> Yep, I like this one, but I would prefer using an OR instead of an ADD
> (with a highly hypothetical integer overflow :p) and because it's nicer
> in terms of pure logic.
> "The comparison beetwen s1 and s2 is false if *s1 is different from
> *s2, or recursively if the comparison beetwen s1+1 and s2+1 is false"
>
> int
> auth_strcmp (const char *s1, const char *s2)
> {
>   int ret = 0;
>
>   for (;;)
>   {
> ret |= (*s1 != *s2);
>
> if (*s1 == '\0')
>   break;
>
> s1++;
> s2++;
>   }
>
>   return ret;
> }
>
But now it has a technical problem: it may read post array definitions.
If any of post-array memory is MMIO or absent reading from it may have
peculiar consequences
> Also, because s1 and s2 have two differents roles, I think it would be
> best to give them names that better suits them. ;)
>
> Thomas.

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko




signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Duboucher Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bean a écrit :
> 
> Hi,
> 
> This one work:
> 
> int
> auth_strcmp (const char *s1, const char *s2)
> {
>   int result = 0;
> 
>   while (1)
> {
>   result += (*s1 != *s2);
>   if (*s1 == 0)
>   break;
> 
>   s1++;
>   s2++;
> }
> 
>   return (result != 0);
> }
> 
> The trick is to compare the ending '\0' as well, so that partial match
> is not satisfied.
> 

Yep, I like this one, but I would prefer using an OR instead of an ADD
(with a highly hypothetical integer overflow :p) and because it's nicer
in terms of pure logic.
"The comparison beetwen s1 and s2 is false if *s1 is different from
*s2, or recursively if the comparison beetwen s1+1 and s2+1 is false"

int
auth_strcmp (const char *s1, const char *s2)
{
  int ret = 0;

  for (;;)
  {
ret |= (*s1 != *s2);

if (*s1 == '\0')
  break;

s1++;
s2++;
  }

  return ret;
}

Also, because s1 and s2 have two differents roles, I think it would be
best to give them names that better suits them. ;)

Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4he4ACgkQBV7eXqefhqj0kACgkgE60xJe5X/zpmXoPEd9SsT9
6H8An113fF03h0cndz2LpJvqnPyJ3EPx
=5MEi
-END PGP SIGNATURE-


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))

[Robert Millan]

On Mon, Nov 09, 2009 at 09:10:33PM +0100, Felix Zielcke wrote:
> Am Montag, den 09.11.2009, 21:04 +0100 schrieb Robert Millan:
> > On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> > > Some system such as ubuntu karmic define write using
> > > warn_unused_result attribute, which cause a warning when return
> > value
> > > of write is not used. As grub compile with -Werror, this turn into
> > > error, to work around it, use something like this:
> > > 
> > >  ssize_t tmp = write(bcat, buf, 2048);
> > >  (void) tmp;
> > 
> > Isn't "(void) write (bcat, buf, 2048)" enough? 
> 
> Why not just check the return code and print a warning (or maybe even
> error) for tmp != 2048?

Of course... shame on us.  A proper fix was so easy and we were still
looking for the workaround :-)  Thanks Felix.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] prefix redefinition fix (Re: hdparm documentation)

[Robert Millan]

On Mon, Nov 09, 2009 at 04:00:17PM +0100, Robert Millan wrote:
> === modified file 'normal/autofs.c'
> --- normal/autofs.c   2009-11-09 14:45:28 +
> +++ normal/autofs.c   2009-11-09 14:55:27 +
> @@ -51,12 +51,6 @@
>  read_fs_list (void)
>  {
>const char *prefix;
> -  static int first_time = 1;
> -
> -  /* Make sure that this function does not get executed twice.  */
> -  if (! first_time)
> -return;
> -  first_time = 0;
>  
>prefix = grub_env_get ("prefix");
>if (prefix)
> @@ -72,6 +66,15 @@
> file = grub_file_open (filename);

Vladimir, I don't think grub_file_open() can cause read_fs_list() to be invoked
recursively.  Note that read_fs_list() is not called when probing for
filesystems, only during initialization (before my patch, only once, and after
my patch, additionally each time ${prefix} is written to).

Do you still see a problem with this patch?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))

[Colin Watson]

On Mon, Nov 09, 2009 at 09:04:50PM +0100, Robert Millan wrote:
> On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> > Some system such as ubuntu karmic define write using
> > warn_unused_result attribute, which cause a warning when return value
> > of write is not used. As grub compile with -Werror, this turn into
> > error, to work around it, use something like this:
> > 
> >  ssize_t tmp = write(bcat, buf, 2048);
> >  (void) tmp;
> 
> Isn't "(void) write (bcat, buf, 2048)" enough?

You'd think so, but sadly that doesn't affect gcc warn_unused_result.
Usually I do something like 'if (write (...) < 0) /* ignore error */;'.

-- 
Colin Watson   [cjwat...@ubuntu.com]


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))

[Felix Zielcke]

Am Montag, den 09.11.2009, 21:04 +0100 schrieb Robert Millan:
> On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> > Some system such as ubuntu karmic define write using
> > warn_unused_result attribute, which cause a warning when return
> value
> > of write is not used. As grub compile with -Werror, this turn into
> > error, to work around it, use something like this:
> > 
> >  ssize_t tmp = write(bcat, buf, 2048);
> >  (void) tmp;
> 
> Isn't "(void) write (bcat, buf, 2048)" enough? 

Why not just check the return code and print a warning (or maybe even
error) for tmp != 2048?

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))

[Robert Millan]

On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> Some system such as ubuntu karmic define write using
> warn_unused_result attribute, which cause a warning when return value
> of write is not used. As grub compile with -Werror, this turn into
> error, to work around it, use something like this:
> 
>  ssize_t tmp = write(bcat, buf, 2048);
>  (void) tmp;

Isn't "(void) write (bcat, buf, 2048)" enough?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))

[Robert Millan]

On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote:
> 
> MINGW don't have fnmatch.h, add fnmatch.h to include
> MINGW don't define S_IROTH, S_IRGRP and u_char
> MINGW don't have lstat, getuid and getgid.

I started making some adjustments to these, and it was basically rewritten.  I
verified current trunk cross-compiles for mingw32.  The only caveat is I had to
use --disable-grub-mkfont.  Please try it out.

> BTW, my mingw version is 3.4.5 from windows host, it'd be nice if
> someone can verify the result with newer version.

I assume you mean your GCC version (mingw32 is still at 3.13).  Note that
we don't support building GRUB with GCC < 4.1.3 anymore.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Bean]

On Tue, Nov 10, 2009 at 2:46 AM, Vladimir 'phcoder' Serbinenko
 wrote:
> Bean wrote:
>> On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan  wrote:
>>
>>> On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko 
>>> wrote:
>>>
 Robert Millan wrote:

> Actually, modern CPUs are very complex and the number of operations (or
> time taken by them) isn't easy to predict.
>
>
>
 It's generally a good practice to do exactly same operations
 independently of result just store the result in a separate variable
 it's how RSA is correctly implemented

   for (n = grub_strlen (s1); n >= 0; n--)
   {
     if (*s1 != *s2)
       ret |= 1;
     else
       ret |= 0;

>>> Uhm I didn't check, but I'd suspect -Os would optimize this out.
>>>
>>> Anyhow, if we move the fixed time wait to the outer loop, it should no
>>> longer be a problem.
>>>
>>> We could also check the approach taken by e.g. su from coreutils.
>>>
>>
>> Hi,
>>
>> How about this one:
>>
>> int
>> grub_auth_strcmp (const char *s1, const char *s2)
>> {
>>   int result = 0;
>>
>>   for (; *s1 != 0; s1++, s2++)
>>     result += (*s1 != *s2);
>>
>>   return (result != 0);
>> }
>>
>>
>>
> Welcome to club: try it with
> "abc", "abcdef"
> They will match :(. Exactly the same problem as with my code but I like
> the approach. Perhaps:
>
> int
> grub_auth_strcmp (const char *s1, const char *s2)
> {
>  int result = 0;
>
>  for (; *s1 != 0; s1++, s2++)
>    result += (*s1 != *s2);
>
>  return !(result == 0 && *s2 == 0);
> }

Hi,

This one work:

int
auth_strcmp (const char *s1, const char *s2)
{
  int result = 0;

  while (1)
{
  result += (*s1 != *s2);
  if (*s1 == 0)
break;

  s1++;
  s2++;
}

  return (result != 0);
}

The trick is to compare the ending '\0' as well, so that partial match
is not satisfied.

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Vladimir 'phcoder' Serbinenko]

Bean wrote:
> On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan  wrote:
>   
>> On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko 
>> wrote:
>> 
>>> Robert Millan wrote:
>>>   
 Actually, modern CPUs are very complex and the number of operations (or
 time taken by them) isn't easy to predict.


 
>>> It's generally a good practice to do exactly same operations
>>> independently of result just store the result in a separate variable
>>> it's how RSA is correctly implemented
>>>
>>>   for (n = grub_strlen (s1); n >= 0; n--)
>>>   {
>>> if (*s1 != *s2)
>>>   ret |= 1;
>>> else
>>>   ret |= 0;
>>>   
>> Uhm I didn't check, but I'd suspect -Os would optimize this out.
>>
>> Anyhow, if we move the fixed time wait to the outer loop, it should no
>> longer be a problem.
>>
>> We could also check the approach taken by e.g. su from coreutils.
>> 
>
> Hi,
>
> How about this one:
>
> int
> grub_auth_strcmp (const char *s1, const char *s2)
> {
>   int result = 0;
>
>   for (; *s1 != 0; s1++, s2++)
> result += (*s1 != *s2);
>
>   return (result != 0);
> }
>
>
>   
Welcome to club: try it with
"abc", "abcdef"
They will match :(. Exactly the same problem as with my code but I like
the approach. Perhaps:

int
grub_auth_strcmp (const char *s1, const char *s2)
{
  int result = 0;

  for (; *s1 != 0; s1++, s2++)
result += (*s1 != *s2);

  return !(result == 0 && *s2 == 0);
}




-- 
Regards
Vladimir 'phcoder' Serbinenko




signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Bean]

On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan  wrote:
> On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko wrote:
>> Robert Millan wrote:
>> >
>> > Actually, modern CPUs are very complex and the number of operations (or
>> > time taken by them) isn't easy to predict.
>> >
>> >
>> It's generally a good practice to do exactly same operations
>> independently of result just store the result in a separate variable
>> it's how RSA is correctly implemented
>>
>>   for (n = grub_strlen (s1); n >= 0; n--)
>>   {
>>     if (*s1 != *s2)
>>       ret |= 1;
>>     else
>>       ret |= 0;
>
> Uhm I didn't check, but I'd suspect -Os would optimize this out.
>
> Anyhow, if we move the fixed time wait to the outer loop, it should no
> longer be a problem.
>
> We could also check the approach taken by e.g. su from coreutils.

Hi,

How about this one:

int
grub_auth_strcmp (const char *s1, const char *s2)
{
  int result = 0;

  for (; *s1 != 0; s1++, s2++)
result += (*s1 != *s2);

  return (result != 0);
}


-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Robert Millan]

On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> Robert Millan wrote:
> >
> > Actually, modern CPUs are very complex and the number of operations (or
> > time taken by them) isn't easy to predict.
> >
> >   
> It's generally a good practice to do exactly same operations
> independently of result just store the result in a separate variable
> it's how RSA is correctly implemented
> 
>   for (n = grub_strlen (s1); n >= 0; n--)
>   {
> if (*s1 != *s2)
>   ret |= 1;
> else
>   ret |= 0;

Uhm I didn't check, but I'd suspect -Os would optimize this out.

Anyhow, if we move the fixed time wait to the outer loop, it should no
longer be a problem.

We could also check the approach taken by e.g. su from coreutils.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Vladimir 'phcoder' Serbinenko]

Robert Millan wrote:
> On Mon, Nov 09, 2009 at 06:46:16PM +0100, Duboucher Thomas wrote:
>   
>>  Ok, I typed this in a few minutes and I'm not confident either with
>> what I wrote; I would check that it works first. ;)
>>  But the point here is that whatever the user gives as an input, it is
>> executed exactly n-th times, n being the length of the user input; and
>> that whatever the result of the 'if' statement is, the CPU realizes the
>> same amount of operations. By doing so, the attacker will only find out
>> how long it takes to make the comparison with a n caracters long input.
>> 
>
> Actually, modern CPUs are very complex and the number of operations (or
> time taken by them) isn't easy to predict.
>
>   
It's generally a good practice to do exactly same operations
independently of result just store the result in a separate variable
it's how RSA is correctly implemented

  for (n = grub_strlen (s1); n >= 0; n--)
  {
if (*s1 != *s2)
  ret |= 1;
else
  ret |= 0;

s1++; s2++;

  }

It's pproximately how my first attempt worked and it had this bug. If
you can propose a good and tested code of this kind I would be ok with it


-- 
Regards
Vladimir 'phcoder' Serbinenko




signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Robert Millan]

On Mon, Nov 09, 2009 at 06:46:16PM +0100, Duboucher Thomas wrote:
> 
>   Ok, I typed this in a few minutes and I'm not confident either with
> what I wrote; I would check that it works first. ;)
>   But the point here is that whatever the user gives as an input, it is
> executed exactly n-th times, n being the length of the user input; and
> that whatever the result of the 'if' statement is, the CPU realizes the
> same amount of operations. By doing so, the attacker will only find out
> how long it takes to make the comparison with a n caracters long input.

Actually, modern CPUs are very complex and the number of operations (or
time taken by them) isn't easy to predict.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Improve handling of "keep" in gfxpayload

[Colin Watson]

On Mon, Nov 09, 2009 at 06:18:41PM +0100, Robert Millan wrote:
> We don't have GRUB_ASSUME_LINUX_HAS_FB_SUPPORT anymore.  Does this
> patch still make sense?  (or some part of it?  I suspect
> GRUB_LINUX_VID_MODE_CURRENT is still useful).

Given the kernel issues with it, I've withdrawn this patch for the time
being. There may be cunning things we can do in future on systems that
support kernel modesetting, but it's not worth it right now.

-- 
Colin Watson   [cjwat...@ubuntu.com]


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Duboucher Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
> Bean wrote:
>> On Mon, Nov 9, 2009 at 9:50 PM, Vladimir 'phcoder' Serbinenko
>>  wrote:
>>   
>> Hi,
>>
>> int
>> grub_auth_strcmp (const char *s1, const char *s2)
>> {
>>   int ret;
>>   grub_uint64_t end;
>>
>>   end = grub_get_time_ms () + 100;
>>   ret = grub_strcmp (s1, s2);
>>
>>   /* This prevents an attacker from deriving information about the
>>  password from the time it took to execute this function.  */
>>   while (grub_get_time_ms () < end);
>>
>>   return ret;
>> }
>>
>> Isn't this 100 ms ? Anyway, the longest supported string is 1024 long,
>> I doubt there is any perceivable difference between them.
>>
>>   
> If attacker is on fast serial connection he could possibly measure the
> difference
> 

Hi,

I'm not very confident in this piece of code. I would rather go with
something like

int
grub_auth_strcmp (const char *s1, const char *s2)
{
  int n;
  volatile int ret = 0;

  for (n = grub_strlen (s1); n >= 0; n--)
  {
if (*s1 != *s2)
  ret |= 1;
else
  ret |= 0;

s1++; s2++;
  }

  return ret;
}

Ok, I typed this in a few minutes and I'm not confident either with
what I wrote; I would check that it works first. ;)
But the point here is that whatever the user gives as an input, it is
executed exactly n-th times, n being the length of the user input; and
that whatever the result of the 'if' statement is, the CPU realizes the
same amount of operations. By doing so, the attacker will only find out
how long it takes to make the comparison with a n caracters long input.

Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr4VWgACgkQBV7eXqefhqhcIQCgpviYSvNqGqH3fi2Td4QChsam
JWQAni9R7zOWFMGBu5X9rXWOjenIXx31
=vnph
-END PGP SIGNATURE-


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Improve handling of "keep" in gfxpayload

[Robert Millan]

On Mon, Aug 10, 2009 at 12:01:02PM +0100, Colin Watson wrote:
> If the user set "keep" in gfxpayload, as I understand it, that indicates
> that they want the graphical mode set by GRUB to persist through to the
> kernel. In order for this to actually work with Linux, we need to set up
> the vid_mode boot parameter to indicate that it should keep the current
> video mode, otherwise it'll just reset the mode to text at boot and
> nothing much is gained. This patch fixes that.
> 
> Note that I'm explicitly not enabling GRUB_ASSUME_LINUX_HAS_FB_SUPPORT
> in the Ubuntu grub2 package. I can understand why support for it was
> added, and I'd be willing to assume that the Ubuntu kernel has the
> necessary support, but I'm not willing to assume that every Linux kernel
> booted by the Ubuntu grub2 build has the necessary support; that seems
> one assumption too far for me. As such I'm interested in making this
> work properly with run-time configuration as well as build-time
> configuration.
> 
> This doesn't quite work perfectly yet. It's better than before - I've
> tested this, and if everything works properly then the result is a
> smooth zero-flicker transition, which is wonderful. However, if
> something goes wrong before the kernel starts a framebuffer then it has
> no way to display any text at all, and it doesn't seem to start one
> until relatively late for me. It may be that the next step here is to
> try to explicitly tell the kernel to set the correct VESA mode rather
> than using 0x0F04, but I thought I'd send this patch anyway in the
> meantime ...
> 
> 2009-08-10  Colin Watson  
> 
> * include/grub/i386/linux.h (GRUB_LINUX_VID_MODE_CURRENT): New
> macro.
> * loader/i386/linux.c (grub_linux_boot): If gfxpayload starts
> with "keep", or if GRUB_ASSUME_LINUX_HAS_FB_SUPPORT is defined,
> then set the vid_mode boot parameter to
> GRUB_LINUX_VID_MODE_CURRENT.

Hi Colin,

We don't have GRUB_ASSUME_LINUX_HAS_FB_SUPPORT anymore.  Does this patch
still make sense?  (or some part of it?  I suspect GRUB_LINUX_VID_MODE_CURRENT
is still useful).

> diff -Nur -x '*.orig' -x '*~' grub2-1.96+20090725/include/grub/i386/linux.h 
> grub2-1.96+20090725.new/include/grub/i386/linux.h
> --- grub2-1.96+20090725/include/grub/i386/linux.h 2009-07-06 
> 03:10:57.0 +0100
> +++ grub2-1.96+20090725.new/include/grub/i386/linux.h 2009-08-08 
> 19:45:10.0 +0100
> @@ -39,6 +39,7 @@
>  #define GRUB_LINUX_VID_MODE_NORMAL   0x
>  #define GRUB_LINUX_VID_MODE_EXTENDED 0xFFFE
>  #define GRUB_LINUX_VID_MODE_ASK  0xFFFD
> +#define GRUB_LINUX_VID_MODE_CURRENT  0x0F04
>  #define GRUB_LINUX_VID_MODE_VESA_START   0x0300
>  
>  #define GRUB_LINUX_SETUP_MOVE_SIZE   0x9100
> diff -Nur -x '*.orig' -x '*~' grub2-1.96+20090725/loader/i386/linux.c 
> grub2-1.96+20090725.new/loader/i386/linux.c
> --- grub2-1.96+20090725/loader/i386/linux.c   2009-08-08 19:31:00.0 
> +0100
> +++ grub2-1.96+20090725.new/loader/i386/linux.c   2009-08-08 
> 19:45:09.0 +0100
> @@ -446,6 +446,7 @@
>int e820_num;
>grub_err_t err = 0;
>char *modevar, *tmp;
> +  int keep_mode = 0;
>  
>params = real_mode_mem;
>  
> @@ -460,11 +461,19 @@
>if (! tmp)
>   return grub_errno;
>grub_sprintf (tmp, "%s;" DEFAULT_VIDEO_MODE, modevar);
> +#ifndef GRUB_ASSUME_LINUX_HAS_FB_SUPPORT
> +  if (grub_memcmp (modevar, "keep", sizeof ("keep")) == 0
> +   || grub_memcmp (modevar, "keep,", sizeof ("keep,") - 1) == 0
> +   || grub_memcmp (modevar, "keep;", sizeof ("keep;") - 1) == 0)
> + keep_mode = 1;
> +#endif
>err = grub_video_set_mode (tmp, 0);
>grub_free (tmp);
>  }
> -#ifndef GRUB_ASSUME_LINUX_HAS_FB_SUPPORT
>else
> +#ifdef GRUB_ASSUME_LINUX_HAS_FB_SUPPORT
> +keep_mode = 1;
> +#else
>  err = grub_video_set_mode (DEFAULT_VIDEO_MODE, 0);
>  #endif
>  
> @@ -474,6 +483,8 @@
>grub_printf ("Booting however\n");
>grub_errno = GRUB_ERR_NONE;
>  }
> +  else if (keep_mode)
> +params->vid_mode = GRUB_LINUX_VID_MODE_CURRENT;
>  
>if (! grub_linux_setup_video (params))
>  params->have_vga = GRUB_VIDEO_TYPE_VLFB;

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Grub-devel Digest, Vol 69, Issue 16

[Robert Millan]

On Mon, Nov 09, 2009 at 04:31:17PM +, Pedro A ARANDA wrote:
> 
> Hi, :-) thanks a lot. BTW if you need a tester. let me know ;-)

I sent a patch in a mail with subject:

  "[PATCH] prefix redefinition fix (Re: hdparm documentation)"

Btw, please try to avoid repliing on digest mails, it breaks thread grouping,
thanks :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))

[Bean]

On Tue, Nov 10, 2009 at 12:16 AM, Robert Millan  wrote:
> On Mon, Nov 09, 2009 at 11:55:11PM +0800, Bean wrote:
>> Sync with upstream r1810,
>
> Nice.
>
>> also fix a few compile error of grub-mkisofs
>> in mingw and ubuntu karmic.
>
> Could you perhaps send a patch for those compile fixes?

Hi,

Here is it, the compile error:

MINGW don't have fnmatch.h, add fnmatch.h to include
MINGW don't define S_IROTH, S_IRGRP and u_char
MINGW don't have lstat, getuid and getgid.
Some system such as ubuntu karmic define write using
warn_unused_result attribute, which cause a warning when return value
of write is not used. As grub compile with -Werror, this turn into
error, to work around it, use something like this:

 ssize_t tmp = write(bcat, buf, 2048);
 (void) tmp;

My branch also remove trailing blanks, but i use -w option to skip
those in the diff file.

BTW, my mingw version is 3.4.5 from windows host, it'd be nice if
someone can verify the result with newer version.

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


mkisofs.diff
Description: Binary data
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bazaar as main repository

[Felix Zielcke]

Am Montag, den 09.11.2009, 16:49 +0100 schrieb Michal Suchanek:
> 
> is there a tool similar to git-svn that would import bzr repository
> into git? 

You can use the bzr fast-export , git fast-import method for a one time
conversion.
If I understood Vladimir on IRC right, incremental mirroring should also
be possible with it.

There also seems to be some git-bzr stuff:
http://github.com/pieter/git-bzr/network

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

RE: Grub-devel Digest, Vol 69, Issue 16

[Pedro A ARANDA]

> Message: 4
> Date: Mon, 9 Nov 2009 15:13:38 +0100
> From: Robert Millan 
> Subject: Re: hdparm documentation
> To: The development of GNU GRUB 
> Message-ID: <20091109141338.gb19...@thorin>
> Content-Type: text/plain; charset=us-ascii
> 
> On Sun, Nov 08, 2009 at 06:09:33PM +0100, Christian Franke wrote:
> >
> > After 'insmod ata', loading of further modules typically fails because  
> > the drive in the 'prefix' variable is no longer valid.
> 
> Actually, there's a bit more to it:  even if you reset prefix, it won't
> use the new path.
> 
> I'm working on a fix for that right now.
> 
> -- 
> Robert Millan

Hi, :-) thanks a lot. BTW if you need a tester. let me know ;-)
 
>   The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>   how) you may access your data; but nobody's threatening your freedom: we
>   still allow you to remove your data and not access it at all."

Good one :-)  
_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

GRUB 1.97.1 released

[Robert Millan]

Hi,

GNU GRUB version 1.97.1 has been released.

GRUB, also known as the GRand Unified Bootloader, is a modular, portable
bootloader that supports a number of platforms, including standard BIOS-based
PCs, IEEE-1275 platforms (such as the OLPC and some PowerPC/Sparc64 hardware)
and coreboot, the free (as in freedom) pre-boot initialization framework.

  

This is a bug-fix release for a number of problems (excerpt from NEWS file
is attached) that weren't detected in time for GRUB 1.97, including a
security fix, misc fixes for GNU/Hurd support, and a number of improvements
in documentation and error messages (specially coreboot-related).

A source tarball for the new release can be found at:

  http://alpha.gnu.org/gnu/grub/grub-1.97.1.tar.gz

and its GPG detached signature [*]:

  http://alpha.gnu.org/gnu/grub/grub-1.97.1.tar.gz.sig

[*] You can use either of the above signature file to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify grub-1.97.1.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys DEA2C38E

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.61
  Ruby 1.8.7

GCC 4.4 is the recommended version for building it, although any version
starting with 4.1.3 is supported in this release.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."
New in 1.97.1:

* Security fix in password-checking functionality.

* Fixes for GNU/Hurd support.

* Fix build problem on MacOSX.

* Misc improvements in documentation and error messages.


signature.asc
Description: Digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation))

[Robert Millan]

On Mon, Nov 09, 2009 at 11:55:11PM +0800, Bean wrote:
> Sync with upstream r1810,

Nice.

> also fix a few compile error of grub-mkisofs
> in mingw and ubuntu karmic.

Could you perhaps send a patch for those compile fixes?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bazaar as main repository

[Michal Suchanek]

2009/11/9 Robert Millan :
> On Mon, Nov 09, 2009 at 04:49:58PM +0100, Michal Suchanek wrote:
>> 2009/11/8 Robert Millan :
>> >
>> > Hi,
>> >
>> > Vladimir would like to do this move;  I would like too, and can only assume
>> > that Colin Watson would be satisfied with it.
>> >
>> > So far nobody protested, and we finally sorted out the corruption problems.
>> >
>> > I stop resyncing with SVN now.  All developers are encouraged to commit
>> > directly to Bazaar (either trunk, experimental or personal branch depending
>> > on the nature of changes).
>>
>> Hello,
>>
>> is there a tool similar to git-svn that would import bzr repository into git?
>
> I think there is, but I'll let someone who knows better reply on that.
>
>> Or will the be the bzr development mirrored in the svn repository?
>
> No plans for that.
>
>> brz is very obscure system and even if it's good it may be hard to get
>> started with.
>
> Can you be more specific?  I've only used it for a few weeks, and let aside
> the problems related to svn->bzr conversion or bzr+ssh:// interaction, I
> found it very easy to figure out.
>

At the very least there is the problem of existing git branches/local
repositories.

Thanks

Michal


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bazaar as main repository

[Robert Millan]

On Mon, Nov 09, 2009 at 04:49:58PM +0100, Michal Suchanek wrote:
> 2009/11/8 Robert Millan :
> >
> > Hi,
> >
> > Vladimir would like to do this move;  I would like too, and can only assume
> > that Colin Watson would be satisfied with it.
> >
> > So far nobody protested, and we finally sorted out the corruption problems.
> >
> > I stop resyncing with SVN now.  All developers are encouraged to commit
> > directly to Bazaar (either trunk, experimental or personal branch depending
> > on the nature of changes).
> 
> Hello,
> 
> is there a tool similar to git-svn that would import bzr repository into git?

I think there is, but I'll let someone who knows better reply on that.

> Or will the be the bzr development mirrored in the svn repository?

No plans for that.

> brz is very obscure system and even if it's good it may be hard to get
> started with.

Can you be more specific?  I've only used it for a few weeks, and let aside
the problems related to svn->bzr conversion or bzr+ssh:// interaction, I
found it very easy to figure out.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [GITGRUB] New menu interface (implementation)

[Bean]

Hi,

Update:

Sync with upstream r1810, also fix a few compile error of grub-mkisofs
in mingw and ubuntu karmic.

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bazaar as main repository

[Michal Suchanek]

2009/11/8 Robert Millan :
>
> Hi,
>
> Vladimir would like to do this move;  I would like too, and can only assume
> that Colin Watson would be satisfied with it.
>
> So far nobody protested, and we finally sorted out the corruption problems.
>
> I stop resyncing with SVN now.  All developers are encouraged to commit
> directly to Bazaar (either trunk, experimental or personal branch depending
> on the nature of changes).

Hello,

is there a tool similar to git-svn that would import bzr repository into git?

Or will the be the bzr development mirrored in the svn repository?

brz is very obscure system and even if it's good it may be hard to get
started with.

Thanks

Michal


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] prefix redefinition fix (Re: hdparm documentation)

[Robert Millan]

On Mon, Nov 09, 2009 at 03:13:38PM +0100, Robert Millan wrote:
> On Sun, Nov 08, 2009 at 06:09:33PM +0100, Christian Franke wrote:
> >
> > After 'insmod ata', loading of further modules typically fails because  
> > the drive in the 'prefix' variable is no longer valid.
> 
> Actually, there's a bit more to it:  even if you reset prefix, it won't
> use the new path.
> 
> I'm working on a fix for that right now.

Here.  The problem is that command.lst (and friends) are only processed
once.  I fixed this by inserting a write hook in ${prefix}.

Would you please test and/or review?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

sftp://bzr.savannah.gnu.org/srv/bzr/grub/people/robertmh/prefix-redefinition-fix/

=== modified file 'normal/autofs.c'
--- normal/autofs.c	2009-11-09 14:45:28 +
+++ normal/autofs.c	2009-11-09 14:55:27 +
@@ -51,12 +51,6 @@
 read_fs_list (void)
 {
   const char *prefix;
-  static int first_time = 1;
-
-  /* Make sure that this function does not get executed twice.  */
-  if (! first_time)
-return;
-  first_time = 0;
 
   prefix = grub_env_get ("prefix");
   if (prefix)
@@ -72,6 +66,15 @@
 	  file = grub_file_open (filename);
 	  if (file)
 	{
+	  /* Override previous fs.lst.  */
+	  while (fs_module_list)
+		{
+		  grub_named_list_t tmp;
+		  tmp = fs_module_list->next;
+		  grub_free (fs_module_list);
+		  fs_module_list = tmp;
+		}
+
 	  while (1)
 		{
 		  char *buf;

=== modified file 'normal/dyncmd.c'
--- normal/dyncmd.c	2009-11-09 14:50:20 +
+++ normal/dyncmd.c	2009-11-09 14:55:27 +
@@ -62,12 +62,6 @@
 read_command_list (void)
 {
   const char *prefix;
-  static int first_time = 1;
-
-  /* Make sure that this function does not get executed twice.  */
-  if (! first_time)
-return;
-  first_time = 0;
 
   prefix = grub_env_get ("prefix");
   if (prefix)
@@ -84,6 +78,16 @@
 	  if (file)
 	{
 	  char *buf = NULL;
+
+	  /* Override previous commands.lst.  */
+	  while (grub_command_list)
+		{
+		  grub_command_t tmp;
+		  tmp = grub_command_list->next;
+		  grub_free (grub_command_list);
+		  grub_command_list = tmp;
+		}
+
 	  for (;; grub_free (buf))
 		{
 		  char *p, *name, *modname;

=== modified file 'normal/handler.c'
--- normal/handler.c	2009-11-09 14:50:20 +
+++ normal/handler.c	2009-11-09 14:55:27 +
@@ -135,7 +135,6 @@
 read_handler_list (void)
 {
   const char *prefix;
-  static int first_time = 1;
   const char *class_name;
 
   auto int iterate_handler (grub_handler_t handler);
@@ -162,11 +161,6 @@
   return 0;
 }
 
-  /* Make sure that this function does not get executed twice.  */
-  if (! first_time)
-return;
-  first_time = 0;
-
   prefix = grub_env_get ("prefix");
   if (prefix)
 {
@@ -182,6 +176,16 @@
 	  if (file)
 	{
 	  char *buf = NULL;
+
+	  /* Override previous handler.lst.  */
+	  while (grub_handler_class_list)
+		{
+		  grub_handler_class_t tmp;
+		  tmp = grub_handler_class_list->next;
+		  grub_free (grub_handler_class_list);
+		  grub_handler_class_list = tmp;
+		}
+
 	  for (;; grub_free (buf))
 		{
 		  char *p;

=== modified file 'normal/main.c'
--- normal/main.c	2009-08-24 23:55:06 +
+++ normal/main.c	2009-11-09 14:55:27 +
@@ -404,6 +404,16 @@
 
 static int reader_nested;
 
+static char *
+read_lists (struct grub_env_var *var __attribute__ ((unused)),
+	const char *val)
+{
+  read_command_list ();
+  read_fs_list ();
+  read_handler_list ();
+  return val ? grub_strdup (val) : NULL;
+}
+
 /* Read the config file CONFIG and execute the menu interface or
the command line interface if BATCH is false.  */
 void
@@ -411,9 +421,8 @@
 {
   grub_menu_t menu = 0;
 
-  read_command_list ();
-  read_fs_list ();
-  read_handler_list ();
+  read_lists (NULL, NULL);
+  grub_register_variable_hook ("prefix", NULL, read_lists);
   grub_command_execute ("parser.sh", 0, 0);
 
   reader_nested = nested;

___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Vladimir 'phcoder' Serbinenko]

Bean wrote:
> On Mon, Nov 9, 2009 at 9:50 PM, Vladimir 'phcoder' Serbinenko
>  wrote:
>   
>> Bean wrote:
>> 
>>> On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan  wrote:
>>>
>>>   
 A security problem [1] was found in our password-checking routines,
 which affects GRUB 1.97.  I'll be releasing 1.97.1 tomorrow.

 Additionally, I cherry-picked fixes for a few problems that should
 have made it to the release, like GNU/Hurd support (see NEWS file
 for details).  The release branch is available in:

  sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/

 If you have time, please test this tree, specially password support,
 to help find possible problems.

 
>>> Hi,
>>>
>>> Actually, the function of grub_auth_strcmp puzzles me, why would it
>>> need to wait 100 ms to return the result ?
>>>   
>> 10 ms actually. The goal is to take same amount of time indpendently of
>> input values. But probably the delay should be around whole thing and
>> it's how I'll do but for this urgent release this will do it
>> 
>
> Hi,
>
> int
> grub_auth_strcmp (const char *s1, const char *s2)
> {
>   int ret;
>   grub_uint64_t end;
>
>   end = grub_get_time_ms () + 100;
>   ret = grub_strcmp (s1, s2);
>
>   /* This prevents an attacker from deriving information about the
>  password from the time it took to execute this function.  */
>   while (grub_get_time_ms () < end);
>
>   return ret;
> }
>
> Isn't this 100 ms ? Anyway, the longest supported string is 1024 long,
> I doubt there is any perceivable difference between them.
>
>   
If attacker is on fast serial connection he could possibly measure the
difference


-- 
Regards
Vladimir 'phcoder' Serbinenko




signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Bean]

On Mon, Nov 9, 2009 at 9:50 PM, Vladimir 'phcoder' Serbinenko
 wrote:
> Bean wrote:
>> On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan  wrote:
>>
>>> A security problem [1] was found in our password-checking routines,
>>> which affects GRUB 1.97.  I'll be releasing 1.97.1 tomorrow.
>>>
>>> Additionally, I cherry-picked fixes for a few problems that should
>>> have made it to the release, like GNU/Hurd support (see NEWS file
>>> for details).  The release branch is available in:
>>>
>>>  sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/
>>>
>>> If you have time, please test this tree, specially password support,
>>> to help find possible problems.
>>>
>>
>> Hi,
>>
>> Actually, the function of grub_auth_strcmp puzzles me, why would it
>> need to wait 100 ms to return the result ?
> 10 ms actually. The goal is to take same amount of time indpendently of
> input values. But probably the delay should be around whole thing and
> it's how I'll do but for this urgent release this will do it

Hi,

int
grub_auth_strcmp (const char *s1, const char *s2)
{
  int ret;
  grub_uint64_t end;

  end = grub_get_time_ms () + 100;
  ret = grub_strcmp (s1, s2);

  /* This prevents an attacker from deriving information about the
 password from the time it took to execute this function.  */
  while (grub_get_time_ms () < end);

  return ret;
}

Isn't this 100 ms ? Anyway, the longest supported string is 1024 long,
I doubt there is any perceivable difference between them.

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Robert Millan]

On Mon, Nov 09, 2009 at 02:50:36PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> >
> > Actually, the function of grub_auth_strcmp puzzles me, why would it
> > need to wait 100 ms to return the result ? 
> 10 ms actually. The goal is to take same amount of time indpendently of
> input values. But probably the delay should be around whole thing and
> it's how I'll do but for this urgent release this will do it

Yes.  I realized that too this morning, but it's not so important.  The
previous approach was tested and I'll release 1.97.1 with it, afterwards
(or previously in trunk, thankfully we have branches now) we can fix it
to do the right thing.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Robert Millan]

On Sun, Nov 08, 2009 at 06:08:39PM -0800, Jordan Uggla wrote:
> None of the .sh scripts ( autogen.sh and the scripts it uses ) are
> executable; I needed to "chmod 744 *.sh" before I could run
> ./autogen.sh successfully. After doing that make failed with an error
> in auth.c. This was with revision 1780. I've attached the output from
> ./configure and make.

This was fixed in trunk, but release_1_97 didn't have it.  I'll cherry-pick
that one...

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: hdparm documentation

[Robert Millan]

On Sun, Nov 08, 2009 at 06:09:33PM +0100, Christian Franke wrote:
>
> After 'insmod ata', loading of further modules typically fails because  
> the drive in the 'prefix' variable is no longer valid.

Actually, there's a bit more to it:  even if you reset prefix, it won't
use the new path.

I'm working on a fix for that right now.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: bzr is online

[Robert Millan]

On Mon, Nov 09, 2009 at 04:53:37PM +0800, Bean wrote:
> 
> Hi,
> 
> I use the following method to apply patches:
> 
> find a common parent for old and new branch.
> move one revision up in old branch,
> remove all files expect .bzr in new branch, then copy files from old branch.
> use bzr commit to commit in new branch, the move new branch up one
> revision, and it has an identical tree as old branch.
> repeat the steps until all revision is synced,

Try with bzr merge command.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Vladimir 'phcoder' Serbinenko]

Bean wrote:
> On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan  wrote:
>   
>> A security problem [1] was found in our password-checking routines,
>> which affects GRUB 1.97.  I'll be releasing 1.97.1 tomorrow.
>>
>> Additionally, I cherry-picked fixes for a few problems that should
>> have made it to the release, like GNU/Hurd support (see NEWS file
>> for details).  The release branch is available in:
>>
>>  sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/
>>
>> If you have time, please test this tree, specially password support,
>> to help find possible problems.
>> 
>
> Hi,
>
> Actually, the function of grub_auth_strcmp puzzles me, why would it
> need to wait 100 ms to return the result ? 
10 ms actually. The goal is to take same amount of time indpendently of
input values. But probably the delay should be around whole thing and
it's how I'll do but for this urgent release this will do it
> grub_auth_strcmp is used in
> many place, so the authorized could take some time to complete. And
> there is a hidden issue in it, grub_auth_strcmp can accept NULL
> pointer as input, but grub_strcmp doesn't check for NULL pointer.
>
>   
Current codebase didn't use it


-- 
Regards
Vladimir 'phcoder' Serbinenko




signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Imminent bugfix release (1.97.1)

[Bean]

On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan  wrote:
>
> A security problem [1] was found in our password-checking routines,
> which affects GRUB 1.97.  I'll be releasing 1.97.1 tomorrow.
>
> Additionally, I cherry-picked fixes for a few problems that should
> have made it to the release, like GNU/Hurd support (see NEWS file
> for details).  The release branch is available in:
>
>  sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/
>
> If you have time, please test this tree, specially password support,
> to help find possible problems.

Hi,

Actually, the function of grub_auth_strcmp puzzles me, why would it
need to wait 100 ms to return the result ? grub_auth_strcmp is used in
many place, so the authorized could take some time to complete. And
there is a hidden issue in it, grub_auth_strcmp can accept NULL
pointer as input, but grub_strcmp doesn't check for NULL pointer.

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Grub EFI ia32 in QEMU using TianoCore EFI BIOS

[Colin Ian King]

Hi,

I've noticed only just recently that an EFI BIOS has been ported to
QEMU http://www.qemu.org/efi-bios.tar.bz2 from the TianoCore EFI
sources.

Has anyone had any success at getting EFI enabled grub2 to load and boot
a kernel inside of QEMU using this TianoCore EFI BIOS? 

I'm trying to get it to work based on the Ubuntu Karmic grub-efi-ia32
package (based on grub2-1.97 beta4) and I'm having all sorts of problems
trying to make it parse and execute the commands in a menu correctly.

Any one else had any luck with this?

Colin

-- 
Colin Ian King 



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: bzr is online

[Bean]

On Mon, Nov 9, 2009 at 4:41 PM, Vladimir 'phcoder' Serbinenko
 wrote:
> Bean wrote:
>> On Mon, Nov 9, 2009 at 4:45 AM, Vladimir 'phcoder' Serbinenko
>>  wrote:
>>
>>> Bean wrote:
>>>
 On Sun, Nov 8, 2009 at 11:36 PM, Vladimir 'phcoder' Serbinenko
  wrote:


> Hello, all. As you may have heard or noticed we had a data corruption in
> bzr repository. We couldn't find for sure what caused it but we could
> recover it, Robert Millan is running regular backups. But please be
> careful in the future.
> 1) Don't use bzr-svn. The IDs won't match anyway so it's useless. I
> removed bzr-svn altogether
> 2) Don't use bzr+ssh. Old daemon on savannah is one of possible vectors.
> --2a format should block it but don't even try please. Use
> sftp://bzr.savannah.gnu.org/srv/bzr/grub/
> ftp://bzr.savannah.gnu.org/srv/bzr/grub/trunk/grub>
> 3) Take precautions when handling your current branches. As the IDs
> don't match the bzr trunk you need to migrate it anyway. If you have
> small number of branches and history isn't important just create a patch
> and apply it to new bzr branch of current trunk. If you have large
> number of branches or no local copy contact me privately.
> 4) Regularly run "bzr check" on your repository
> 5) Sign your commits. For this add
> create_signatures = always
> to your bazaar.conf
> This has double use: security and integrity.
>
> Currentyl we haven't set up syncronisation between bzr and svn. Wait
> further instructions before comitting to mainstream
>
>
 Hi,

 I just sync my branch with main bzr repo, and find similar issue. It
 seems the bzr diff  has bug that could cause problem with renames, for
 example, don't use this:

 old branch:
 bzr diff > aa.diff

 new branch:
 bzr patch aa.diff

 The renamed file could get lost in the process. The only reliable way
 to apply patch is to export the whole tree from old branch, and add
 them in the new branch.



>>> I don't know what exactly do you mean but the concern is safety: your
>>> approach may result in corruption to be transfered to new repo
>>>
>>
>> Hi,
>>
>> It's very easy to verify, for example, run these commands:
>>
>> bzr mv COPYING COPYING1
>> bzr diff > aa.diff
>>
>> Output:
>> === renamed file 'COPYING' => 'COPYING1'
>>
>> This is obviously wrong, as neither "patch" nor "bzr patch" recognize
>> this format, so if you apply it with:
>>
>> bzr patch aa.diff
>>
>> Nothing happens. Therefore, 'bzr diff' is useless to create patch file
>> containing renames.
>>
>> BTW, my bzr version is 2.0.2
>>
>>
> I understood this part but haven't understood what do you propose as an
> alternative.
> (BTW feel free to report this issue to bzr mainstream)

Hi,

I use the following method to apply patches:

find a common parent for old and new branch.
move one revision up in old branch,
remove all files expect .bzr in new branch, then copy files from old branch.
use bzr commit to commit in new branch, the move new branch up one
revision, and it has an identical tree as old branch.
repeat the steps until all revision is synced,

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: bzr is online

[Vladimir 'phcoder' Serbinenko]

Bean wrote:
> On Mon, Nov 9, 2009 at 4:45 AM, Vladimir 'phcoder' Serbinenko
>  wrote:
>   
>> Bean wrote:
>> 
>>> On Sun, Nov 8, 2009 at 11:36 PM, Vladimir 'phcoder' Serbinenko
>>>  wrote:
>>>
>>>   
 Hello, all. As you may have heard or noticed we had a data corruption in
 bzr repository. We couldn't find for sure what caused it but we could
 recover it, Robert Millan is running regular backups. But please be
 careful in the future.
 1) Don't use bzr-svn. The IDs won't match anyway so it's useless. I
 removed bzr-svn altogether
 2) Don't use bzr+ssh. Old daemon on savannah is one of possible vectors.
 --2a format should block it but don't even try please. Use
 sftp://bzr.savannah.gnu.org/srv/bzr/grub/
 ftp://bzr.savannah.gnu.org/srv/bzr/grub/trunk/grub>
 3) Take precautions when handling your current branches. As the IDs
 don't match the bzr trunk you need to migrate it anyway. If you have
 small number of branches and history isn't important just create a patch
 and apply it to new bzr branch of current trunk. If you have large
 number of branches or no local copy contact me privately.
 4) Regularly run "bzr check" on your repository
 5) Sign your commits. For this add
 create_signatures = always
 to your bazaar.conf
 This has double use: security and integrity.

 Currentyl we haven't set up syncronisation between bzr and svn. Wait
 further instructions before comitting to mainstream

 
>>> Hi,
>>>
>>> I just sync my branch with main bzr repo, and find similar issue. It
>>> seems the bzr diff  has bug that could cause problem with renames, for
>>> example, don't use this:
>>>
>>> old branch:
>>> bzr diff > aa.diff
>>>
>>> new branch:
>>> bzr patch aa.diff
>>>
>>> The renamed file could get lost in the process. The only reliable way
>>> to apply patch is to export the whole tree from old branch, and add
>>> them in the new branch.
>>>
>>>
>>>   
>> I don't know what exactly do you mean but the concern is safety: your
>> approach may result in corruption to be transfered to new repo
>> 
>
> Hi,
>
> It's very easy to verify, for example, run these commands:
>
> bzr mv COPYING COPYING1
> bzr diff > aa.diff
>
> Output:
> === renamed file 'COPYING' => 'COPYING1'
>
> This is obviously wrong, as neither "patch" nor "bzr patch" recognize
> this format, so if you apply it with:
>
> bzr patch aa.diff
>
> Nothing happens. Therefore, 'bzr diff' is useless to create patch file
> containing renames.
>
> BTW, my bzr version is 2.0.2
>
>   
I understood this part but haven't understood what do you propose as an
alternative.
(BTW feel free to report this issue to bzr mainstream)


-- 
Regards
Vladimir 'phcoder' Serbinenko




signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: bzr is online

[Bean]

On Mon, Nov 9, 2009 at 4:45 AM, Vladimir 'phcoder' Serbinenko
 wrote:
> Bean wrote:
>> On Sun, Nov 8, 2009 at 11:36 PM, Vladimir 'phcoder' Serbinenko
>>  wrote:
>>
>>> Hello, all. As you may have heard or noticed we had a data corruption in
>>> bzr repository. We couldn't find for sure what caused it but we could
>>> recover it, Robert Millan is running regular backups. But please be
>>> careful in the future.
>>> 1) Don't use bzr-svn. The IDs won't match anyway so it's useless. I
>>> removed bzr-svn altogether
>>> 2) Don't use bzr+ssh. Old daemon on savannah is one of possible vectors.
>>> --2a format should block it but don't even try please. Use
>>> sftp://bzr.savannah.gnu.org/srv/bzr/grub/
>>> ftp://bzr.savannah.gnu.org/srv/bzr/grub/trunk/grub>
>>> 3) Take precautions when handling your current branches. As the IDs
>>> don't match the bzr trunk you need to migrate it anyway. If you have
>>> small number of branches and history isn't important just create a patch
>>> and apply it to new bzr branch of current trunk. If you have large
>>> number of branches or no local copy contact me privately.
>>> 4) Regularly run "bzr check" on your repository
>>> 5) Sign your commits. For this add
>>> create_signatures = always
>>> to your bazaar.conf
>>> This has double use: security and integrity.
>>>
>>> Currentyl we haven't set up syncronisation between bzr and svn. Wait
>>> further instructions before comitting to mainstream
>>>
>>
>> Hi,
>>
>> I just sync my branch with main bzr repo, and find similar issue. It
>> seems the bzr diff  has bug that could cause problem with renames, for
>> example, don't use this:
>>
>> old branch:
>> bzr diff > aa.diff
>>
>> new branch:
>> bzr patch aa.diff
>>
>> The renamed file could get lost in the process. The only reliable way
>> to apply patch is to export the whole tree from old branch, and add
>> them in the new branch.
>>
>>
> I don't know what exactly do you mean but the concern is safety: your
> approach may result in corruption to be transfered to new repo

Hi,

It's very easy to verify, for example, run these commands:

bzr mv COPYING COPYING1
bzr diff > aa.diff

Output:
=== renamed file 'COPYING' => 'COPYING1'

This is obviously wrong, as neither "patch" nor "bzr patch" recognize
this format, so if you apply it with:

bzr patch aa.diff

Nothing happens. Therefore, 'bzr diff' is useless to create patch file
containing renames.

BTW, my bzr version is 2.0.2

-- 
Bean

My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: hdparm and prefix invalidation

[Vladimir 'phcoder' Serbinenko]

Pedro A ARANDA wrote:
> Thanks Christian :-) that works now. I now understand that the last module
> I have to load is ata_pthru That's great. So currently I can turn off APM
> and got rid of the clunking. Next step is to make OSX load.
>   
Booting OSX on non-Apple computer constitutes an EULA violation.
Depending on the law in action this may be either enforceable or not.
But even if it isn't it constitutes an attempt on freedom to run
software which is essential to every software freedom. Imagine that
someone tries to tie you to a chair but you're able to get loose only
because a cord was of bad quality, would you give him second chance? We
encourage you to boycott OSX altogether. On a side note I tested OSX and
haven't found anything out of ordinary in it. There are a lot of free OS
for any taste, my personal choice would be GNU/Linux or FreeBSD. You may
also consider GNUStep which is reimplementation of NextStep/Cocoa API.
There is also an effort to create a Darwin (core parts of OSX)
distribution with only free software which can be found at
http://www.puredarwin.org/ . It uses the same kernel as OSX which can be
booted directly from GRUB2 as described here:
http://grub.enbug.org/XNUSupport

-- 
Regards
Vladimir 'phcoder' Serbinenko



___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel