Bug#574839: gajim: failed input sanitizing in chat window right click action

2010-04-09 Thread Yann Le Boulanger

Dirk Griesbach  a écrit :


Package: gajim
Version: 0.13.3-1
Severity: normal

Hi,

if opening special formed text in a chat window with right click ->
action->wikipedia, or one of the other stuff, the action is not
performed right if the marked text includes e.g. an odd number of " or
other shell-sensitive characters like ' or #. Depending on the String
gajim throws an error message, does open a single tab in the browser for
every space-separated word or does some other weired stuff.

This is because gajim builds the command to open such a action without
sanitizing the input and executes exec_command() from commom/helpers.py
with shell=True. So the underlaying shell gets all the unescaped
characters.

IMHO the best way would be to use subprocess.Popen together with
shlex.split() as mentioned in [1] and shell=False in exec_command() to
solve this issue. Input sanitizing would therefore become no longer
necessary, phrases with spaces would be no problem, the code would be
clean and mean and the world would become a better, a safer place. ;-)

I tried to quick and dirty patch gajim this way, but sadly it had some
side effects on e.g. playing sound or opening the file manager because
of the current way the commands are build, so I dismissed the changes.
(Mostly because of time constraints which prohibited a deeper
investigation.)

Greetings
Dirk

[1] http://docs.python.org/library/subprocess.html


Hi,

First, thanks for the report and the solution, and sorry for the delay.

I'm trying to play with shlex, but I don't see how it can help. If the  
string contacins a ", it fails. if it contains a space, it fails:

shlex.split('play sound"file')

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python2.6/shlex.py", line 279, in split
return list(lex)
  File "/usr/lib64/python2.6/shlex.py", line 269, in next
token = self.get_token()
  File "/usr/lib64/python2.6/shlex.py", line 96, in get_token
raw = self.read_token()
  File "/usr/lib64/python2.6/shlex.py", line 172, in read_token
raise ValueError, "No closing quotation"
ValueError: No closing quotation


shlex.split("play sound'file")

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python2.6/shlex.py", line 279, in split
return list(lex)
  File "/usr/lib64/python2.6/shlex.py", line 269, in next
token = self.get_token()
  File "/usr/lib64/python2.6/shlex.py", line 96, in get_token
raw = self.read_token()
  File "/usr/lib64/python2.6/shlex.py", line 172, in read_token
raise ValueError, "No closing quotation"
ValueError: No closing quotation


shlex.split('play sound file')

['play', 'sound', 'file']

So yes we should fix the way we handle urls, but we need a way to  
escape those shell-sensitive chars.


Did I missed something?
--
Yann
--
Yann


This message was sent using IMP, the Internet Messaging Program.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#574839: gajim: failed input sanitizing in chat window right click action

2010-04-09 Thread Yann Le Boulanger

Dirk Griesbach  a écrit :


Package: gajim
Version: 0.13.3-1
Severity: normal

Hi,

if opening special formed text in a chat window with right click ->
action->wikipedia, or one of the other stuff, the action is not
performed right if the marked text includes e.g. an odd number of " or
other shell-sensitive characters like ' or #. Depending on the String
gajim throws an error message, does open a single tab in the browser for
every space-separated word or does some other weired stuff.

This is because gajim builds the command to open such a action without
sanitizing the input and executes exec_command() from commom/helpers.py
with shell=True. So the underlaying shell gets all the unescaped
characters.

IMHO the best way would be to use subprocess.Popen together with
shlex.split() as mentioned in [1] and shell=False in exec_command() to
solve this issue. Input sanitizing would therefore become no longer
necessary, phrases with spaces would be no problem, the code would be
clean and mean and the world would become a better, a safer place. ;-)

I tried to quick and dirty patch gajim this way, but sadly it had some
side effects on e.g. playing sound or opening the file manager because
of the current way the commands are build, so I dismissed the changes.
(Mostly because of time constraints which prohibited a deeper
investigation.)

Greetings
Dirk


Moreover, I don't have any problem when I select some text with " or '  
or #, right clich it and select lookup in dictionarry. It goes to the  
url correctly.


--
Yann


This message was sent using IMP, the Internet Messaging Program.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#455014: gajim: get password from netrc

2008-01-12 Thread Yann Le Boulanger

Ian Zimmerman <[EMAIL PROTECTED]> a écrit :


Package: gajim
Version: 0.11.3-1
Severity: wishlist

If a password for an account is not saved, gajim should try to get it
from the user's ~/.netrc file.  Python has netrc parsing module right
there in the standard library, so this is easy.  There is really no
excuse for yet another mode 600 file containing my passwords.



.netrc file is used to store FTP login / passwords. As Gajim is not a  
FTP client, I don't see why we should use it.


--
Yann


This message was sent using IMP, the Internet Messaging Program.





Bug#419010: gajim: option to change status on screensaver

2007-04-17 Thread Yann Le Boulanger
Filippo Giunchedi wrote:
> Package: gajim
> Version: 0.11.1-1
> Severity: wishlist
> 
> Hi,
> it would be nice to have an option to change status whenever
> (x)screensaver kicks-in/returns. (i.e. put yourself away automatically
> when screensaver/xlock is on)
> 
> filippo
> 

the problem is that there is no python bindings for xscreensaver. As a
workarround, you can set the same time for xscreensaver and gajim
autoaway option.

-- 
Yann


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#419122: gajim: ctrl+tab behaves incorrectly with ctrl_tab_go_to_next_composing enabled

2007-04-17 Thread Yann Le Boulanger
Michael Schutte wrote:
> Package: gajim
> Version: 0.11.1-1
> Severity: normal
> Tags: patch
> 
> If the option ctrl_tab_go_to_next_composing (available from the advanced
> configuration editor) is enabled, Gajim ignores Ctrl+Tab when the
> current contact is typing and there are no other tabs with new messages
> or a typing/paused state.  A patch is attached.
> 


with your patch, you'll switch between composing tab and next one only,
not others. I know how to fix this, but I wonder if it's really a bug.
This option means you want to switch between tabs with unread messages
and composing tabs. if you have only one in this case you stays on it.
This sounds logical. What you suggest is to ignore this option if there
is only one composing tab. I'm not sure it's good to do that.

What do you think?

-- 
Yann


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#410047: infinite dialog popups

2007-02-08 Thread Yann Le Boulanger
Gonéri Le Bouder wrote:
> Package: gajim
> Version: 0.10.1-6
> Severity: serious
> 
> Gajim is unusable with a Wildfire server [1]. The issue is fixed in the last 
> upstream release. Is it possible to have a backport for testing before Etch 
> release?
> http://trac.gajim.org/ticket/2028
> 
> Best regards,
> 
> Gonéri

I sent a mail to debian-release for that, I wait the answer

-- 
Yann



Bug#405969: patch to fix this bug

2007-01-09 Thread Yann Le Boulanger
Jan Luebbe wrote:
> tags 405969 + patch
> thanks
> 
> Configure now need the --enable-remote option. Then it also need the dbus 
> development files.
> 
> A patch is attached.
> 
> 
> Jan Lübbe
> 
> 
> 
> 
> diff -u gajim-0.11/debian/rules gajim-0.11/debian/rules
> --- gajim-0.11/debian/rules
> +++ gajim-0.11/debian/rules
> @@ -8,7 +8,7 @@
>  include /usr/share/cdbs/1/class/autotools.mk
>  
>  PYTHONVER = 2.4
> -DEB_CONFIGURE_EXTRA_FLAGS := --prefix=/usr
> +DEB_CONFIGURE_EXTRA_FLAGS := --prefix=/usr --enable-remote
>  DEB_MAKE_BUILD_TARGET:= all PYTHON=python$(PYTHONVER)
>  DEB_MAKE_INSTALL_TARGET = install PYTHON=python$(PYTHONVER) 
> DESTDIR=$(DEB_DESTDIR)
>  
> diff -u gajim-0.11/debian/changelog gajim-0.11/debian/changelog
> --- gajim-0.11/debian/changelog
> +++ gajim-0.11/debian/changelog
> @@ -1,3 +1,10 @@
> +gajim (0.11-2) unstable; urgency=low
> +
> +  * Enable gajim-remote. Closes: #405969
> +  * Add Build-Depends: libdbus-1-dev
> +
> + -- Jan Luebbe <[EMAIL PROTECTED]>  Tue,  9 Jan 2007 19:01:42 +0100
> +
>  gajim (0.11-1) unstable; urgency=low
>  
>* New upstream release. Closes: #403806
> diff -u gajim-0.11/debian/control gajim-0.11/debian/control
> --- gajim-0.11/debian/control
> +++ gajim-0.11/debian/control
> @@ -2,7 +2,7 @@
>  Section: net
>  Priority: optional
>  Maintainer: Yann Le Boulanger <[EMAIL PROTECTED]>
> -Build-Depends: debhelper (>= 5.0.37.2), cdbs (>= 0.4.43), python-support (>= 
> 0.3), python2.4-dev, libgtk2.0-dev, python-gtk2-dev, libgtkspell-dev, 
> gettext, libxss-dev, intltool, imagemagick, python-central (>= 0.5)
> +Build-Depends: debhelper (>= 5.0.37.2), cdbs (>= 0.4.43), python-support (>= 
> 0.3), python2.4-dev, libgtk2.0-dev, python-gtk2-dev, libgtkspell-dev, 
> gettext, libxss-dev, intltool, imagemagick, python-central (>= 0.5), 
> libdbus-1-dev
>  Build-Conflicts: python2.3
>  XS-Python-Version: 2.4
>  Standards-Version: 3.7.2

this patch is not needed fully needed. Only the build-depends is. I
rebuilt a new package and now it's ok. It will be uploaaded in next days