gtk-passes displays a different (and wrong) QR code

[spaetz]

Hi, I have a german subscription for the nation-wide train ticket (Deutschlandticket). The ticket website, https://github.com/KDE/kitinerary and PassAndroid show a 355 byte Aztec code as QR code, while passes only shows a brief number as Aztec code (I think the ticket number). The Passes code is definitely not the correct one, although I used the very same .pkpass file as eg for passandroid and kitinerary.

I would attach the pkpass but as it is a currently valid ticket with all my data in it, I would rather not make it public. But I could email it to you, if you are interested.

P.S. Forgot: I am using the flatpak 0.8 version, not sure if things might have been fixed since then.

[pablo-s]

Hi @spaetz ! Thank you for reporting the issue!

Yes, if fine with you, please send me the pkpass and I will fix it (pablo@sanchezrodriguez.me)

[fogti]

At least I can reproduce this problem using zint on the contents of the pkpass (extracted using jq).

[fogti]

I took the aztec data from a ticket page and the .pkpass data package from the same page.

./ZXingReader -format Aztec -bytes ticket.png > ticket-decoded.raw
jq -r '.barcodes[0].message' < ticket.pkpass.extracted/pass.json > ticket-barcode.raw

both files have the same trailing 11 bytes (the last 8 bytes seem to be the VDV pubkey identifier). the byte before that differs (the version from the json file has an additional 0xc2 byte inserted there)

[fogti]

maybe take a look at the unpack&validate stuff in https://github.com/KDE/kitinerary/blob/9473c03be6c650d1137d43b47a1220a452c8e7f5/src/lib/vdv/vdvticketparser.cpp

[fogti]

ok, no it's worse actually (the above code already works on the properly decoded data, recognizable because the tag at the front matches what's expected)

decoded:      9e    81    80 07
vs.
from-json: c2 9e c2 81 c2 80 07

the whole "from-json" thing is interspersed with c2 and c3 values, although I don't know yet where they came from...

[fogti]

I suppose jq -r '.barcodes[0].message' < pass.json | iconv -f 'UTF-8' -t 'LATIN1' (notice the conversion to LATIN1, as specified in the associated json)

% jq -r '.barcodes[0].messageEncoding' < pass.json 
iso-8859-1

Maybe I've spent way too many hours to debug this, but I guess this mostly solves this, conditional transcoding now "just" needs to be integrated into the barcode evaluation code.

[pablo-s]

I have taken a look at this issue and I think I found the problem.

Passes is mostly written in Python, with the exception of the logic used to generate the barcodes (C language).

The problem seems to be in the way I am converting Python types into C types.