Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#337 end of string problem

open
nobody
5
2012-09-17
2012-03-09
rabbe
No

By mistake, when I was changing the Default Autotype String, I left a backslash ( \ ) at the end of the string. Following this, the database saved ok and I was able to re-open the database for a while, but when trying to open this database with Password Gorilla (on a MacBook Air), I received an "incorrect end of string" error message and the database would not open. After a bit, I found that I could not open the database with Password Safe either: I received a "corrupt database" message.

So, I reverted to a backup copy of the database and began to run experiments - that is when I discovered my error, and adding subtracting the incorrect backslash reliably caused the database to fail or work with Password Gorilla.

Now that I know, I will be careful but, it would be good if Password Safe would check for incorrect Autotype String syntax and warn the careless user (such as myself).

Many thanks for your attention to this problem!

Robert C. Abbe

Discussion

  • Rony Shapiro
    Rony Shapiro
    2012-03-09

    Here's some more detailed info, from Zbigniew, one of Password Gorilla's current maintainers:

    One of our users told us in issue #75 (https://github.com/zdia/gorilla/issues/75) that one of his Password Safe databases could not be opened by PWGorilla.

    \"The change I made that seemed to lead to the trouble was to change the autotype string to: \d200\u\t\p\n\...\"

    PWGorilla is coded in Tcl/Tk and it expects a character after the escape character \"\\". As seen by Tcl the user\'s string is not terminated and so Tcl will cause an error.

    How to solve this issue?

    On the one hand you could implement a string check and advertise the user that the string is mal-formatted, on the other hand we could we could modify our string reading code to handle the bad data. During Twofish decryption PWGorilla is comparing the database saved string length with the \"actual\" string length which will lead to an error if the string is badly composed.

    I would still like to ask for the special delimiting characters in non-default preferences strings that have been implemented since version 3.26. In formatV3.txt I can read that:

    Note: normally strings are delimited by the doublequote character. However, if this character is in the string value, an arbitrary character will be chosen to delimit the string. Version 0x0309 added database wide special symbols to the Non-default preferences (0x02).

    Could you tell me what these special symbols are like?

    And according to formatV3.txt a normal string description is:
    countbyte, string

    Would it be an alternative solution for the delimiting issue to implement \"netstrings\" (see: http://cr.yp.to/proto/netstrings.txt)? This concept would allow sub-strings.

     
  • DrK
    DrK
    2012-03-11

    To add to Rony's update:

    The main & original Windows version of PasswordSafe (now at V3.28) and the definitive source of the preferences stored in a database, treats the AutoType string as that - a string of characters and not special characters until it is actually used as an "AutoType string". Having an extra backslash in this field would not prevent PWS opening the database.

    As to the comment re: the new Symbols as per the FormatV3.txt file. Again, from the definitive version of PWS, this is just a string of normal characters. Symbols are defined as non-alphanumeric (i.e. not A-Z, a-z or 0-9).

    David