From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 1391698F for ; Tue, 13 May 2014 15:59:37 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E700F201CE for ; Tue, 13 May 2014 15:59:35 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id eb12so618550oac.25 for ; Tue, 13 May 2014 08:59:35 -0700 (PDT) MIME-Version: 1.0 Sender: jwboyer@gmail.com In-Reply-To: References: <20140511162918.GA2527@linux.com> <1995824.rdvEX5SOIt@avalon> <20140511171824.GB2527@linux.com> <20140512155320.GW12708@titan.lakedaemon.net> <20140512164921.GB3509@linux.com> <53710053.4040100@zytor.com> <20140513112525.GB10733@kroah.com> <20140513150520.GA15857@kroah.com> Date: Tue, 13 May 2014 11:59:34 -0400 Message-ID: From: Josh Boyer To: Sarah A Sharp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: PJ Waskiewicz , Jason Cooper , ksummit-discuss@lists.linuxfoundation.org, Anton Arapov , Dirk Hohndel Subject: Re: [Ksummit-discuss] [TECH TOPIC] QR encoded oops for the kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, May 13, 2014 at 11:51 AM, Sarah A Sharp wrote: > On Tue, May 13, 2014 at 8:05 AM, Greg KH 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 wrote: >>> > On Mon, May 12, 2014 at 08:50:27PM +0300, Teodora B=C4=83lu=C5=A3=C4= =83 wrote: >>> >> On Mon, May 12, 2014 at 8:09 PM, H. Peter Anvin wrot= e: >>> >> > On 05/12/2014 09:49 AM, Levente Kurusa wrote: >>> >> >> >>> >> >> What I wonder is how could we get the server back-end to not allo= w >>> >> >> the same oopses from bad users. >>> >> >> >>> >> >> Having a link like: >>> >> >> >>> >> >> oops.kernel.org/submit_oops.php?qr=3D$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 t= o >>> >> kernel.org by posting it in a query? >>> > >>> > That is what the kerneloops.org site is for, please use that for stuf= f >>> > like "automated oops reports", not bugzilla.kernel.org, as that is no= t >>> > 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