Package: reportbug Version: 4.12.4 Severity: normal As I haven't been able to find a feature request for that, here is one! Dear reportbug maintainers, the contest of this request is the -devel (sub)thread started at <http://lists.debian.org/debian-devel/2010/07/msg00492.html>. In subsequent messages, it has been argued that permitting to report bugs via http (actually, via port 80 ...) would remove some more barriers to bug reporting, due to firewalling and the like. I understand that for such a feature mere support in reportbug isn't enough, so you might want to block this feature request by some other feature request on debbugs (I haven't yet checked whether the latter request already exists or not). Cheers PS that thread just made me try again the GTK2 UI of reportbug: it's just *great* nowadays, kudos!
Thanks Don! I took the freedom of inverting the block relationship though; arguably Sandro can't go forward with support on the reportbug side until there's support in debbugs :-) BTW, since reportbug it's already using the SOAP interface for bug querying and the mail interface for bug submission, the simplest way forward is probably just to add a submit SOAP method, which takes a complete (MIME?) mail as payload and delivers it locally. Just my 0.02€. Keep up the good work, Cheers.
Hi, *cough* *cough* reportbug is still using web scraping to get bugs information :( I have plan to use SOAP soon (FSVO soon) but it's not there yet, and I don't think it would be a wise idea to code it just before the freeze starts. for sure that would help to have a consistent way to interact with debbugs, given SOAP it's already used, let's just continue with that, what do you think? Cheers,
Hello Olivier, On Wed, Jul 28, 2010 at 09:12, Olivier Berger <olivier.berger@it-sudparis.eu> wrote: so you should have sent this comment to 590269, where it's actually requested the http submission feature in debbugs, not on the reportbug bug, that's downstream of 590269. Anyhow, I find it rather odd to call OSLC-CM "standard" or "more standard than SOAP", since I've never heard of it, and I worked a lot on interoperability between heterogeneous systems, where I find SOAP (or plain REST) a lot more usable than any other rich format. The lower the entry level, the easier for tools & people to adapt to it. SOAP it's already available on BTS side, so it has definitely and advantage over others. Anyhow, it's a decision debbugs owner has to take, and so this is only a comment; i'll just use what will be available. Regards,
Ciao Sandro. Le mercredi 28 juillet 2010 à 09:26 +0200, Sandro Tosi a écrit : That's what I thought I had done... using bts --mbox show 590269 but I was tricked by the automatic proposal to CC 590214 :-(... anyway, the principle is that both server (debbugs) and client (reportbug) should speak the same language, so that's not completely off-topic... it's just that the server is more concerned by interoperability with more clients probably. Thanks for fixing and CC-ing the proper debbugs one. In can understand your point as I've been myself working on bugtracker interoperability for years and only heard about OSLC-CM one year only after they had started to elaborate the process. The fact that you never heard of OSLC-CM is probably related to you not noticing my numerous posts about it ;), but more seriously, because it has mainly been elaborated by big proprietary vendors. Notice I haven't called it "more standard than SOAP". It's just that it has all properties of a good standard, i.e. a specs which propose some properties, and not just one instance of an API of a particular tool. But in any case, I think *if* one thinks about designing a new API, and REST is an option, then I would definitely *advise* to check OSLC-CM [0] instead of reinventing another wheel. If the properties of OSLC-CM don't fit, then... ok... but just because you ignore something doesn't dismiss it I guess... OK, then, now you know about it, if you don't like it, period. Sure. The point is just, with a (proposed) standard, the couple reportbug + debbugs may not be the only tools that can implement some connection between each-other, and adopting OSLC-CM may help foster interoperability with other tools that (will) speak OSLC-CM (like Mylyn). Sure, one has to implement something... and the rest is void... only, now, you are aware that OSLC-CM exists ;) My 2 cents, Best regards,
Life runs in circle: I was about to summarize the discussion and submit a feature request to keep track of this. I gave up after discovering I did that about 1 year ago at the last iteration of the very same discussion (see #590269). I'm Cc:-ing the bug log to store in it the only new element I've been able to spot. Namely, it would be nice if the HTTP "transport" could detect on the fly syntax errors in the bts message, something we can't do for SMTP (unless we control the MTA of the user). I'm pretty sure Don welcomes patches for #590269 ... Cheers.
tags 590269 + patch thanks As briefly discussed on IRC, here is (half) patch to implement this feature request. It's a CGI that: - receive via HTTP file upload a bug report. The bug report is meant to prepared on the user machine by reportbug as usual, so by default it will contain all the information that mail-submitted bug reports contain - do some syntax checking on the bug report, and fail with an HTTP error code if that fails - do some mail header sanitization to reduce SPAM effects. AFAICT, after sanitization the SPAM risks of using the CGI would be the same that we have at present with the mail-based submission interface It's only half a patch because, for complete testing, we also need a patch for #590214 (Cc:-ed), i.e. we need support in reportbug for delivering a MIME bug report via HTTP upload rather than via mail. If a kind soul can write this, I'll be happy to set up a test instance of the script for more wide testing. Note that at present, the following testing path does *not* work properly: - prepare a bug report with reportbug - save it as a draft on disk and quit - upload the file using the CGI because the "save to draft" feature of reportbug does not save the entire MIME bug report (e.g. it lacks attachments and other details). So we really need proper HTTP upload support in reportbug to proceed. If nevertheless someone want to test the attached CGI, you need to set $bts_to to 'submit@bugs.debian.org' and $DEBUG to 0 (see comments in the source code). Feedback is welcome, Cheers.
Hello I'm writing a patch for reportbug, and I believe the cgi might need some minor tweaks: If the bugreport is a security problem, reportbug asks whether it is an undisclosed vulnerability. If the answer is Yes, the report is NOT to be sent to submit@bugs.debian.org but rather to team@security.debian.org. Right now, the CGI will override the destination and publish the problem on the BTS, which is probably a Bad idea™. Additionnaly, there are a few other addresses that would be nice to support: reportbug -kudos sends mail to: _package_ @packages.debian.org If the security tag is present, reportbug will cc: Debian Security Team <team@security.debian.org> Debian Testing Security Team <secure-testing-team@lists.alioth.debian.org> If the user sends additionnal information, report bug will send to Debian Bug Tracking System <nnnnnn@bugs.debian.org> Right now the cgi will post to submit, and it might be catched by the BTS [1] but it would be nice to support these addresses too. The bugreport cc: option is only writing X-Debbugs-CC headers, so this is not an issue. How bad would it be to support all adresses matching *@*.debian.org in to: and cc:, regarding spams? My perl level is close to nil. Can anyone look into that? [1] http://www.debian.org/Bugs/Developer#subjectscan
In this case, reportbug should probably just ask people to e-mail team@security.debian.org details instead of sending a bug report. These aren't really necessary. These should be X-Debbugs-Cc:. The BTS will catch these, but accepting messages to a bug would also be allowable. If it's not talking directly to the BTS, I basically don't want to support it in the BTS. I suspect that allowing the destination to be given as destination=(nnnnn|submit|control) with a default to submit would be sufficient. I'm also concerned about allowing through bugs/messages which do not correspond to a working e-mail address... so it's possible that I will implement the CGI with some sort of cache coupled with a response.
There is a team GnuPG key: http://www.debian.org/security/faq#contact which would alleviate snooping concerns.
Heya, thanks a lot for working on the reportbug part of this! Executive summary: feel free (you, or anyone else interested in Perl hacking) to change the CGI script as you see fit. I really care about offering users the ability to use HTTP as a transport, possibly as the *default* transport, for bug reports because I'm convinced that SMTP is a real blocker for many users. But I don't think I'll be hacking again on this CGI in the near future; if it's easier for you, feel even free to rewrite in something non-Perl-ish. Either way, coordinating with Don to have something he'll be happy to integrate in debbugs proper seems like the best way forward (and maybe that means sticking to Perl? dunno...). Thanks for your interest in this, I really appreciate! Cheers.