For context, kernel panics seem to sometimes be encoded as a URL in the QR code by distros. The panic text is encoded as a numeric parameter. For example:
https://jexposit.fedorapeople.org/drm-panic/#?a=x86_64&v=6.17.0-rc2+&z=64016708045408584681305161836175901065787789727173061004041671633088591186286363786562987653814347942450168430510852681524688435157911241621365859153819732690406649525043247774110913752991389170560320455163781439079986337356710273501164645667555084821480237326301207073831710176482850121513079951455217310046422632328303510474264780788030301611164774573122018172510304672562667379831349924441560360997679573341401750485619388375493[... many more digits]
This script is to decode such kernel panics without needing to provide it to an external service.
In the particular URL example, the panic is not necessarily sent to a server, because it's in a URL fragment (`#`), but still.
userbinator 1 days ago [-]
The panic text is encoded as a numeric parameter.
This script is to decode such kernel panics without needing to provide it to an external service.
WTF. A solution for an entirely self-inflicted problem.
jolmg 1 days ago [-]
> self-inflicted
Distro developers and user are separate people. Also, a person viewing the QR code is not necessarily the owner of the panicked system.
userbinator 13 hours ago [-]
Distro developers and user are separate people.
No, they don't have to be. How did this user-hostile attitude infect Linux too?
Also, a person viewing the QR code is not necessarily the owner of the panicked system.
So what? Stop hiding things from users. If they don't care they don't have to read. If they do, don't make them jump through additional hoops.
jolmg 10 hours ago [-]
It being user-hostile is debatable. It's meant to be friendlier, as described in the Fedora link I shared. Coincidentally though, I got a panic yesterday and my phone wasn't able to scan the QR code, lol, so who knows what the panic was.
The non-QR/textual panics can be restored with a kernel/module parameter as described here:
The QR code can be made to provide the text itself (non-URL-encoded) by rebuilding the kernel with CONFIG_DRM_PANIC_SCREEN_QR_CODE_URL unset.
userbinator 1 days ago [-]
I hope this is Windows-inspired satire. If I get a kernel panic I want something I can actually read.
kouosi 1 days ago [-]
It's been there for like 2 years (6.12 iirc) so it is not satire it is real.
natas 1 days ago [-]
I think that's a really good idea! Would love to see this upstream
bri3d 1 days ago [-]
It is? This is drm-panic qr codes from Linux 6.12. It’s a neat feature but I’m not sure why this random implementation is particularly interesting.
theowaway213456 1 days ago [-]
Can't a phone decode a QR code natively? I don't even get what it does
hamandcheese 1 days ago [-]
If you decode it and open the link, you are potentially leaking data to whoever controls the domain of the URL.
creatonez 24 hours ago [-]
It's a possibility, but it's not how these kernel panic viewer websites are currently implemented. They do the decoding on the clientside, with the data stored in the URL fragment, which is not sent to the server by default.
Still good to have alternative implementations, though. The Javascript could be silently stealing the URL fragment on only specific requests, so there's no real way to audit it to be sure.
ranger_danger 4 hours ago [-]
This is why I like to use Binary Eye, it never acts on anything automatically when scanning a code, you have to tell it to.
catlifeonmars 1 days ago [-]
Link previews even! Just paste it into a group chat and everyone’s message clients will happily issue a GET request.
charcircuit 1 days ago [-]
That's not how it works. The chat app requests the link preview and caches it.
catlifeonmars 10 hours ago [-]
That’s how link previews work on iOS (it was the cause of the zero click RCE a few years ago by executing row hammer through WebView), so I guess it depends on your software.
ErroneousBosh 1 days ago [-]
This sounds like the panicky adverts from 20-odd years ago "YOUR COMPUTER IS LEAKING YOUR IP ADDRESS!!11!!""2!!2!!"
https://discussion.fedoraproject.org/t/f45-change-proposal-d...
This script is to decode such kernel panics without needing to provide it to an external service.
In the particular URL example, the panic is not necessarily sent to a server, because it's in a URL fragment (`#`), but still.
This script is to decode such kernel panics without needing to provide it to an external service.
WTF. A solution for an entirely self-inflicted problem.
Distro developers and user are separate people. Also, a person viewing the QR code is not necessarily the owner of the panicked system.
No, they don't have to be. How did this user-hostile attitude infect Linux too?
Also, a person viewing the QR code is not necessarily the owner of the panicked system.
So what? Stop hiding things from users. If they don't care they don't have to read. If they do, don't make them jump through additional hoops.
The non-QR/textual panics can be restored with a kernel/module parameter as described here:
https://wiki.archlinux.org/title/Kernel#QR_code_on_a_blue_sc...
The QR code can be made to provide the text itself (non-URL-encoded) by rebuilding the kernel with CONFIG_DRM_PANIC_SCREEN_QR_CODE_URL unset.
Still good to have alternative implementations, though. The Javascript could be silently stealing the URL fragment on only specific requests, so there's no real way to audit it to be sure.
https://www.usenix.org/system/files/usenixsecurity23-han-xin...
https://www.tomsguide.com/computing/online-security/new-qr-c...
Qr -> URL -> Panic Log