Skip Menu |

This queue is for tickets about the File-KeePass CPAN distribution.

Report information
The Basics
Id: 63442
Status: resolved
Worked: 30 min
Priority: 0/
Queue: File-KeePass

People
Owner: Nobody in particular
Requestors: Lester Hightower (no email address)
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.01
Fixed in: (no value)



Subject: File::KeePass group hierarchy bug
File::KeePass messes up the group hierarchy any time parse_groups() encounters a structure where one moves more than one level "up" in a tree. Here is an example: - hello - world - i am sam - goodbye In this case, the group "goodbye" will mistakenly be placed inside of the group "hello" instead of at the root level, and all later root groups will be place an increasing level deeper. This problem only seems to occur if the "move up" is greater than 1 level. I am pretty sure there is a mistake inside the conditional "if ($previous_level > $level)" in parse_groups() and I suspect that the issue is with the splice() operation, but I am struggling to grok exactly what that code is doing. It would be great if the original author could have a quick look at it as he may see the problem straight away... Thanks.
From: lester.hightower [...] gmail.com
On Mon Nov 29 10:55:48 2010, lester.hightower@gmail.com wrote: Show quoted text
> File::KeePass messes up the group hierarchy any time parse_groups() > encounters a structure where one moves more than one level "up" in a > tree. Here is an example: > > - hello > - world > - i am sam > - goodbye > > In this case, the group "goodbye" will mistakenly be placed inside of > the group "hello" instead of at the root level, and all later root > groups will be place an increasing level deeper. This problem only > seems to occur if the "move up" is greater than 1 level. I am pretty > sure there is a mistake inside the conditional "if ($previous_level > > $level)" in parse_groups() and I suspect that the issue is with the > splice() operation, but I am struggling to grok exactly what that code > is doing. > > It would be great if the original author could have a quick look at it > as he may see the problem straight away... > > Thanks.
In follow up to this, I _think_ I figured this problem out but would sure like the original author to verify it. My tiny change in parse_groups(): < splice @gref, $previous_level, $previous_level - $level, (); Show quoted text
> splice @gref, -1*$previous_level, $previous_level - $level, ();
which seems to fix the problem and is the desired behavior _if_ I am understanding the structure of @gref correctly. Sincerely, Lester Hightower
From: lester.hightower [...] gmail.com
[...snip...] Show quoted text
> In follow up to this, I _think_ I figured this problem out...
[...snip...] ...I spoke too soon. :( I'll try to look into this more later. No time now. -- Lester
Subject: Re: [rt.cpan.org #63442] File::KeePass group hierarchy bug
Date: Thu, 02 Dec 2010 21:22:09 -0700
To: bug-File-KeePass [...] rt.cpan.org
From: Paul Seamons <paul [...] seamons.com>
Thank you for your interest. I finally took some time tonight and added a unit test for your exact problem. The problem duplicated itself exactly. The @gref acts as a stack of ref pointers to the various groups. When the level is less than the previously stored level we have to unwind the stack. I'm not exactly sure what I was thinking with that particular line. Here is the replacement line: splice @gref, $level, @gref - $level, (); We need to remove any levels above the level that we are moving back to - the last code sort of did it in the wrong direction. This new chunk lops off the branches correctly. I've also added the following as part of the unit tests: # test for correct stack unwinding during the parse_group phase my $obj2 = File::KeePass->new; my $G = $obj2->add_group({ title => 'hello', }); $G = $obj2->add_group({ title => 'world', group => $G, }); $G = $obj2->add_group({ title => 'i am sam', group => $G, }); $G = $obj2->add_group({ title => 'goodbye', }); $dump = eval { $obj2->dump_groups }; diag($dump); my $ok = $obj2->parse_db($obj2->gen_db($pass), $pass); my $dump2 = eval { $obj2->dump_groups }; #diag($dump); is($dump, $dump2, "Dumps should match after gen_db->parse_db"); I got started on adding keepass2 files, I may try and get that done and out to, but I'll get this patch out hopefully early next week. I'll comment more on your other emails soon. Thanks again. Paul On 11/29/2010 09:13 AM, Lester Hightower via RT wrote: Show quoted text
> Queue: File-KeePass > Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=63442> > > On Mon Nov 29 10:55:48 2010, lester.hightower@gmail.com wrote:
>> File::KeePass messes up the group hierarchy any time parse_groups() >> encounters a structure where one moves more than one level "up" in a >> tree. Here is an example: >> >> - hello >> - world >> - i am sam >> - goodbye >> >> In this case, the group "goodbye" will mistakenly be placed inside of >> the group "hello" instead of at the root level, and all later root >> groups will be place an increasing level deeper. This problem only >> seems to occur if the "move up" is greater than 1 level. I am pretty >> sure there is a mistake inside the conditional "if ($previous_level> >> $level)" in parse_groups() and I suspect that the issue is with the >> splice() operation, but I am struggling to grok exactly what that code >> is doing. >> >> It would be great if the original author could have a quick look at it >> as he may see the problem straight away... >> >> Thanks.
> > In follow up to this, I _think_ I figured this problem out but would > sure like the original author to verify it. > > My tiny change in parse_groups(): > > < splice @gref, $previous_level, $previous_level - $level, ();
>> splice @gref, -1*$previous_level, $previous_level - $level, ();
> which seems to fix the problem and is the desired behavior _if_ I am > understanding the structure of @gref correctly. > > Sincerely, > Lester Hightower >
The hierarchy bug is fixed, as is the parsing of dates from the group entry. Keepassx did not parse those headers. The keepass windows code did. All I needed to know was which field type indexes matched which field names.
On Fri Dec 03 23:38:56 2010, RHANDOM wrote: Show quoted text
> The hierarchy bug is fixed, as is the parsing of dates from the group > entry. Keepassx did not parse those headers. The keepass windows code > did. All I needed to know was which field type indexes matched which > field names.
I forgot to say - 0.02 has been uploaded to cpan.
From: lester.hightower [...] gmail.com
On Fri Dec 03 23:38:56 2010, RHANDOM wrote: Show quoted text
> The hierarchy bug is fixed, as is the parsing of dates from the group > entry. Keepassx did not parse those headers. The keepass windows > code did. All I needed to know was which field type indexes matched > which field names.
Paul, I had a chance to test 0.02 this morning and hate to have to report that the hierarchy bug is not fixed and the new code actually breaks the hierarchy in a worse way (one that I see no easy work-around for). I am going to spend a little time trying to wrap my brain around the code again, but I'm still struggling to fully understand the technique you are using there. I wish I could share my personal password db with you, but obviously can't... Try building up this hierarchy: - personal - career - finance - banking - credit - health - web - hosting - mail - Foo I *think* that type of hierarchy will expose both the old bug and the new one -- both 0.01 and 0.02 should parse that hierarchy incorrectly. Sincerely, -- Lester
From: lester.hightower [...] gmail.com
On Sat Dec 04 10:38:44 2010, lester.hightower@gmail.com wrote: [...snip...] Show quoted text
> the hierarchy bug is not fixed and the new code actually breaks the > hierarchy in a worse way (one that I see no easy work-around for). > I am going to spend a little time trying to wrap my brain around the > code again...
[...snip...] Paul, I think I figured it out -- at least this works in my test cases: < splice @gref, $level, @gref - $level, (); Show quoted text
> splice @gref, -1*($previous_level-$level), $previous_level-$level, ();
I hope I got this right and that you agree and can ship a v0.03. Thanks! Lester
From: brian [...] bldewolf.com
On Sat Dec 04 10:38:44 2010, lester.hightower@gmail.com wrote: Show quoted text
> > Try building up this hierarchy: > > - personal > - career > - finance > - banking > - credit > - health > - web > - hosting > - mail > - Foo > > I *think* that type of hierarchy will expose both the old bug and the > new one -- both 0.01 and 0.02 should parse that hierarchy incorrectly. >
I believe the cleanest fix is to change the splice to: splice @gref, $level + 1; When we move down in levels, our goal is to delete any references higher than the current level. This line achieves exactly that.
Thank you again. Fixed again. And the logic is even more simplified - which is usually a good thing. 0.03 is on its way to cpan. On Mon Dec 06 21:50:07 2010, bldewolf wrote: Show quoted text
> On Sat Dec 04 10:38:44 2010, lester.hightower@gmail.com wrote:
> > > > Try building up this hierarchy: > > > > - personal > > - career > > - finance > > - banking > > - credit > > - health > > - web > > - hosting > > - mail > > - Foo > > > > I *think* that type of hierarchy will expose both the old bug and the > > new one -- both 0.01 and 0.02 should parse that hierarchy incorrectly. > >
> > I believe the cleanest fix is to change the splice to: > splice @gref, $level + 1; > > When we move down in levels, our goal is to delete any references higher > than the current level. This line achieves exactly that.
Subject: Re: [rt.cpan.org #63442] File::KeePass group hierarchy bug
Date: Mon, 06 Dec 2010 23:20:43 -0700
To: bug-File-KeePass [...] rt.cpan.org
From: Paul Seamons <paul [...] seamons.com>
That was interesting. I got your email after sending on to cpan - that would've saved me 15 minutes of fixing the latest test case. My fix was exactly the same as yours - with some other code removed as well - the cases are much more simplified and explained. Not sure what I was thinking the first time. Since your code suggestion was identical to the fix already uploaded, I've back ported the Changes to mention your fix. All of my group use cases to date have had very simple hierarchies. Though the submitted hierarchies are simple, it helps to have them as unit tests as it quickly exposes the breaking points. Thank you for your interest and suggestions. Paul On 12/06/2010 07:50 PM, Brian De Wolf via RT wrote: Show quoted text
> Queue: File-KeePass > Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=63442> > > On Sat Dec 04 10:38:44 2010, lester.hightower@gmail.com wrote:
>> Try building up this hierarchy: >> >> - personal >> - career >> - finance >> - banking >> - credit >> - health >> - web >> - hosting >> - mail >> - Foo >> >> I *think* that type of hierarchy will expose both the old bug and the >> new one -- both 0.01 and 0.02 should parse that hierarchy incorrectly. >>
> I believe the cleanest fix is to change the splice to: > splice @gref, $level + 1; > > When we move down in levels, our goal is to delete any references higher > than the current level. This line achieves exactly that. >
This was resolved a long long time ago, but I replied the thread thus reopening it. We now also have support for keepass2 files.