gtk-passes displays a different (and wrong) QR code about passes HOT 7 CLOSED

Hi @spaetz ! Thank you for reporting the issue!

Yes, if fine with you, please send me the pkpass and I will fix it ([email protected])

from passes.

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

from passes.

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)

from passes.

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

from passes.

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...

from passes.

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.

from passes.

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.

from passes.