Hi Anthony:

In message <1585208555.20170201185211@inbox.ru>, Anthony writes:
[ john wrote ]
>> If you go to the edit for for a user e.g. tracker/user3 and type in two
>> different passwords for the password fields, you get a traceback:
>
>> In cgi/templating.py PasswordHTMLProperty::plain calls:
>>
>>         if isinstance(self._value, hyperdb.Password):
>>             value = self._value.dummystr()
>>         else:
>>             value = self._('[hidden]')
>>         if escape:
>>             value = cgi.escape(value)

Blech. I screwed up and pasted my fixed code twice. The code above is
supposed to be what you have below.

>I don't have this issue. But I use Jinja2 and my roundup-tracker
>source  is slightly different:
>
> def plain(self, escape=0):
>         """ Render a "plain" representation of the property
>       """
>        if not self.is_view_ok():
>             return self._('[hidden]')
>
>       if self._value is None:
>             return ''
>       value = self._value.dummystr()
>       if escape:
>             value = cgi.escape(value)
>         return value

This is the code that breaks if you have the current development head.

If you have a release roundup version (e.g. 1.5.1) the code works. I
think this problem only happens if you have the commit:

  changeset:   5166:232c74973a56
  user:        Ralf Schlatterbeck
  date:        Mon Aug 22 22:19:48 2016 +0200

which makes sure that a form keeps the edited values if it fails a
check when submitted. See: http://issues.roundup-tracker.org/issue1408570

I have to do a bisect to make sure that's the (much wanted) change in
functionality that caused the issue.

>May be it doesn't matter. I guess that there is a value substitution
>in  password input control in TAL template. I don't understand TAL so
>this is only a guess.

This substitution should happen in the jinja code as well. It's
possible the substitution is only needed for older trackers.

See: http://issues.roundup-tracker.org/issue2550688 for details.

Can you check a password change in the journal/history and
verify that you see:

   {scheme}*encrypted*

If it looks like:

   {scheme}the actual password hash

we are leaking the hashed password. I claim this code should prevent
the leak regardless of the templating language but...