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. 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. > 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. 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.) 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. > But there is no bug nor security flaws here, because the user agrees > in being scanned ;-) On that point I agree. When the user-admin installs something they implicitly agree to it. > 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. 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. > But no, I was not referring to that specific ability of reportbug (which > I still find a bit intrusive) but the option for looking into another > bugs already opened for the same issue. I always search the BTS myself first to look for problems before reporting them. Then when I do invoke reportbug I invoke it with the --no-query-bts option to avoid that interaction. $ reportbug -b somepackage Looking now I see that it is possible to put this into the $HOME/.reportbugrc file and make it the default. I have now done so as a convenience. > >> And bugzilla does not tend to crash when writing bug reports >:-) > >> > >> In fact, I usually avoid using "reportbug" because of its high > >> instability (it's annoying having to re-do a full report several > >> times...) and finally send the report "manually" -by e-mail- which is > >> not a task for newcomers neither encourages people to write bug reports > >> ;-( > > > > 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'? It was suggested by another that perhaps you were using 'reportbug-ng' instead which appears to be a Qt4 GUI based application. Do you have a .reportbugrc file? (I do not.) What are the contents? Try moving it out of the way and running without local customization. $ mv ~/.reportbugrc reportbugrc.suspect $ reportbug -b somepackage 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. > > Since it is just a python script I would think that an actual crash > > would be quite difficult. > > Err... that must be because you have never seen it explode in front of > your face :-) Correct. > > 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. :-) Bob
Attachment:
signature.asc
Description: Digital signature