Re: Error in debian package dia

2006-05-26 Thread Roland Stigge
Hi, thanks for your report. Sedlak Anton wrote: > Your dia-common_0.94.0-7sarge3_all.deb > has error in data.tar.gz (bad crc) for very long time - more then month. > > Due that this file is each day mirrored again and again. Unfortunately, I can't do much about this directly. The security team

Re: [Pkg-dia-team] Bug#368202: dia: CVE-2006-2480: format string vulnerability

2006-05-20 Thread Roland Stigge
Hi, thanks for reporting this. Alec Berryman wrote: > CVE-2006-2480: "Format string vulnerability in Dia 0.94 allows > user-complicit attackers to cause a denial of service (crash) and > possibly execute arbitrary code via format string specifiers in a .bmp > filename. NOTE: since the exploit occ

[Fwd: [Pkg-dia-team] Bug#364293: dia-common_0.94.0-7sarge3_all.deb is corrupted/incomplete?]

2006-04-22 Thread Roland Stigge
Hi, indeed: $ tar tfz data.tar.gz [...] ./usr/share/omf/ ./usr/share/omf/dia/ ./usr/share/applications/ ./usr/share/mime-info/ ./usr/share/mime-info/dia.mime ./usr/share/mime-info/dia.keys ./usr/share/pixmaps/ ./usr/share/pixmaps/dia_gnome_icon.png ./usr/share/pixmaps/dia-diagram.png ./usr/share/

Re: [Pkg-dia-team] Bug#330890: dia: Arbitrary code execution when importing a .svg file

2005-09-30 Thread Roland Stigge
tag 330890 security tag 330890 upstream forwarded 330890 http://bugzilla.gnome.org/show_bug.cgi?id=317637 # woody: notfound 330890 0.88.1-3 # sarge: found 330890 0.94.0-7 # testing/unstable: found 330890 0.94.0-14 # experimental found 330890 0.94.0+CVS20050917-2 thanks Hi, thanks for reporting th

xautolock activation behaviour

2004-04-01 Thread Roland Stigge
Hi, a user provided a convenience patch[1] for xautolock[2] preventing xautolock from starting its configured executible (e.g. xlock) when the computer just woke up from sleep. IMHO this would raise a security issue for people assuming xlock to be started after wakeup, so I propose to reject the

xautolock activation behaviour

2004-04-01 Thread Roland Stigge
Hi, a user provided a convenience patch[1] for xautolock[2] preventing xautolock from starting its configured executible (e.g. xlock) when the computer just woke up from sleep. IMHO this would raise a security issue for people assuming xlock to be started after wakeup, so I propose to reject the