maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Browser process opens ports on all interfaces.|
|Product:||[Maemo Official Applications] Browser||Reporter:||r.c.g|
|Component:||MicroB engine||Assignee:||unassigned <nobody>|
|Status:||CLOSED FIXED||QA Contact:||microb-bugs|
|Priority:||Unspecified||CC:||andre_klapper, antti.vaha-sipila, maemo, moe|
EXACT STEPS LEADING TO PROBLEM: None - Problem exists in the factory default settings. EXPECTED OUTCOME: The browser process should not listen on external interfaces, or an option should be provided to turn this behavior off. Another alternative (if technically possible) would be to make the process only listen on the local loopback interface. This problem is discussed also in the following thread: http://talk.maemo.org/showthread.php?t=38700 ACTUAL OUTCOME: A "browser" process running as user opens by default a random unprivileged UDP port on all network interfaces. After some browsing also open (listening) TCP ports could be discovered also after the browser window (GUI) was closed. REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20091227 Gentoo Firefox/3.5.6
Confirmed also on 2.2009.51-1. Seems like an oversight to me, at least I can't think of a good reason why it can't only bind to the loopback interface.
well. you can easily get udp *:1900 and udp *:39400 in browser ui by using 'open file' from the bookmarks view. Those are UPnP (which makes sense, it can try to show you random shares -- i doubt they'll work, but hey!) and SIP (i can't explain this one and don't want to, but it's clearly coming from the dialog, so it isn't our fault). So, here's the deal: i don't care what you think, but giving a bug without steps to reproduce is not acceptable. Steps to reproduce should not be "gleaned" by reading another web page after having read your useless rant. Here are the steps I used for testing: 1. open xterminal 2. while true; do lsof -u4|grep UDP; done 3. open browser (=bookmarks) 4. switch to xterminal, see nothing 5. switch to browser (bookmarks) 6. tap on facebook 7. switch to xterminal, see udp for DNS resolution by browserd 8. close browser 9. open another xterminal 10. killall browser 11. open browser (=bookmarks) 12. tap the title area 13. tap open file 14. switch to xterminal, see udp for 1900 (UPnP) and 39400 (SIP) 15. switch to browser (=file picker) 16. close the file picker 17. switch to first xterminal, press enter, see more for udp 1900/39400 18. switch to second xterminal 19. killall browser Nothing interesting. But this is "steps to reproduce" and any bug without them will be summarily marked as invalid. Your steps don't have to be good, but they have to exist. At the very least you need to include steps 1 and 2 in any bug you file. This was with an internal build from this week. However my point stands. I do not want to see a bug without steps to reproduce. Do not reopen this bug. Do feel free to file a proper bug with steps to reproduce. Don't worry, your bug will not be ignored if you file it properly.
If someone wants to quibble about the resolution, it's probably "fixed in 53-2" (it's what I had around, I'm not sure about 52). However I do not want to reward poorly filed bugs with happy resolutions. And a bug filed on the 11th of january without proper steps has nothing to do with a version that was already working properly before that time. wrt release plans, which we never discuss, my feeling is that there could be an update that is roughly '51-1' as noted in comment 1, in which case that update (after the 44-1) will not have it. There is always the chance of future minor releases (44-1 was a minor release over 42-11), and as we are not sure what 'fixed' this 'bug', it is unlikely that whatever that was would end up in such minor releases (even though it's likely that the numbers for that 'week' will be 'newer' than the 53-2 mention above). Which means you're probably waiting for the next 'major' release. And again, we never discuss release schedules. I personally find out about release dates/numbers from customers when they tell me they've installed their new shiny release (i.e. I get my news really late).
Seems to work fine in the internal version 2009.53-2, hence resetting to fixed.
*** Bug 7832 has been marked as a duplicate of this bug. ***
In internal version 2010.04-11: # lsof -n|grep UDP|grep browserd # => verifying on behalf of reporter.
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).