[BUG] Displayed QR codes are wrong

[TLATER]

Describe the bug The scanned-out QR codes for at least easyjet, schiphol security check bookings and Dutch NS rail PDFs end up different from what ia actually on the PDF.

To Reproduce Steps to reproduce the behavior:

1. Add PDF with QR code
2. Squint at resulting QR code until you spot the inconsistencies

Expected behavior QR codes should match between what greenpass displays and what is actually on the PDF.

Screenshots

Smartphone (please complete the following information):

• Device: Pixel 6
• OS: Android 14
• App Version: 4.2.0

[Hoggy-1]

Hi,

I imported my train ticket from Czeske Drahy (Aztec?) and my Kaufland Card QR code from PDF/png. I can confirm that the versions in Green Pass Wallet look different than the original. However, I did not try to use them.

I also recognized that if I scan QR codes for 2FA setup, e. g. for Github, the version in Free-OTP app also looks different and it still works. Have you actually tried your scanned QR/Aztec/... codes even if they look different? I am no expert, but maybe something is computed into QR codes generally like a timestamp, but this does not affect the validity.

I have no idea how QR code generation and recognition works, but I also expected to see identical representations.

I will comment after I tried to use my QR codes.

Update: My device info: Device: Pixel 8 OS: GrapheneOS 2024121200 (Android 15) App version: 4.2.0

[Hoggy-1]

I ran my original QR code and a screenshot from the imported one from Green Pass through https://www.onlinebarcodereader.com/ Both returned the data which was expected (the number below the QR code). The only difference is that according to the website the imported QR code "contains not printable characters."

So I guess that the code looks different because something is added to the data during import, e. g. 1) decode scanned code; 2) generate QR code from data (which contains some additional data for some reason). This causes the new QR code to look different. As long as the reader is able to cooperate with the additional non-sense, the code probably works.

Update: I compared the HEX data output and the only difference is an additional line feed (0x0a) at the end of the imported QR code. So, as long as the reader ignores this LF then it should still decode the valid data. Maybe this LF is added, because of the different support code types and maybe some code types support multi-line data?

[Hoggy-1]

I tried both my Kaufland Card QR code and my ticket aztec code Form Czech Train company from Green pass and they worked.

I can also say that other apps like Catima behave in the same way, I. e. showing a different code with the same effective data.

Unless there is a definite report of codes not working from Green pass or if there is another justification for considering this behavior invalid, I don't think that the described behavior is a bug.

[TLATER]

Hmm, in my case it failed to work for both EasyJet and the Dutch NS rail scanners, though I never ended up using the QR code in the screenshot. It took about 5 times of it just not working and annoying staff for me to double check if the images are actually the same. There's a chance it was just bad luck with scanner positioning and glare or somesuch, but that seems unlikely given how often it went wrong?

At least in the case of EasyJet's scanner opening the PDF with a PDF viewer and zooming in resolved the problem (using just greenpass made it hard to position the phone without the scanner picking up the copied QR code).

I wouldn't necessarily expect all scanners to ignore LFs, since most use cases probably have no need for a random LF in the data they scan, and that anyway sounds like an easy enough fix, whether that has to happen in some library or downstream.

Thanks for the sleuthing in any case, glad it's not just that I'm going insane :D