linux-kernel - Re: [RFC] QR encoding for Oops messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 23 Mar 2014 15:38:39 -0400
From:	Jason Cooper <jason@...edaemon.net>
To:	Teodora Băluţă <teobaluta@...il.com>
Cc:	Levente Kurusa <levex@...ux.com>, Dave Jones <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Subject: Re: [RFC] QR encoding for Oops messages

All,

On Sat, Mar 22, 2014 at 08:20:01PM +0200, Teodora Băluţă wrote:
> On Sat, Mar 22, 2014 at 7:09 PM, Levente Kurusa <levex@...ux.com> wrote:
> > On 03/21/2014 02:28 PM, Jason Cooper wrote:
...
> >> I would definitely like to see the QR output incorporated into a
> >> kernel.org url.  That would remove the need for installing another app,
> >> and would ease bug reporting.
> >
> > I still struggle to understand how could that be done. We can encode the
> > QR code as ASCII. Okay, that's fine, however it is very long. Encoding
> > 'Unable to handle kernel paging request at 0000000f' gave a 449 character
> > long sequence with very strange characters [0]. We should try to shorten
> > it, imho. Not sure how to do that though.

The man page for qrencode says you can have up to 4000 characters in a
qrcode.  However, I've seen readers have trouble with a 2048bit ascii
armored PGP public key (3929 characters).

I grabbed a random oops from oops.kernel.org, it weighed in at 1544
bytes, not too bad.  I then did:

$ echo "https://oops.kernel.org/?qr=`cat oops.txt | gzip -9 | base64 -wrap=0`" | wc -c
993

The benefit of a url is that any QR reader can automagically report an
oops.  While a specific app could parse the URL/oops locally if the
user desires.

> it misses the point of having a QR code in the first place. The way I
> see it, having a QR decoder app installed that can do an offline
> decoding is a less greater effort than popping out a browser on the
> machine you're working on.

I think you're selling the advantage of the QR code short.  Automated
reporting (via the url) is a _huge_ plus.  The app you conceive of could
still parse it in place if the user desires.

My point for the URL isn't to use the internet/server to automate oops
parsing for the user.  Rather it's to make it easy to report oopses to
developers.  While still preserving the ability of your app to parse it
for the user.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/