MRC Converter Suite Errors

jruss · August 12

Hi everyone! I've been running conversions for our staff from the .json Password Boss exports to .1pux files using the MRC Conversion Suite. All have been converting successfully until I tried a specific employee's .json file. It is throwing multiple errors... When I opened it in Notepad, I saw that excess quotation marks were present and tried reducing those. That didn't help. I tried a fair amount of other changes, none of which worked. Can you please assist? Please right-click the image, then "open in new tab" to enlarge. Thank you

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Windows 11
Browser: Not Provided

jruss · August 12

Hi! I've been running conversions for our staff from the .json Password Boss exports to .1pux files using the MRC Conversion Suite. All have been converting successfully until I tried a specific employee's .json file. It is throwing multiple errors... When I opened it in Notepad, I saw that excess quotation marks were present and tried reducing those. That didn't help. I tried a fair amount of other changes, none of which worked. Can you please assist? Thank you!

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Windows 11
Browser: Not Provided

jruss · August 12

Hi! I've been running conversions for our staff from the .json Password Boss exports to .1pux files using the MRC Conversion Suite. All have been converting successfully until I tried a specific employee's .json file. It is throwing multiple errors... When I opened it in Notepad, I saw that excess quotation marks were present and tried reducing those. That didn't help. I tried a fair amount of other changes, none of which worked. Can you please assist? Thank you!

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Windows 11
Browser: Not Provided

MrC · August 12

Hi @jruss

I'm guessing this might be a line ending problem. Was the JSON file created on Windows, or a Unix-y system? The PasswordBoss test JSON exports I have use 0x0a as line endings for macOS, whereas the Windows export has 0x0d 0x0a. My test files convert fine, regardless of platform.

If you might also let me know what version of PasswordBoss you are using, that might help.

Finally, if you can provide a little snippet that shows a sanitized bit of the problematic JSON, I might be able to see something.

You can ignore the excessive quoting you see in your error screenshot... look instead at the raw JSON.

MrC · August 12

Oh, one more question... What version of Strawberry Perl are you running?

MrC · August 14

@jruss - Do you still require assistance?

jruss · August 15

Sorry, yes! I was out sick yesterday and for part of today.

I'm using Strawberry Perl version 5.38.2.2-64bit.

Here are some snippets from the .json file. I replaced part of the emails/usernames with "EMAIL" and the passwords with "PASSWORD". I tried to grab a few of the lines referenced in the errors (the first contains line 342, the second contains 1104, the third contains 833, and the fourth contains 153).

MrC · August 15

Hi @jruss

I hope you're feeling better today.

Wow - that JSON data is severely broken.

I don't think P.B. has been updated since Nov 2022, right? So every export should be affected (unless this is some odd edge case issue w/P.B.'s exports).

The only thing I can think of here is that the user has a copy of a P.B. JSON export as a value for some field or notes, and the re-export is having trouble with this. That might also account for the "0a" line endings.

Would you be able see if this theory yields some insight?

jruss · August 15

I'm not sure when PB was last updated, though I do see on their site that the latest notes were in 2022. Possibly, they stopped publishing release notes at that time? It would surprise me if they didn't have to do any patches in two years... As for the file conversions from PB to 1P, this is the only conversion that's failed so far.

I'm not really sure what you mean. While I have a technical background, I have very little familiarity with JSON. If you're saying he may have exported it multiple times, I know he had exported it three different ways: .json, .pdf, and (I believe) .txt. If he previously exported an additional .json file, it doesn't appear to be there anymore.

MrC · August 15

Hi @jruss

I suppose you can check the About box (or similar) to get the app version for that user. I don't have my VM running currently, so can't check the latest version.

There are several releases in 2023 stating "bug fixes and performance enhancements" for the iOS app in the App Store. The developer clearly doesn't care.

It wouldn't matter how many times the user exported; rather, I was thinking perhaps the user exported to JSON, copied that content as raw text, and pasted it into an item.

We can ignore the converter as being the source of the issue. The JSON examples you've posted are invalid JSON. Every attribute name and value needs to be double quoted, as in this "foo" attribute with a "bar" value:

"foo": "bar"

If a double quote is to be used in the tag name or value, it needs to be escaped with a backslash, as in:

\"

The JSON file should look like this sample:

{
  "folders": [
    {
      "name": "SomeFolder",
      "id": "5d7875c4-8852-4027-99d8-48859b444f41"
    },
  ],
  "items": [
    {
      "name": "A driver license secure note",
      "secure_item_type_name": "SN",
      "color": "#da3b01",
      "type": "DriverLicense",
      "subtitle": "555444abc",
      "identifiers": {
        "ignoreItemInSecurityScore": false,
        "expires": "99/2099bogus dates",
        "country": "us",
        "firstName": "Sally",
        "lastName": "Brown",
        "driverLicenseNumber": "555444abc",
        "name": "A driver license secure note"
      },
      "tags": []
    },
  ]
}

The values seen in your samples look like:

""type"": ""Website""

If the attribute really had a double quote in it's name, it would be properly escaped as:

"\"type\"": ...

Likewise for the value "Website".

But notice also that my example, the "tags" attribute should be a non-double-quoted array in square brackets, where your square brackets end with a double quote. That double quote seems to end after the invisible newline character (hex A) followed by the closing curly bracket and comma separator:

 ""tags"": []"
    },"

In fact, every single line ends with the hidden newline character being double quoted, with the closing quote being either immediately after the newline, or somewhere later. Everything about this is wrong. Since I don't have your data, I can't tell where actual "items" begin and end. Likewise the "folders" list.

Again, what I had been theorizing as a possible cause w/the P.B. export is that the user copied / pasted the actual raw JSON text data into a some item's Notes, or possibly into some value. Still, my theory is weak, since proper JSON escaping would require P.B. to properly escape double quotes - backslash for any double quote which is part of a attribute name or attribute value. But I don't have any other explanation for what would cause the JSON data to be so malformed.

Earlier I mentioned that a P.B. Windows export JSON should contain the two characters 0d 0a for line endings. Your data has only 0a. There are a few things that can cause line ending translations:

auto text conversion layers for file systems
copy / paste
text editors
misc tools
CSV exports

The last one, CSV exports... The CSV rules for escaping a double quote are to double up the double quote. So:

Foo    A "double quoted" value.

would CSV encode as:

Foo,"A ""double quoted"" value."

Here again we come back to my theory that the user copied a P.B. export (perhaps CSV), and pasted that content into one of the entries. P.B. may simply choke on this.

Does this provide you with some help in helping the user look for this?

jruss · August 19

@MrC Sorry for the delay. I'm working with our MSP to get further guidance in relation to your comments, and will reply soon. While I have some background in I.T., this is largely beyond me.

MrC · August 19

@jruss

No worries.

I'm working on testing out my theory in a Windows VM. It may a bit, as I have to do some updates.

MrC · August 19

@jruss,

I've installed the latest P.B. for Windows (5.5.5220.0 db49 release: 52), but have been unable to replicate any export issues, and conversion works fine.

On a whim, I tested pasting the JSON text into a spreadsheet, and saving as CSV. As I expected, the results of the data look identical to yours, minus the double quoting of the line separator (the double quotes at the end of each line and ending on the next line). Here's a side-by-side comparison of yours (white background) and mine (black background):

So I'm fairly confident that somehow this user's data, or some portion, was exported as JSON, opened in a spreadsheet, saved as CSV, and that CSV data is being used as JSON. What happened at various stages would be unclear to me.

The line ending differences, I believe, is because I'm not working directly under Windows, instead working on my Mac while trying to provide a plausible theory.

Unless you're able to obtain valid, unmodified JSON from that user's export, there's not much more I can offer on this end.

MRC Converter Suite Errors

Comments