[Ksummit-discuss] [TECH TOPIC] QR encoded oops for the kernel

Josh Boyer jwboyer at fedoraproject.org
Tue May 13 15:59:34 UTC 2014


On Tue, May 13, 2014 at 11:51 AM, Sarah A Sharp <sarah at thesharps.us> wrote:
> On Tue, May 13, 2014 at 8:05 AM, Greg KH <greg at kroah.com> wrote:
>> On Tue, May 13, 2014 at 07:41:15AM -0700, Sarah A Sharp wrote:
>>> On Tue, May 13, 2014 at 4:25 AM, Greg KH <greg at kroah.com> wrote:
>>> > On Mon, May 12, 2014 at 08:50:27PM +0300, Teodora Băluţă wrote:
>>> >> On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin <hpa at zytor.com> wrote:
>>> >> > On 05/12/2014 09:49 AM, Levente Kurusa wrote:
>>> >> >>
>>> >> >> What I wonder is how could we get the server back-end to not allow
>>> >> >> the same oopses from bad users.
>>> >> >>
>>> >> >> Having a link like:
>>> >> >>
>>> >> >> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
>>> >> >>
>>> >> >> would mean that malicious users could edit the $ENTROPY part and
>>> >> >> hence effectively report the same oops twice. Maybe some checksum?
>>> >> >>  Or will it be too much for an already damaged kernel?
>>> >> >>
>>> >> >
>>> >> > What did the old kerneloops system do for these kinds of things?
>>> >> >
>>> >> > Again, I'm concerned that a KS session for this will turn into an
>>> >> > implementation discussion, which is better done by email.
>>> >>
>>> >> Well, the discussion got a bit technical, but as Josh said, I see no
>>> >> point in doing that sort of talk (for technical discussion there's
>>> >> always the RFC thread [0]). I think what would be of interest is the
>>> >> way the workflow changes and the infrastructure you need to maintain.
>>> >> For example, at the moment, can you actually send an Oops directly to
>>> >> kernel.org by posting it in a query?
>>> >
>>> > That is what the kerneloops.org site is for, please use that for stuff
>>> > like "automated oops reports", not bugzilla.kernel.org, as that is not
>>> > going to work at all.
>>>
>>> It's clear that by default, any oops reported through the QR code
>>> generator should be reported to kerneloops.org.  Do you think there's
>>> additional value in *optionally* allowing someone to file a bugzilla
>>> report against that oops, or do you think there's no value in using
>>> bugzilla.kernel.org at all for this project?
>>
>> As I don't use bugzilla for kernel stuff, I really don't recommend it.
>> Espcially if it would give a false sense of "I reported it to the
>> developers" feeling to users that someone would actually now look at the
>> issue.
>
> And everyone will look at kerneloops.org instead?
>
> There are some maintainers (like Bjorn in PCI) that do use bugzilla.
> Other maintainers want people to report bugs to the mailing list.
> It's confusing to bug reporters to figure out where to report bugs.
>
> If MAINTAINERS listed either a bugzilla URL or a mailing list email
> where bugs should be reported to, that might be helpful to users.  The
> phone app could use that file from a recent kernel to figure out
> whether to allow the user to report the oops to bugzilla.kernel.org or
> to create an email to send to the right mailing list (and make sure
> it's a plain text email).
>
> It's these kinds of social aspects of the project that I'd like to see
> get discussed at kernel summit.

We have similar dilemmas in Fedora as well.  Our users report bugs in
Red Hat bugzilla, which nobody wants to look at.  So we wind up trying
to forward relevant information upstream, and the individual
preferences of the maintainers is hard to keep track of.  Reducing the
problem to the absurd, we could just screen scrape RHBZ reports and
dump them on LKML, but I really doubt that is going to help anyone.
I'd be interested in discussing the "how/where to report issues"
problem.

josh


More information about the Ksummit-discuss mailing list