Assigning to me.
Status: NEW → ASSIGNED
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007022704 Minefield/3.0a3pre] (nightly) (W2Ksp4) For the record, I can reproduce the Ctrl+D behaviour with the FF testcase, and the JS exploit which leads me to <http://lcamtuf.coredump.cx/ffbook/success.html>. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070227 SeaMonkey/1.5a] (nightly) (W2Ksp4) I can reproduce the Ctrl+D behaviour with the FF testcase, and not the JS exploit which leads me to <http://lcamtuf.coredump.cx/ffbook/failure.html>. (Maybe related to my profile ?) *(D.o.) Bug 371179, as I guess the SM patch will be based after the FF one.
Status: NEW → ASSIGNED
Component: Bookmarks → Security
Depends on: 371179
OS: Windows XP → All
Hardware: PC → All
Version: 1.8 Branch → Trunk
It would be nice to know what caused the failure for you Serge. With the latest SM trunk, on Linux, it's the same behavior as with FX. Maybe google.com redirects you to google.co.uk? With google.com.br here it fails.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070228 SeaMonkey/1.5a] (nightly) (W2Ksp4) No redirection. I tested again, with a new profile, and it succeeded. ... I guess the |document.cookie| in <http://lcamtuf.coredump.cx/ffbook/attack.js> is "blocked" in my usual profile. [I don't like JS "playing" with cookies.] Sorry for my first report: I didn't try this, because the try+catch masked the exception I get otherwise. It looks like that demonstration does not explicitly account for secure browser/profile ;-/
What's up here? No action for almost two months on something marked as a blocker? We would strictly be entering code freezes for 1.0.9 and 1.1.2 today, and if we want to hold off those releases for this bug, as the blocking+ flags imply, we badly need a solution. Not tomorrow, but yesterday or some weeks ago, actually! So, what's the status on this?
Created attachment 262484 [details] [diff] [review] Fix Add Bookmark As for Groupmarks, they work by adding new tabs for the bookmarks (and optionally deleting the old tabs), so they always run on a safe context.
Assignee: benoit → neil
Attachment #262484 - Flags: review?(cst)
Comment on attachment 262484 [details] [diff] [review] Fix Add Bookmark looks good.
Attachment #262484 - Flags: review?(cst) → review+
[14:08] <BenoitRen> KaiRo: I'm sorry. I'm sorry. I'm sorry. :( [14:08] <BenoitRen> KaiRo: Read the bugmail. What happened is that I looked at the Firefox patch, got confused, investigated it for a while, and then forgot about it. [14:08] <BenoitRen> ("Read the bugmail." is meant as paste tense, I didn't add a comment to the bug.)
Comment on attachment 262484 [details] [diff] [review] Fix Add Bookmark sr=dveditz I'm not sure users will know that a data: url is potentially dangerous even if you show them the dialog
Attachment #262484 - Flags: superreview+
Does this still need to land on the branch(es)?
(In reply to comment #10) > Does this still need to land on the branch(es)? [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:22.214.171.124pre) Gecko/20070504 SeaMonkey/1.0.9] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:126.96.36.199pre) Gecko/20070505 SeaMonkey/1.1.2] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070504 SeaMonkey/1.5a] (nightly) (W2Ksp4) Bug still there. *** Well :-/ Actually, this patch has not been checked in anywhere yet. NB: </xpfe/components/bookmarks/resources/bookmarks.js> was recently moved to </suite/common/bookmarks/bookmarks.js>.
Fix checked in to the trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Should we also be triggering a dialog for "Bookmark this link" and "Bookmark this page" from the context menu?
a=me for SM1.1.8
Flags: blocking-seamonkey1.1.8? → blocking-seamonkey1.1.8+
Fix checked in to the branch.
You need to log in before you can comment on or make changes to this bug.