Re: Is there any issue with reportbug in unstabl or bugs.debian.org?
On Tue, 11 Oct 2011 16:26:09 -0600, Bob Proulx wrote:
> Camaleón wrote:
>> Bob Proulx wrote:
>> > (shock, surprise) You are saying that filling out a web form in a
>> > browser can run processes on the local host machine and send data to
>> > the internet? No it can't or it would be a severe security
>> > vulnerability. Please list any browser that allows this so that I can
>> > file the appropriately severe security bugs against them.
>>
>> With todays html5 specs out there and a capable browser? I wouldn't put
>> my hand on fire for that. And have you recently heard about GNOME and
>> javascript capabilities? They allow doing amazing things over a
>> browser.
>
> I admit that I know little yet of HTML5. Although one should never
> doubt the power of stupid people in large groups I cannot believe that
> HTML5 has been allowed to open such deep security holes in the system.
Yes, it can be true to believe but they are here and gnome3 in join with
gkt+ 3.2 and javascript is starting to make it firsts steps. You can read
more on the usuil IT press/blogs and related developer mailing lists.
> My confidence there and believe that it would have been Slashdot'd
> widely tells me that it can't yet have happened. Therefore I continue
> to believe that it isn't true until proven otherwise.
It won't be me who persuades you about that :-)
>> Besides, I'm sure you know that flash player plugin can contact you
>> webcam and audio devices very easily.
>
> Is that true on an ARM based platform? Remember that Debian supports a
> large number of architectures. AFAIK there is no Adobe Flash available
> for ARM based systems.
And what has ARM to do with this? Are you running an ARM based machine?
Yes? Then good for you :-) But people running flash player on their
systems are subject to that type of scannings.
> Is that true with Gnash (GNU Flash)? Gnash is the only flash player on
> my main desktop (although other machines of mine have the Adobe
> proprietary player). (Although I mentioned ARM above my main desktop is
> amd64. I didn't want to be misleading here. But I do have ARM based
> systems.)
Good, but again, are we talking about "you" specifically or we are taking
a more wide user case?
I am telling you what happens right now with technology that is available
in our systems, I can't speak for every concrete desktop there is on the
earth as you can understand...
> I am not as familiar but I believe even the Adobe Flash player operates
> within some containment of access, even if it is self-imposed and
> therefore open to attacks and vulnerabilities. If I had my wishes there
> would be no Flash based web sites.
To be sincere, I don't care about flash player very much, just put it as
an example of what can be done with a small plugin and a browser.
>> So, if that's something missing in Bugzilla (or another bug tracking
>> systems), it should be easily to add although I seriously doubt about
>> its usefulness.
>
> It has a high usefulness, although as a convenience. A BTS bug report
> is nothing more than an email message. A user can always follow
> instructions instead and create the email message fully manually. Ha!
> How often do people actually follow instructions? That is the entire
> reason for the bug helpers.
Bugzilla (and related web based bug tracking systems) also provides
wizards which guide the user to write the report. It's the same as
reportbug, you can customize the level of help you want to receive and
set that level as the default for the next time.
> But I disagree completely here that a web browser filling in a web form
> has access to the local system as it is intended to be impossible by
> design and security layers to run local programs across the local
> filesystem as a web form. Note that Javascript runs inside a security
> layer and is restricted from this access.
Oh, come on, is not that hard. In the worst scenario, you can tell the
user to download a script with instructions to run it and then send the
output to a file to be uploaded with the report.
That's all. It's possible, easy and convenient for the user that can run
the script when he/she wants and attach it to the bug later, when there
is Internet connection, for example.
>> > I have never ever seen reportbug crash.
>>
>> You must be then a happy camper and the luckiest person in the hill.
>
> Are you sure we are talking about 'reportbug'?
The last time I run I called "reportbug", not sure if that command will
point to something else. Hum... it goes to /usr/bin/reportbug.
> It was suggested by another that perhaps you were using 'reportbug-ng'
> instead which appears to be a Qt4 GUI based application.
I don't thin so, it's plain "reportbug".
> Do you have a .reportbugrc file? (I do not.)
Yes.
> What are the contents?
I can't copy the full file because I'm in another computer but it has the
usual lines: version, mode expert, ui text, from name, e-mail,smtphost,
smtphost user, smtphost password (empty), smtptls and that's all.
> Try moving it out of the way and running without local customization.
>
> $ mv ~/.reportbugrc reportbugrc.suspect
> $ reportbug -b somepackage
I had to not only remove that config file several times but also set
"ncurses" GUI as the default to avoid perpetual crashes...
> Since reportbug simply guides the user through sending an email the
> design of it is very simple. Ask a couple of questions. Build an email
> template. Start an editor for the user to finish filling out the email.
> Send the email. Although bugs exist in almost every program that seems
> too simple to crash. Launching the editor seems to me like the most
> risky part since people can choose anything and some of the choices
> could be quite problematic.
Yes, but simplicity does not mean it cannot crash in the middle of any of
those steps :-)
>> > I am hoping you filed a bug report on reportbug crashing! :-)
>>
>> I think no more. I'm tired.
>
> It is okay to complain. But complaints have much more weight to them
> when you can point to a bug report in the BTS concerning it. :-)
No need to tell... I do know that very well (I have written several
reports in Mozilla, KDE, GNOME, openSUSE and now Debian bug tracking
systems). It's just that sometimes you say: stop, that's much for me,
very time consuming task with small results.
Greetings,
--
Camaleón
Reply to: