Security isn't kept. This seems like more of a prevention of accidental
disclosure than real security. (And therefore pointless...?)
As an example, with this patch applied, run the following:
The output in the spy terminal is:
_SURF_GO: not found
_SURF_GO(UTF8_STRING) = 0x61, 0x73, 0x64,
On 4/7/11, Nick suckless-...@njw.me.uk wrote:
Quoth Bjartur Thorlacius:
On 4/7/11, Adam Strzelecki o...@java.pl wrote:
(2) surf-2-delete-_SURF_GO-once-received.patch
This xprop (atom) may be used to tell *surf* to go to specific URL. It
is
safer to remove this atom just after it is set
_SURF_GO just after it's set?
_SURF_GO shouldn't be read, though, it's only used for telling surf
to load a new page. Unless I'm misunderstanding your point.
If it can't be read, then what's the original security breach?
Nick wrote it shouldn't be read, but it can. So right now you can
Adam Strzelecki o...@java.pl wrote:
It is safer to remove this atom just after it is set in case we send some URL
containing passwords or auth tokens
I'm confused as to the state between setting _SURF_GO and removing it.
It smells like a race condition to me, but then again I don't
understand
On Sat, 9 Apr 2011, Bjartur Thorlacius wrote:
Adam Strzelecki wrote:
It is safer to remove this atom just after it is set in case we send
some URL containing passwords or auth tokens
I'm confused as to the state between setting _SURF_GO and removing it.
It smells like a race condition to me,
Below you will find patches for latest HG head of *surf* which I am using in my
project using integrated Linux station.
(1) surf-1-respect-GNOME-URL-handlers.patch
This patch makes *surf* respect URL schema handlers registered in
GNOME/Gtk/GConf, when requested url is using other schemas than
On Thu, Apr 07, 2011 at 02:15:11PM +0200, Adam Strzelecki wrote:
(2) surf-2-delete-_SURF_GO-once-received.patch
This xprop (atom) may be used to tell *surf* to go to specific URL. It is
safer to remove this atom just after it is set in case we send some URL
containing passwords or auth
Anyway _SURF_URI will represents current page URL, so keeping _SURF_GO makes
no sense. In our case it is matter of safety to not expose this one.
Cool, good idea. Can't _SURF_URI have login/password info in
too (I haven't checked)?
AFAIK no, that one is taken out from WebKit
On 4/7/11, Adam Strzelecki o...@java.pl wrote:
Below you will find patches for latest HG head of *surf* which I am using in
my project using integrated Linux station.
(1) surf-1-respect-GNOME-URL-handlers.patch
This patch makes *surf* respect URL schema handlers registered in
Quoth Bjartur Thorlacius:
On 4/7/11, Adam Strzelecki o...@java.pl wrote:
(2) surf-2-delete-_SURF_GO-once-received.patch
This xprop (atom) may be used to tell *surf* to go to specific URL. It is
safer to remove this atom just after it is set in case we send some URL
containing passwords
10 matches
Mail list logo
