Missing item in teampass versions coming from cpassman about teampass HOT 4 CLOSED

Have you clean up the cache table?

Are you using IE8?

from teampass.

I'm not entirely sure that my issues are related to this bug, but after upgrading from (cpassman) 2.0bsomething to (teampass) 2.1.7 i spotted two problems:

a) some passwords returned only "false" (Yes, the litaral string)
b) some passwords are there, are even findable via search, they are also COUNTed and are included in the number of items in the tree, but are NOT showed in the list when clicking inside the tree.

When looking at the database i noticed one major difference between passwords displayed correctly and returning false - the length of the hash - Passwords returned correctly have a longer Hash stored, Passwords not returned have a shorter Hash stored (but a respective entry in cpassman_keys).

When i delete the entry FROM cpassman_keys of a shorter hash, the password is displayed correctly in the UI. When i reload the UI, the entry shows behaviour b) (i.e. it disappears from the UI).

The Problem is that passwords in this list are only showed when there actually is a key stored in cpassman_keys for this cpassman_items.

The fix for (b) (and i assume this bugreport) is that the INNER JOIN in the respective places is replaced by a LEFT JOIN, as the LEFT JOIN will also include _items that have NO _keys associated, while a INNER_JOIN requires that.

ill send you a pull request in a few.

(Basically takes this table:

Table A | Table B => LEFT JOIN | INNER JOIN | RIGHT JOIN
x | - => x - | empty set | empty set
x | x => x x | x x | x x

•    |      x     =>  empty set  |  - x             | - x
  

)

as to issue a) i'm not sure how to solve this, the most obvious solution would be to ignore the _keys entry if the (B64-"encoded") hash stored in _items is "too short" (44 versus 88 Byte?)

from teampass.

Thank you for this analysis and yes what you written is true.
Indeed migrating from a version previous of 2.1 can produce such effect.

I've not noticed it in my test environment but I've read similar issues. I don't understand why actually as I can't reproduce it.

I think the tip with LEFT JOIN could be solution even if more permissive ... I'll test it on my side.

Thank you

from teampass.

I havent checked wether its more permissive, i just workarounded (given! ;).

Anyhow, maybe a better solution would be to add a another task in the maintenance section which basically reads all Passwords (no matter which "version" it was) and writes them in the latest version back, which would fix the issue by hand and probably upcoming, too.

On the other hand, if it did it would probably show exact the same passwords like the LEFT JOIN, because the difference only is that the INNER JOIN only selects rows which have the _keys associated, while the LEFT JOIN will also select rows which have no _keys associated. The rest of the query selects inside _items anyway.

from teampass.