Bug#885023: gnome-shell: spams syslog with "e_cal_recur_generate_instances_sync: assertion 'icaltime_compare (interval_start, interval_end) < 0' failed"

[Benny Arana]

 at 23:06:30 +, Simon McVittie wrote:> > > On Mon, 01
Jan 2018 at 20:42:29 +0100, Martin Bergström wrote:> > > > Bug resolved
when upgrading evolution to 3.26.3-1 and/or> > > > evolution-data-
server to 3.26.3-4 when they entered testing.> > > > > > In that case
I'll close this bug after the reassign command has been> > >
processed.> > > > > > The Problem still persists> > # dpkg -l|grep
evolution-data> ii  evolution-data-server 3.26.3-4 amd64 evolution
database backend server> ii  evolution-data-server-common 3.26.3-4 all
architecture independent> files for Evolution Data Server> > Jan 28
15:52:03 aldebaran evolution-calen[372]:>
e_cal_recur_generate_instances_sync: assertion 'icaltime_compare>
(interval_start, interval_end) < 0' failed> Jan 28 15:52:03 aldebaran
evolution-calen[372]:> e_cal_recur_generate_instances_sync: assertion
'icaltime_compare> (interval_start, interval_end) < 0' failed> Jan 28
15:52:03 aldebaran evolution-calen[372]:>
e_cal_recur_generate_instances_sync: assertion 'icaltime_compare>
(interval_start, interval_end) < 0' failed> Jan 28 15:52:03 aldebaran
evolution-calen[372]:> e_cal_recur_generate_instances_sync: assertion
'icaltime_compare> (interval_start, interval_end) < 0' failed> Jan 28
15:52:03 aldebaran evolution-calen[372]:>
e_cal_recur_generate_instances_sync: assertion 'icaltime_compare>
(interval_start, interval_end) < 0' failed> Jan 28 15:52:03 aldebaran
evolution-calen[372]:> e_cal_recur_generate_instances_sync: assertion
'icaltime_compare> (interval_start, interval_end) < 0' failed> Jan 28
15:52:03 aldebaran evolution-calen[372]:>
e_cal_recur_generate_instances_sync: assertion 'icaltime_compare>
(interval_start, interval_end) < 0' failed> Jan 28 15:52:03 aldebaran
evolution-calen[372]:> e_cal_recur_generate_instances_sync: assertion
'icaltime_compare> (interval_start, interval_end) < 0' failed> Jan 28
15:52:03 aldebaran evolution-calen[372]:>
e_cal_recur_generate_instances_sync: assertion 'icaltime_compare>
(interval_start, interval_end) < 0' failed> Jan 28 15:52:03 aldebaran
evolution-calen[372]:> e_cal_recur_generate_instances_sync: assertion
'icaltime_compare> (interval_start, interval_end) < 0' failed> Jan 28
15:52:03 aldebaran evolution-calen[372]:>
e_cal_recur_generate_instances_sync: assertion 'icaltime_compare>
(interval_start, interval_end) < 0' failed> Jan 28 15:52:03 aldebaran
evolution-calen[372]:> e_cal_recur_generate_instances_sync: assertion
'icaltime_compare> (interval_start, interval_end) < 0' failed> Jan 28
15:52:03 aldebaran evolution-calen[372]:>
e_cal_recur_generate_instances_sync: assertion 'icaltime_compare>
(interval_start, interval_end) < 0' failed> Jan 28 15:52:03 aldebaran
evolution-calen[372]:

-- 
Benny

Bug#873523: libinput-bin: After resuming touchpad is enabled although in settings is disabled

[Benny Arana]

Package: libinput-bin
Version: 1.8.0-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
After switching to wayland (since last release in testing), the 
suspend-resume cycle re-enables the touchpad.
I disabled the touchpad in 'mouse & touchpad' settings but after 
resuming from suspending the touchpad is enabled although in settings it 
remains disabled.

Just to test if all settings are being ignored or just the touchpad 
enable/disable config, I changed the default values to see if the config was 
going back to them but this is not the case. Just the touchpad enable/disable 
config is being ignored. 


Other related packages:
ii gnome-shell 3.22.3-3
ii xwayland  2:1.19.3-2
ii libinput10:amd64 1.8.0-1




-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libinput-bin depends on:
ii  libc6  2.24-14
ii  libudev1   234-2.3
ii  libwacom2  0.24-1

libinput-bin recommends no packages.

libinput-bin suggests no packages.

-- debconf-show failed

Bug#823061: Benny Ray-✉-Message-on-hold-

[Benny Ownby]

Dame girl houses is this can not see you on here
On Apr 30, 2016 12:32 PM, "Angel"  wrote:
>
> _Just_saw_something_really_hot_that_made_me_wonder...
>
> _What_would_you_like_me_to_wear_tonight?_
>
> _What's_the_hottest_thing_I_can_do_for_you_when_I_see_you?_
>
> We'll_even_play_some_games_honey_
>
>
_you_just_guess_what_color_my_panties_are,_then_I'll_give_you_whatever_you_want_;)

>
> register_and_add_my_nickname_:angelicax3
> u_ns__ub
> optout
>

Bug#759771: Allow to align sizes/size differences used in format strings

[Benny Baumann]

Package: aptitude
Version: 0.6.11-1
Severity: minor

Let's assume I was using something along the lines of

%c%a%M%S %?i %p# %Z %10D %10I %4r %20v %20V %t

for the display format of package lists. Now this looks much better than the
default but due to the lack of aligning numbers of the included sizes it
always requires  second look to see the actual sizes. It would be better,
if all sizes could be right aligned with the empty SI prefix treated as
a space, thus instead of

1,234 B
12.9 kB
789 kB

I'd get something like

1,234.5 kB
   12.9 kB
  789.7 kB

Regards,
BenBE.

-- Package-specific info:
Terminal: screen
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Jun  9 2014 20:46:57
Compiler: g++ 4.8.3
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.11
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140712
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x727fc000)
libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7fc8bd44c000)
libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7fc8bd216000)
libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fc8bcfeb000)
libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fc8bcde6000)
libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fc8bcadf000)
libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fc8bc81d000)
libboost_iostreams.so.1.55.0 = 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7fc8bc605000)
libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7fc8bc1fa000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fc8bbfdc000)
libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fc8bbcd1000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fc8bb9d)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fc8bb7b9000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fc8bb41)
libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fc8bb20d000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc8bb008000)
libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fc8badf)
libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fc8babe)
liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fc8ba9bc000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fc8ba7b4000)
libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fc8ba5ae000)
/lib64/ld-linux-x86-64.so.2 (0x7fc8bdde2000)

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.6
ii  libboost-iostreams1.55.0  1.55.0+dfsg-2
ii  libc6 2.19-9
ii  libcwidget3   0.5.17-1
ii  libgcc1   1:4.9.1-4
ii  libncursesw5  5.9+20140712-2
ii  libsigc++-2.0-0c2a2.2.11-4
ii  libsqlite3-0  3.8.5-2
ii  libstdc++64.9.1-4
ii  libtinfo5 5.9+20140712-2
ii  libxapian22   1.2.18-1

Versions of packages aptitude recommends:
pn  aptitude-doc-en | aptitude-doc  none
ii  libparse-debianchangelog-perl   1.2.0-1
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  none
ii  debtags   1.12.1
ii  tasksel   3.20

-- debconf-show failed


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

Bug#759772: Allow format strings to require fixed width for optional arguments

[Benny Baumann]

Package: aptitude
Version: 0.6.11-1
Severity: minor

Let's assume the following format string for package lists:

%c%a%M%S %?i %p# %Z %10D %10I %4r %20v %20V %t

Now configure some packages with explicit preferences along the lines of:

$ cat /etc/apt/preferences
Package: linux-image-* linux-headers-* linux-firmware-* firmware-* 
*-firmware
Pin: release a=experimental
Pin-Priority: 1000

Package: linux-image-* linux-headers-* linux-firmware-* firmware-* 
*-firmware
Pin: release a=unstable
Pin-Priority: 950

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=stable
Pin-Priority: 800

Package: *
Pin: release a=experimental
Pin-Priority: 750

Package: *
Pin: release a=unstable
Pin-Priority: 700

When browsing the various categories you will see various most packages without
any priority, as desired. But when looking into a section with kernel images,
development headers or firmware packages in them, mixed with other, you will
see stairs and other effects with misalignment of the columns.

It would be cool if you could ask Aptitude to skip the value as is now, but
still reserve a certain amount of space for it anyway.

Regards,
BenBE.

-- Package-specific info:
Terminal: screen
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Jun  9 2014 20:46:57
Compiler: g++ 4.8.3
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.11
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140712
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x7fffa67fc000)
libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7f1358d05000)
libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f1358acf000)
libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f13588a4000)
libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f135869f000)
libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f1358398000)
libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f13580d6000)
libboost_iostreams.so.1.55.0 = 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f1357ebe000)
libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f1357ab3000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f1357895000)
libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f135758a000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f1357289000)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f1357072000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f1356cc9000)
libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f1356ac6000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f13568c1000)
libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f13566a9000)
libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f1356499000)
liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f1356275000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f135606d000)
libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f1355e67000)
/lib64/ld-linux-x86-64.so.2 (0x7f135969b000)

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.6
ii  libboost-iostreams1.55.0  1.55.0+dfsg-2
ii  libc6 2.19-9
ii  libcwidget3   0.5.17-1
ii  libgcc1   1:4.9.1-4
ii  libncursesw5  5.9+20140712-2
ii  libsigc++-2.0-0c2a2.2.11-4
ii  libsqlite3-0  3.8.5-2
ii  libstdc++64.9.1-4
ii  libtinfo5 5.9+20140712-2
ii  libxapian22   1.2.18-1

Versions of packages aptitude recommends:
pn  aptitude-doc-en | aptitude-doc  none
ii  libparse-debianchangelog-perl   1.2.0-1
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  none
ii  debtags   1.12.1
ii  tasksel   3.20

-- debconf-show failed


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

Bug#759769: aptitude: Installed Size diff reported wrong for packages larger 2GiB if installed

[Benny Baumann]

Package: aptitude
Version: 0.6.11-1
Severity: minor
Tags: lfs

When installing a package that will require more than two GiB on disk
if installed this change of required disk space is reported incorrectly.

To reproduce have a look at the linux-image-*-dbg packages that require
more than 2GiB on amd64 after installation. When installing such a package
aptitude will report something like pi linux-image-*-dbg   -1,900M ...
while the correct display would report +2300M instead.

Likewise uninstalling such a package will report something along the lines
of id linux-image-*-dbg   +1,900M where -2,300M would be correct.

Kind regards,
BenBE.

-- Package-specific info:
Terminal: screen
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Jun  9 2014 20:46:57
Compiler: g++ 4.8.3
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.11
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140712
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x7fff0e3f3000)
libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7f125795a000)
libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f1257724000)
libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f12574f9000)
libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f12572f4000)
libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f1256fed000)
libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f1256d2b000)
libboost_iostreams.so.1.55.0 = 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f1256b13000)
libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f1256708000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f12564ea000)
libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f12561df000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f1255ede000)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f1255cc7000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f125591e000)
libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f125571b000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1255516000)
libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f12552fe000)
libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f12550ee000)
liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f1254eca000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f1254cc2000)
libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f1254abc000)
/lib64/ld-linux-x86-64.so.2 (0x7f12582f)

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.6
ii  libboost-iostreams1.55.0  1.55.0+dfsg-2
ii  libc6 2.19-9
ii  libcwidget3   0.5.17-1
ii  libgcc1   1:4.9.1-4
ii  libncursesw5  5.9+20140712-2
ii  libsigc++-2.0-0c2a2.2.11-4
ii  libsqlite3-0  3.8.5-2
ii  libstdc++64.9.1-4
ii  libtinfo5 5.9+20140712-2
ii  libxapian22   1.2.18-1

Versions of packages aptitude recommends:
pn  aptitude-doc-en | aptitude-doc  none
ii  libparse-debianchangelog-perl   1.2.0-1
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  none
ii  debtags   1.12.1
ii  tasksel   3.20

-- debconf-show failed


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

Bug#757858: ejabberd: Upgrade from 2.1.x to 14.05 causes inconsistent conf of Mnesia db in /etc/default/ejabberd

[Benny Baumann]

Package: ejabberd
Version: 14.05-1~experimental2
Severity: grave

Hi folks,

when upgrading from 2.1.x to 14.05 the configuration of the Mnesia database
is not properly updated. While older versions used ejabberd@$(hostname) for
the EJABBERD_NODE it is ejabberd@localhost for the most recent one. This
change is not reflected during the upgrade and causes the upgraded server to
fail to start (with meaningless erlang error messages worth submitting to
NIST as a new form of random bitstring generation - can't be worse than
DualEC DRBG).

Updating /etc/default/ejabberd to use the old value of ejabberd@$(hostname)
for the EJABBERD_NODE setting solves the issue.

Kind regards,
BenBE.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ejabberd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.53
ii  erlang-asn11:17.1-dfsg-4
ii  erlang-base1:17.1-dfsg-4
ii  erlang-crypto  1:17.1-dfsg-4
ii  erlang-dev 1:17.1-dfsg-4
ii  erlang-eunit   1:17.1-dfsg-4
ii  erlang-inets   1:17.1-dfsg-4
ii  erlang-jiffy   0.8.5+dfsg-1
ii  erlang-lager   2.0.3-1
ii  erlang-mnesia  1:17.1-dfsg-4
ii  erlang-p1-cache-tab0.2014.04.30-1
ii  erlang-p1-iconv0.2014.04.30-1
ii  erlang-p1-mysql0.2014.03.10-2
ii  erlang-p1-pam  0.2014.05.05-1
ii  erlang-p1-pgsql0.2014.04.30-1
ii  erlang-p1-sip  0.2014.06.12-1
ii  erlang-p1-stringprep   0.2013.12.09-3
ii  erlang-p1-stun 0.2014.05.08-1
ii  erlang-p1-tls  0.2014.05.06-1
ii  erlang-p1-xml  0.2014.07.02-1
ii  erlang-p1-yaml 0.2014.06.11-1
ii  erlang-p1-zlib 0.2014.05.06-1
ii  erlang-parsetools  1:17.1-dfsg-4
ii  erlang-ssl 1:17.1-dfsg-4
ii  erlang-xmlrpc  0.2014.03.17-2
ii  openssl1.0.1h-1benbe1
ii  ucf3.0030

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
ii  imagemagick  8:6.7.7.10+dfsg-4
ii  libunix-syslog-perl  1.1-2+b3

-- Configuration Files:
/etc/default/ejabberd changed [not included]

-- debconf information excluded


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

Bug#751737: Package overwrites files from libssh2-php

[Benny Baumann]

Package: php5-ssh2
Version: 0.12-2
Severity: serious

When upgrading from libssh2-php the package does not conflict on the package and
thus dpkg tries to install libssh2-php and php5-ssh2 at the same time.

Please add a proper stanza to the dependencies to indicate that php5-ssh2
superseeds libssh2-php and upgrade works more smoothly.

Kind regards,
Benny Baumann

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php5-ssh2 depends on:
ii  libc6  2.19-1
ii  libssh2-1  1.4.3-3
ii  php-pear   5.6.0~beta4+dfsg-3
ii  php5-common [phpapi-20131226]  5.6.0~beta4+dfsg-3

php5-ssh2 recommends no packages.

php5-ssh2 suggests no packages.

-- no debconf information


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

Bug#748495: closed by Daniel Baumann daniel.baum...@progress-technologies.net (reply to daniel.baum...@progress-technologies.net) (Re: Missing required dependencies)

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Daniel,

Am 21.05.2014 12:55, schrieb Daniel Baumann:
 On 05/19/2014 09:40 AM, Benny Baumann wrote:
 Even then you should make sure you are recommending the correct
 version (python3 = 3.3) which currently is not the case.

 there is no such thing as versioned recommends.
Then it should be hinted in other places that this is necessary.
 Furthermore when running basic commands (and starting a container
 really IS basic) doesn't work then it makes this package unuseable
 for many people - despite this only appearing in one sub-command.

 you're confusing the convenience wrapper /usr/bin/lxc from lxc-stuff
 with /usr/bin/lxc-* from lxc.
Actually: No, I'm not. This bug was filed against lxc-stuff which IS
broken as you so so yourself just below.
 while it's true that the wrapper /usr/bin/lxc in lxc-stuff is useless
 without pythong (since it calls lxc-ls, which is python), the wrapper
 is only one part within lxc-stuff and thus doesn't make lxc-stuff
 unusuable.

 the 'basic commands' that you're refering to are all accessible/usable
 by calling /usr/bin/lxc-* from lxc itself.
Which makes lxc-stuff kinda useless - and thus the bug report on
lxc-stuff requiring python3 (= 3.3).

Kind regards,
Benny Baumann.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJTfPOXAAoJEPHTXLno4S6txLMQAIa6WlpGHYHJh6sHDBLRFasW
Jq0PMuEMsVTpuvn/lcTuptL7xvFlYV10fMEg2670e9V6VrPYbjmg8G0p9SFziU4C
Z1fGZbXe3BHW66Cor67nf/UKjqI8u58hFuJznZn0cmvoCYNj6K3BLRrGO3zZjfRv
vWclzUCUWFjBXkelF2IGLD3b6MtPYzKm5ryTjOT4B4zlYCZ1/xlKkeOn6/dIljuB
r0VhmyMtqiBi0zZ14l/LxOh6V88yYfgD0bJC02pjZdfDo0h2JYXy4RpCE24qr63w
HJOZLtW5p9abJ6pjbGKcYe9DA8s7gFOLVVBUFsyyl0pCXSNZurpylBfwGMDWle9K
zGO+aP+4HJl/LpAS41DLv0ykOHyD2dFhLJR2CT/uG2iOBsbluwyohyGy7n5I/2eb
89z41m2h/vVWCAvowEVCH8eqtOoY3tP8FVXV84e/UynXffD5iACPAMnlKRp3h1Rs
+wshbquH80qk3ubiQpfBq4ym09Jjn/tzx87cOPmSPWK1LpqtgyOAhi01zWgUM2jk
dVQVA253Gb4lz5BPddsI2v0pkCIXQ6iVbe8oulFDIbo7+FuZ66HlcWVfwyhvg8We
3ulpgk70ad9yV0EwlLZvRLkqToP3DeTUzINHFghkx/aVVmg2ur31gpOJOBGlx9QY
JLxE51Lye0sDz+vHKi1P
=/2zt
-END PGP SIGNATURE-


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

Bug#748495: closed by Daniel Baumann daniel.baum...@progress-technologies.net (reply to daniel.baum...@progress-technologies.net) (Re: Missing required dependencies)

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Even then you should make sure you are recommending the correct version
(python3 = 3.3) which currently is not the case.

Furthermore when running basic commands (and starting a container really
IS basic) doesn't work then it makes this package unuseable for many
people - despite this only appearing in one sub-command.

Kind regards,
Benny Baumann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJTebVpAAoJEPHTXLno4S6t4soP/RyyKSxgAWnt0FrDsn7wPl2T
FdtoDUi1x9lVVAxgH51a8sjE5x5P+oiHLU2m82Hvs+JMpuzuJZ0uWkLOQmBbflGH
2vdOiXFCqX97qlplgyOZfl9MtBd//pcxFpeo+4QNsJuIcvn49YqqaJKxTwyWeVtd
zDsbirG9/boT0WsX5QG1SNqkRkZAhhh+Sx4kVIuBDciRmA98luD82GnZafqBk9eT
WgJJ1jpLGPwyxNP4+2mkTX6/yv453fpbMDUiOfB7OkZDYdSV6vPTFa7KLH6bmTHQ
0zq3VddsskgmKsAV+8cR4LbD+DTKIzH2CaNa8gXjQVuYkh04JOFhmb1e9bmufTp6
4uXBvK5CDbqu7yyRNKs7wRDSYL3LbyZnVJ04z3I2alWT6KtVSPH3j9U8sY/csP5h
O1dD7ppGjvKBfMQAMRUfxD3dHM4kxrd5PTIQYuW3KWSJCIKIn/yjl/J0/MtFKgZB
uh8tA6qyVt2Y6H+PLDUQe1P6f5VZ6L2bgcYtCLAsgVGB3BBZyDyB3uA+kqLubKTV
qX56Z1jBNK9EpqCIpROEEbrH6WPOzZKoRvUpzlUuIPENsTP2jgVmc+tShZEMuJ7k
3mtiJZemOPcOMivsr/qsinYn/sLctyxjF0hGj1TpaTJU3Kzc5AfpViBkoMvHtqwi
8L8bYg9yIg07QEatQRuT
=wEjI
-END PGP SIGNATURE-


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

Bug#745418: Bug#748495: Acknowledgement (Missing required dependencies)

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

The issue seems to go away when python3.3 or newer is installed.

Thus having python3 (= 3.3) as a dependency (and not only
recommendation) should fix those issues.

Kind regards,
Benny Baumann.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJTeJEqAAoJEPHTXLno4S6th7sP/jxYJg/tv5YAfLSK1XKhOd1E
p468ozka+xl1Py5QXkxwxnF8O8WXoiWd919XYThQNqvUbsKC7YD8ESKVxneP8gKe
NeGYK2z1bzW5Ln2QQqwJHDyejVh2zPd/wOnFyPiH7MUqJwoGAJsG/Y9BJksa07Gd
4EZNUWm+DUG86gALVSCbQONxH/Szgzo2l1bInAz0ESbo65wV/k0N3f2KVxjSCVY2
74DWwAb+yUQq2QOyJWgvMFbIKIUM4ym20rU1IjnVxwaycM4hzWlqsSSZgGrVr22H
lvsYVbIF6PHtW3CkzAUIqJKtMDlUuO4tdrmBnddd8ba5xNVDZ8cgvtxKVWqq5w6k
qEYAyWocrs6FaseN5iAQXOTpqzy2p6Czh6WzlYmpgxbJGOM3Pk8pYUSZxTCkD6qr
0NDKUpGuPJ1RoIO81NiWLVggZsWLnJBF5+hKEfvqdHRQBSPaI81pTA4qFzJL/srE
LaR9i5bEmoToK5Zch5R9+ETocSLcsL1G05Z2yTNh7AR3NwhG2kAc/MXqEk0v9mTC
AGoaz3uw0IG6T8MY/7uS8AHfUbIUvgW2I+vAj0vU6WHioCQWuKgGjE/099A5T5dV
abzXDzXS3Ab5jVae7PNym+H7yn4VRklLF5/ZtOIhxPCRarY0JFx/v5AhGKzuOapG
XsMm+B6UNDBup2M61vMS
=g4Mo
-END PGP SIGNATURE-


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

Bug#748495: Missing required dependencies

[Benny Baumann]

Package: lxc-stuff
Version: 1.0.3-1
Severity: serious

Hi,

When recommended packages are not installed by default the package fails to find
at least the following dependencies:

- python3

If those are not installed lxc-stuff fails to execute even simple things like

lxc start container -d

Even after pulling those additional dependencies I run into [1].

Kind regards,
Benny Baumann

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745418

-- System Information:
Debian Release: wheezy/stable
  APT prefers stable
  APT policy: (900, 'stable'), (800, 'testing'), (750, 'unstable'), (700, 
'experimental'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lxc-stuff depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  lxc1.0.3-1

Versions of packages lxc-stuff recommends:
ii  debootstrap  1.0.60
pn  irkernone

Versions of packages lxc-stuff suggests:
ii  rsync   3.0.9-4

-- debconf information excluded


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

Bug#747667: Provide builds for AMD64 and i386 plattforms

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Ryan,

Am 16.05.2014 08:51, schrieb Ryan Kavanagh:
 tags 747667 + moreinfo
 fixed 747667 opensmtpd/5.3.3p1-1
 thanks

 Hi Benny,

 On Sat, May 10, 2014 at 11:10:05PM +0200, Benny Baumann wrote:
 Successfully build this package locally and would like to see an
 official upload in the repositories.
 Could you please clarify? opensmtpd has been available in Debian
 unstable and testing since September. The buildd status page for
 opensmtpd[0] shows that packages have successfully built for amd64 and
 i386.
I only had a look at [1] when looking for the binary package, which only
lists an armhf version of it - even when having amd64 or i386 in the URL.
 Best,
 Ryan
Thx,
BenBE.


 [0] https://buildd.debian.org/status/package.php?p=opensmtpd
[1] https://packages.debian.org/jessie/amd64/opensmtpd
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJTdbqzAAoJEPHTXLno4S6tvEYQAMmiszwEqwWkfkN9wgE1hBsE
abAJGoZaNU/uxmQiQb2DkANRa20BD22Bhl/Pw/yKMWt08pTqu7OZBZl69Vq0jnMd
ltQ38zdG4qZEoKe730cevtgT/xTxODfEnv6d22/iaKg3KKBc1fHy7Hj5iWls5uTL
s7yQeSYQFfFylZm4tmoEVXDmrNwKTRzKHeOWP01qp6CHR/NGdjZoHxlNUi6hWQDa
5m+vOdZUAfyny0dQaqNN1tatbg0v+auXYgh2b/HYPdIL5FZSLvNR4bX9B7SKLuPR
3SCd7QvxP4W5B/oFJiuypEaANCrEJ4O/IUvkE7HK9bOWqN/SD4sDKmuH+qxGgQPA
ptQ9dMrGaJ5lY6mKl1m23BtCkcbvO5wB7LJBhuG236ctaVSh8oNipbNlJG2rfuwK
61S1aDCljo/uEEi2rs+E/hcC5fBCKFUKLGJcYMKCLgEapPVJWtZ0NKLEzH7ncfZv
MaSeM4pkEl/gRRI9NKhW6Rd3JUyiZ0dH+QsMt2hCB9qCKNjb9hm5e3eOYJmpmNEv
Nl3AVImmVpDCsqFaQdYm+q7imhIrsLr2C7KxiB5IJLrO0VoAWcB6GvGpBvu2ykWi
gryPBbM48eunIEPX8HsnJ5jHFtGVj5ku2Rl0icm081j7E/8mIKkfeYzqwGd9e9iJ
zFYhYWzonPhUmdTxQ+VT
=QsGH
-END PGP SIGNATURE-


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

Bug#747453: Arbitrary key size limitations causing hard-to-diagnose problems when establishing a connection

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Florian,

Am 10.05.2014 22:42, schrieb Florian Weimer:
 * Benny Baumann:

 As stated in the initial report you MUST never place arbitrary
 limits on the size of cryptographic keys which is this bug is doing
 in the first place.

 Actually, you have to, otherwise you end up with a rather trivial
 pre-authentication denial of service vulnerability.
But then you should decide this limit on more sophisticated and
situation based criteria than just Oh, I think this key is too long,
which would make this much less arbitrary than saying I don't like long
keys, thus I will barf out on them.

Example: Given a powerful high-security webserver versus an embedded
system you could just nicely argue that 4kBit RSA makes the login on
that 16MHz 8-bit microcontroller with barely 16KB RAM far too slow and
thus at most 2kBit keys should be accepted. On the other hand limiting
your webserver with some powerful highspeed 64bit multicore power-CPU
you'd be artificially limiting your security if you used only 2kBit
keys. In fact you would want to have a limit more at about 16kBit RSA or
alike to make full use of the security offered by your (yet artificial)
TLS1.3-ECDHE(p521r)-RSA-AES256-GCM-SHA512 cipher.

Or in short: The current hard-limit suites NEITHER the embedded system
NOR your powerful high-security webserver. Current patch for the RSA key
problem is a compromise in that it currently only increases the limit
from 516 Bytes (4k RSA) to 8200 Bytes (~64k RSA) to cure the imminent
symptoms we are facing which gives plenty of room for further
improvements (e.g. providing an API to set it or providing an API for a
callback so the application CAN decide if it wants).
 It's less of an
 issue for the plain RSA cipher suites, but for many of the more
 sophisticated ones, it is.
Any links for elaboration on that point? (Though I doubt they provide
ANY good reason for arbitrarily breaking crypto like this.)

Kind regards,
Benny Baumann.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJTb2lyAAoJEPHTXLno4S6tizkP/1wyiZhWEemHnrE1n5i4e8j2
XSrcTnhOKUlyIpaq3+EaLG8FK7mDyJWUv+2UiUctfungX+CuiyDXBc8CE0s9uUzO
QsEPKvHe5f7bPmMCgA4+LIJuPPf6Gmwi9LknYVznq5JTnFEQ86IrGaVeATcyoYKm
QWmZba/zx/0OFIpxbyTVPdOjR3zIdWNgm92JIBhme5JyUoy6UST/oUDBOHzKTIrl
fesoKm6NcvxgiOlDX2aAyZ0Vz69F7MwuBIUNnwH8cGJoj7F0nnJesMV+2dhtypT5
W0zxdhRUh2ZkM02+N4Typ9bnRryPaGHxO1jw2jIeuKK4zIRRTCC1lTrdEjDlzwNV
hYmGkJms2J3rJ7cefFhWusaGlyrwdX+HHAmTIvNHTtpVwr2ah6dVNeldzNSLjS+T
S756O6pL6JoocexrugjHlRM1y/LLu4wmCCJKwPILAygWqrmlFFo5V5ocLZqULoKA
Qhgb9hFHa0ZViFRjSPh+cT0YUnATgQzP6ZOWLISpRsxoV8La6/2B/lDxkjNVhQ7+
yMydmkcu+Aln4AemXIyH65vRef+BJeEGXamQP3SB9NcecyPh5dOhi56vvhWziU+h
H7x6fyEzKiiCQOdIGUbQQFqBcIN2egATl7XXxfMfu2Vw7Ayvs/MVNb54pLUuw4Lp
wE10pGNB4/Je8Haf5CrL
=vjOW
-END PGP SIGNATURE-


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

Bug#747666: Redefined macro messages scrolling by when compiling exhaust console backlog

[Benny Baumann]

Package: opensmtpd
Severity: serious
Tags: upstream patch
Justification: fails to build from source

When building this package a shitload of repeated warnings about a redefined
macro scroll by exhausting my precious console backlog unnecessarily.

The attached patch fixes this issue.

Kind regards,
Benny Baumann

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: Removes a shitload of stupid warnings due to redefining some macro unnecessarily
Author: Benny Baumann be...@geshi.org

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD

--- opensmtpd-5.4.1p1.orig/openbsd-compat/defines.h
+++ opensmtpd-5.4.1p1/openbsd-compat/defines.h
@@ -373,13 +373,13 @@ struct winsize {
 #endif
 
 /* user may have set a different path */
-#if defined(_PATH_MAILDIR)  defined(MAIL_DIRECTORY)
+#if !defined(_PATH_MAILDIR)  defined(MAILDIR)
 # define _PATH_MAILDIR MAILDIR
-#endif /* defined(_PATH_MAILDIR)  defined(MAIL_DIRECTORY) */
+#endif /* !defined(_PATH_MAILDIR)  defined(MAIL_DIRECTORY) */
 
-#ifdef MAIL_DIRECTORY
+#if !defined(_PATH_MAILDIR)  defined(MAIL_DIRECTORY)
 # define _PATH_MAILDIR MAIL_DIRECTORY
-#endif
+#endif /* !defined(_PATH_MAILDIR)  defined(MAIL_DIRECTORY) */
 
 #ifdef MAILDIR
 # undef MAILDIR

Bug#747667: Provide builds for AMD64 and i386 plattforms

[Benny Baumann]

Package: opensmtpd
Severity: wishlist

Successfully build this package locally and would like to see an official upload
in the repositories.

Kind regards,
Benny Baumann.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#747673: Horrid default cipher settings without option to adjust them to sane values

[Benny Baumann]

Package: ejabberd
Version: 2.1.11-1
Severity: grave
Tags: security

When setting up ejabberd with a default configuration it allows only connections
with a weak SSL configuration - if this is even configured:

1.  By default ejabberd allows SSLv3 which is broken in various ways
and thus should no longer be used.

2.  By default ejabberd uses weak cipher suites that make use of weak primitives
like DES, RC2, RC4, MD5, export ciphers.

3.  By default ejabberd does not provide ANY ciphers that make use of forward
secrecy and thus jeopardizes the communication of users that crossed this
server in case of a private key compromise.

4.  Most importantly ejabberd does not provide any way to adjust the accepted
security parameters (acceptable protocol versions, cipher string, cipher
ordering, used ECC curves, used ECDHE/DHE parameters)

Please make sure that a default configuration can be configured to use strong
cryptography, using non-broken primitives and does so by default.

Kind regards,
Benny Baumann

P.S.: By courtesy of #747453.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ejabberd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.53
ii  erlang-asn11:17.0-dfsg-1
ii  erlang-base [erlang-abi-15.b]  1:17.0-dfsg-1
ii  erlang-crypto  1:17.0-dfsg-1
ii  erlang-inets   1:17.0-dfsg-1
ii  erlang-mnesia  1:17.0-dfsg-1
ii  erlang-odbc1:17.0-dfsg-1
ii  erlang-public-key  1:17.0-dfsg-1
ii  erlang-ssl 1:17.0-dfsg-1
ii  erlang-syntax-tools1:17.0-dfsg-1
ii  libc6  2.18-5
ii  libexpat1  2.1.0-4
ii  libpam0g   1.1.8-3
ii  libssl1.0.01.0.1g-3
ii  openssl1.0.1g-3
ii  ucf3.0028
ii  zlib1g 1:1.2.8.dfsg-1

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
ii  imagemagick  8:6.7.7.10+dfsg-1
ii  libunix-syslog-perl  1.1-2+b3

-- debconf information excluded


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

Bug#747675: Missing fallback handling when session layer connections (e.g. SSL) fail

[Benny Baumann]

Package: ejabberd
Version: 2.1.11-1
Severity: important
Tags: upstream

When a server-to-server (s2s) SSL connection cannot be established there is no
fallback or backoff configurable that would try to use e.g. other parameters
like different set of offered cipher suites or even would try without
encryption - if encryption has been configured to be optional for (outgoing)
s2s connections.

Furthermore ejabberd fails to report the cause of the s2s connection failure in
a reasonable way thus only an unspecific remote-host-not-found is returned to
the user even though the plaintext part of a STARTTLS session could successfully
be performed.

Thus ejabberd should ensure that proper fallback is performed when encrypted
connections to yet unknown hosts fail and ensure reasonable diagnostics are
returned in the logfile to debug such issues.

Kind regards,
Benny Baumann

P.S.: By courtesy of #747453

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ejabberd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.53
ii  erlang-asn11:17.0-dfsg-1
ii  erlang-base [erlang-abi-15.b]  1:17.0-dfsg-1
ii  erlang-crypto  1:17.0-dfsg-1
ii  erlang-inets   1:17.0-dfsg-1
ii  erlang-mnesia  1:17.0-dfsg-1
ii  erlang-odbc1:17.0-dfsg-1
ii  erlang-public-key  1:17.0-dfsg-1
ii  erlang-ssl 1:17.0-dfsg-1
ii  erlang-syntax-tools1:17.0-dfsg-1
ii  libc6  2.18-5
ii  libexpat1  2.1.0-4
ii  libpam0g   1.1.8-3
ii  libssl1.0.01.0.1g-3
ii  openssl1.0.1g-3
ii  ucf3.0028
ii  zlib1g 1:1.2.8.dfsg-1

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
ii  imagemagick  8:6.7.7.10+dfsg-1
ii  libunix-syslog-perl  1.1-2+b3

-- debconf information excluded


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

Bug#747469: openssl s_client -starttls hangs on XMPP s2s connections

[Benny Baumann]

Source: openssl
Severity: normal
Tags: upstream

When trying to debug connection issues of a XMPP server it is sometimes required
to debug the plain XMPP data stream between the two servers. In order to do this
a handy tool usually is openssl s_client. Unfortunately when debugging XMPP
connections between two servers which uses STARTTLS inside XMPP OpenSSL simply
hangs.

How to reproduce:
1. Choose an arbitrary XMPP server, e.g. xmpp-server.example.org on port 5269
2. Try to connect to this server with openssl s_client:

openssl s_client -connect xmpp-server.example.org:5269 -starttls xmpp

Expected behaviour:
Either one of the following would be okay:
1.  A connection to the destination server is established
2.  An error message indicating the server's refusal to speak the
XMPP c2s protocol flavour on the s2s port.

Actual behaviour:
Connection hangs without any indication of why it doesn't continue.

Kind regards,
Benny Baumann

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


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

Bug#747470: openssl s_client refuses to be silent

[Benny Baumann]

Source: openssl
Severity: normal
Tags: upstream

Under some circumstances you want openssl s_client to be absolutely silent
about what its doing. Unfortunately the -quiet option available does not
suppress the verification messages of the certificate when the connection
is established.

Howto reproduce:
openssl s_client -connect host.example.com:443 -quiet

Expected behaviour:
netcat with crypto and no output on stderr

Actual behaviour:
netcat with crypto and certificate verification messages spammed into stderr

Kind regards,
Benny Baumann

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


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

Bug#747471: libnss: Arbitrary key size limitation for client certificate authenticaton causing out-of-memory error

[Benny Baumann]

Source: iceweasel
Severity: critical
Tags: security upstream

When using client certificate authentication with client certificates with keys
of 4097 bit RSA or larger you always get a diagnostic from the SSL layer saying
that no memory was available which is funny because usinga key of the same size
for the SSL server works just fine. Also using a 4095 bit RSA client certificate
works just fine as well.

This breaks security in system where such keys are used and thus should be
considered serious misbehaviour as cryptographic systems MUST NOT include an
arbitrary limits on the key size of used cryptographic parameters.

Please either remove this restriction completely or raise this to a much more
sane value that is not limitting casually-paranoid configurations which use
keys like 8192 Bit RSA for client authentication.

A suggested increase could be 65536 Bit RSA, but better remove this limitation
completely as it causes no real benefit.

Furthermore RSA 8192 and up to RSA 16384 has to be considered as it corresponds
roughly to 192-256 bit symmetric key sizes and thus properly configured systems
enforcing 256 bit symmetric cryptography will also enforce asymmetric keys
larger than 4096 bit for RSA or similarly for DSA and ECDSA.

Kind regards,
Benny Baumann

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#747472: s_client: Failure to connect to IPv6-only hosts

[Benny Baumann]

Source: openssl
Severity: important
Tags: upstream ipv6

When trying to establish a secure connection using an IPv6-only host using

openssl s_client -connect ipv6-only.example.net:443

the only message you get is that OpenSSL s_client was unable to resolve that
hostname accompanied by a message that there was no error in the connection:

gethostbyname failure
connect:errno=0

This renders openssl s_client useless on IPv6-only networks. On hostnames
offering both IPv4 and IPv6 addresses OpenSSL silently ignores the IPv6 address
and connects to the IPv4 address in violation of RFCs stating the IPv6 should
be preferred.

IPv6 is around for a good 20 years now and yet not even the basics work
despite quite a few people sending patches on this matter:

https://bugs.debian.org/589520

https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=openssl_s_client_s_server_with_ipv6.diff;att=1;bug=589520

Would be nice if our tools could be upgraded to something more recent than
the stone-aged versions we are distributing ATM.

Kind regards,
Benny Baumann

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


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

Bug#747453: Arbitrary key size limitations causing hard-to-diagnose problems when establishing a connection

[Benny Baumann]

Hi Kurt,

Am 09.05.2014 08:42, schrieb Kurt Roeckx:
 On Fri, May 09, 2014 at 03:32:25AM +0200, Wilfried Klaebe wrote:
 Kurt Roeckx wrote:
 I don't see how the severity of this is critical.
 The severity level critical is defined as: makes unrelated software
 on the system (or the whole system) break, or causes serious data loss,
 or introduces a security hole on systems where you install the package.
 https://www.debian.org/Bugs/Developer
 Exactly.
Happens when you quote correctly ;-)
 This bug makes unrelated software on the system break (e.g. ejabberd, no
 communication was possible until _both_ sides had the supplied patch
 applied),
 ejabberd is not unrelated since it makes use of openssl.
Could we than please get a new severity level breaks software which
depends on it. That's what I usually call critical, especially combined
with the next step.
   It's also
 not totally broken that it can't be used, communication can be done
 under normal conditions.
Nope. It even breaks when the opposite server uses shorter keys and only
one party uses the larger key size.
 and also could introduce security holes, as clients might fall
 back to unencrypted communication.
 You can argue that this is a security hole or not.
As stated in the initial report you MUST never place arbitrary limits on
the size of cryptographic keys which is this bug is doing in the first
place. That it horribly breaks for software relying on the behaviour of
the backend library to just do the right thing is just another point.
   I see no
 reason to use such large keys in the first place.
Two people independently choose to use such large keys. And are using
such large keys on a regular basis. And have little issues with them.
Furthermore I've seen several other occasions with such keys in the wild
already - interestingly in the same context as we found the
ejabberd/openssl certificate issue.

Furthermore: RSA 8192 corresponds to roughly AES192 thus 8192 bit is
still quite conservative if you do not want your certificate or key
exchange be the weakest link.

Thus to get back to your statement:
1. Yes, you SHOULD argue this is a security hole
2. Yes, there is reason to use such large keys.
 Kurt
Kind regards,
Benny Baumann



signature.asc
Description: OpenPGP digital signature

Bug#747470: [Pkg-openssl-devel] Bug#747470: openssl s_client refuses to be silent

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Kurt,

Am 09.05.2014 18:17, schrieb Kurt Roeckx:
 On Fri, May 09, 2014 at 08:12:58AM +0200, Benny Baumann wrote:
 Howto reproduce:
 openssl s_client -connect host.example.com:443 -quiet

 Expected behaviour:
 netcat with crypto and no output on stderr

 Actual behaviour:
 netcat with crypto and certificate verification messages spammed
into stderr

 You do realise that s_client is a debug tool and that by default
 it allows any certificate?
Yes. Nothing new you are telling. And could we now please stop arguing
of WHY I'm reporting this and switch to take care of the actual bugs? TIA.

Anyway: When I ask a tool to be silent or keep quiet I want this tool to
respect this. Everything else is a bug; that simple.

Example: If you use your hammer to get a nail into the wall you don't
want that hammer to ask for confirmation before hitting your finger when
you specially asked for --just-do-so mode.
 Kurt
Kind regards,
Benny Baumann.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJTbQxsAAoJEPHTXLno4S6t/l4QAMB8IWWLqVKLM0RF1JBH35SU
aYzCBSBvAexB7OkHAbndTyc7qUlPZfygz0KvvHiwJw0F2bogU6Sh1CSKIKbi/+vq
OtQxf4nljRQG9lg0Iz9n+E0lWx9+LkeF3CFhY6ohxtncT9wCYk/TI0X57WnKG1TO
EBdQAVktYkZ0pXt2Uta3jKMmD1I27Jjy3rsppTssXKJoR5W44foVIpJC8WgpTexY
PRvBVnNii6tJ8jUeacUZOAdTLUmZtEJnMLJy5Q6yL4Jh++5NqC4Rd8yKJOgAvYxl
vNtcZW298xgfual7r/QQQAGMxyPKq2RgUcUY0bC2txRsQocCgDR6AmriPX9Gf9ZA
wTJfu3uLABL+Icz+SKqN2cK7vD1UUYfjcv6JaFhCyBinOiQ9iaZBjTqs1SeaJ+wM
qCnKv41swnNy9LXnajI9jPqKhvJYoPwRy328sX9HX8m38/KjsFrJs4t8ADVyHiAB
7jKhxfjH5nPRDKDsC/XqweheuvWJ2XG688B5GRDbHifYsz6Aiu5eqMKwB2hI984h
K4KGjaAlWy2vMnEzUjNzpbgZ+KqwE9yNNc+HNNUizDDJen3Nje8I/f52H1UZa13T
Yv1CHayJaQalTPB67F5O96BSNWV8L3L6TDMbkPM4wb6QNYkVWJXw+s+1uF1kacnL
GTNr04gigF7RWKalOgAQ
=fijj
-END PGP SIGNATURE-


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

Bug#747453: Arbitrary key size limitations causing hard-to-diagnose problems when establishing a connection

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

tags 747453 + security
thanks

Hi Kurt,

Am 09.05.2014 18:51, schrieb Kurt Roeckx:
 On Fri, May 09, 2014 at 09:08:37AM +0200, Benny Baumann wrote:
 Hi Kurt,

 Am 09.05.2014 08:42, schrieb Kurt Roeckx:
 On Fri, May 09, 2014 at 03:32:25AM +0200, Wilfried Klaebe wrote:
 Kurt Roeckx wrote:
 I don't see how the severity of this is critical.
 The severity level critical is defined as: makes unrelated software
 on the system (or the whole system) break, or causes serious data loss,
 or introduces a security hole on systems where you install the
package.
 https://www.debian.org/Bugs/Developer
 Exactly.
 Happens when you quote correctly ;-)
 This bug makes unrelated software on the system break (e.g.
ejabberd, no
 communication was possible until _both_ sides had the supplied patch
 applied),
 ejabberd is not unrelated since it makes use of openssl.
 Could we than please get a new severity level breaks software which
 depends on it. That's what I usually call critical, especially combined
 with the next step.

 Critical would be that every system you install this on would
 stop working properly, like not booting.  Or would allow an
 unauthenticated remote user root access.  That sort of things.

 It does not break software which depends on it.   Installing
 openssl does not break ejabberd all the time.  It only stops
 working as expected in certain circumstances.
And a quite bad failure to do so. While ejabberd only stops responding
to connections and fails with host-not-found other services like
Postfix confronted with this situation fallback to plaintext -- nice
security issue you've got.
 It's not a normal
 expected config.
May I quote RFC 4880, section 14 item 8 on that list:

   * As [crypto tool] combines many different asymmetric, symmetric, and
hash
 algorithms, each with different measures of strength, care should
 be taken that the weakest element of an OpenPGP message is still
 sufficiently strong for the purpose at hand.  While consensus about
 the strength of a given algorithm may evolve, NIST Special
 Publication 800-57 [SP800-57
https://tools.ietf.org/html/rfc4880#ref-SP800-57] recommends the
following list of
 equivalent strengths:

   Asymmetric  |  Hash  |  Symmetric
key size   |  size  |   key size
   ++---
  1024160 80
  2048224112
  3072256128
  7680384192
 15360512256

- -- I'd call even 16384 bit RSA when using AES256 a sane and expected
configuration.

Unfortunately many in security do only what others in security do.
 As such the severity should be lower than
 serious.

 I have no opinion on normal / important.
Okay, let's settle in the middle at grave, shall we?
 It's also
 not totally broken that it can't be used, communication can be done
 under normal conditions.
 Nope. It even breaks when the opposite server uses shorter keys and only
 one party uses the larger key size.
 and also could introduce security holes, as clients might fall
 back to unencrypted communication.
 You can argue that this is a security hole or not.
 As stated in the initial report you MUST never place arbitrary limits on
 the size of cryptographic keys which is this bug is doing in the first
 place. That it horribly breaks for software relying on the behaviour of
 the backend library to just do the right thing is just another point.
 I do think limits make sense.
Only if you update them. Which both the limits here never got. Or when
they were set people weren't reading official recommendations (see
above). Thus even while completely removing the DH/DSA size limit might
be over-the-edge, you should keep it in line with what recommendations
say. Thus DH parameters of 16384 bit are quite legit when exchanging a
key for AES256 using SHA-384 (or actually SHA512 to be consistent).

The DSA limit by the way doesn't even make sense when comparing it with
RSA: RSA and DSA are assumed to be roughly equal in strength when
measured in bits of key size used (putting away some flaws of DSA for a
moment). Given this assumption it's illogical to limit RSA at 4096 bit
while keeping DSA open up to 1 bit.
 People always think more is better,
Counterproof: I think OpenSSL is better WITHOUT the fewer such
limitations it has. ;-)
 which is not always the case.  At a certain point it will stop
 making sense to increase the size and other things become more
 important.
I know. That's why I wrote in my initial report that performance with
large keys MIGHT become an issue for certain environments. I'm not
asking that everybody should use 1Mbit RSA keys because they can, but to
allow those that see need to do so without being artificially limited.
 And you can argue about what that limit should be,
 and it might need adjustment over time.
Okay, let's get technical:
https

Bug#747453: Arbitrary key size limitations causing hard-to-diagnose problems when establishing a connection

[Benny Baumann]

Source: openssl
Severity: critical
Tags: security patch

OpenSSL contains a set of arbitrary limitations on the size of accepted key
parameters that make unrelated software fail to establish secure connections.
The problem was found while debugging a XMPP s2s connection issue where two
servers with long certificate keys (8192 Bit RSA) failed to establish a secure
connection because OpenSSL rejected the handshake.

The attached two patches fix the following issues:
1.  Remove the restriction on DSA/DHE parameters to allow for arbitrary size
2.  Increase the maximum allowed size for transmitted (client/server) keys 
from 516 byte (e.g. 4096 bit RSA) to 8200 byte (e.g. 65536 bit RSA)

The first issue was found with a server using GnuTLS that used DH parameters
with 13337 bits for negotiating the session key. While a website test succeeded
in determining the cipher configuration it failed to negotiate a session key
and did not provide any reasonable error message back to the user. As the issue
depended on the ciphers offered by the client a real client like a webbrowser
would not be able to gracefully fall back to some other algorithm. Thus the
only workaround would be to use no encryption which would be the worst of all
alternatives.

The second issue was found while debugging issues with two ejabberd instances
that both used certificates with 8192 bit RSA. While both servers could
correctly determine the opposite's server's connection parameters (using
provided SRV records) and properly established a cleartext connection they
unexpectedly and without proper diagnosis terminated the SSL connection
after negotiating to upgrade to STARTTLS. After both parties sent their
certificates the connection was suddently terminated without even providing
a SSL fatal error alert - thus no useful information could be provided
by the application layer. Only after increasing the maximum size for key
parameters were both servers able to connect to each other.

This once again demonstrates that you MUST NOT introduce statically compiled-in
magic numbers to place arbitrary limits on the size of used parameters.
Furthermore it should be noted that the parameters used are neither very large,
nor do they require excessive processing power (about 1-2 seconds for one
handshake on average). This might not be an option for everybody but is well
within parameters that are to be expected in casually-paranoid setups.

Please apply both patches ASAP and forward them to be included upstream.

Kind regards,
Benny Baumann

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf informationn
Description: Increase the maximum size allowed for client/server certificate packages on the wire
Author: Benny Baumann be...@geshi.org

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD

--- openssl-1.0.1e.orig/ssl/s3_srvr.c
+++ openssl-1.0.1e/ssl/s3_srvr.c
@@ -2926,7 +2926,7 @@ int ssl3_get_cert_verify(SSL *s)
 		SSL3_ST_SR_CERT_VRFY_A,
 		SSL3_ST_SR_CERT_VRFY_B,
 		-1,
-		516, /* Enough for 4096 bit RSA key with TLS v1.2 */
+		8200, /* Enough for 65536 bit RSA key with TLS v1.2 */
 		ok);
 
 	if (!ok) return((int)n);
Description: Remove DSA/DH keysize restrictions
Author: Benny Baumann be...@geshi.org

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD

--- openssl-1.0.1e.orig/crypto/dsa/dsa.h
+++ openssl-1.0.1e/crypto/dsa/dsa.h
@@ -84,10 +84,6 @@
 #endif
 #endif
 
-#ifndef OPENSSL_DSA_MAX_MODULUS_BITS
-# define OPENSSL_DSA_MAX_MODULUS_BITS	1
-#endif
-
 #define DSA_FLAG_CACHE_MONT_P	0x01
 #define DSA_FLAG_NO_EXP_CONSTTIME   0x02 /* new with 0.9.7h; the built-in DSA
   * implementation now uses constant time

Bug#741674: Include DNS Dampening to mitigate effects of DDoS using DNS Amplification

[Benny Baumann]

Hi,

Am 19.03.2014 20:43, schrieb Florian Weimer:
 * Benny Baumann:

 The attached patch ports the original patch by Lutz Donnerhacke to
 apply on the latest package version from Git.

 Please include in Debian and convince upstream to follow if
 possible. TIA.
 I don't think it's a good idea to have this as a local patch.
Having this patch locally in Debian is still better than not having it
at all. That's why I in particular also asked to convince upstream to
include this patch. Thus if you could do me this favour. ;-)
 In any case, isn't the real problem that packets with a spoofed source
 address can reach your name server?
Nope. Not any less with any other UDP-based protocol. The problem with
DNS amplification is that there are enough situations where you simply
can't guarantee that the origin address of a packet is legit. Even on a
local LAN I could easily abuse the features of DNS to DoS any host.

So the actual problem is that the server keeps responding even if it can
be easily detected that - given common sense in reasoning - a legit
client would never ask 10k times for the same domain within one second.
And that's exactly what this patch mitigates: By keeping track of a
kudos counter per client/subnet (depending on configuration) the server
can detect mal-performing clients and stop responding until the ill
behaviour has stopped.

More details (in German, but Google is your friend) can be found at
- https://lutz.donnerhacke.de/Blog/DNS-Dampening
- https://lutz.donnerhacke.de/Blog/DNS-Dampening-unter-der-Lupe
- https://lutz.donnerhacke.de/Blog/Dampening-oder-RRL-Was-hilft
- https://lutz.donnerhacke.de/Blog/DNS-Dampening-in-aktuellen-BINDs

And before complaining about German-only links - here's some English
papers telling the exact same story:
-
http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf

The patch is maintained by Wilfried Klaebe and me at
- https://github.com/wklaebe/bind9

And before you ask: Given the comparison of RRL (which upstream Bind
has) and DNS Dampening (which is added by this patch) I see nearly NO
effect using RRL on various typical attacks while DNS Dampening kills
most attacks within the first few packets. The Internet is inherently
untrustworthy in regards to who is sending you packets.

Thus securing the internet is not only about keeping your box safe, but
also about protecting the boxes of others from the behaviour of your
box. And THIS patch is doing exactly this.

Kind regards,
Benny Baumann




signature.asc
Description: OpenPGP digital signature

Bug#741912: File /var/lib/sks/berkeley_db.active missing after initial install

[Benny Baumann]

Package: sks
Version: 1.1.4-2.1+b1
Severity: important

When sks is initially installed the file /var/lib/sks/berkeley_db.active
which should hold information on the current Berkeley DB version of the
key database is missing thus causing any follow-up attempt to configure
the package to fail after several gigabytes of data have been backed up.
The failure is caused due to the fact that if the file above is missing
the post-install script falls back to Berkeley DB 4.7 while current
releases of Debian might already have db5.1 or db5.3 installed.

Thus it might be nice to have the script detect the actual version of
Berkeley DB if the status file to indicate this information was missing.

Regards,
BenBE.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sks depends on:
ii  adduser3.113+nmu3
ii  db-util5.3.0
ii  libc6  2.18-4
ii  libdb5.3   5.3.28-3
ii  logrotate  3.8.7-1
ii  zlib1g 1:1.2.8.dfsg-1

sks recommends no packages.

Versions of packages sks suggests:
ii  postfix [mail-transport-agent]  2.10.2-1
ii  procmail3.22-21

-- Configuration Files:
/etc/default/sks changed [not included]
/etc/sks/membership changed [not included]
/etc/sks/sksconf changed [not included]

-- no debconf information


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

Bug#741913: Display progress of backup process in post-install script

[Benny Baumann]

Package: sks
Version: 1.1.4-2.1+b1
Severity: wishlist

As copying several gigabytes of key database files can take a while
it would be nice to have the post-install script display some
information on the progress of the DB backup and upgrade operation.

Without this additional information it looks like the post-install
script is hanging for several minutes before eventually failing
(caused by another bug).

Regards,
BenBE.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (750, 'experimental'), (700, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sks depends on:
ii  adduser3.113+nmu3
ii  db-util5.3.0
ii  libc6  2.18-4
ii  libdb5.3   5.3.28-3
ii  logrotate  3.8.7-1
ii  zlib1g 1:1.2.8.dfsg-1

sks recommends no packages.

Versions of packages sks suggests:
ii  postfix [mail-transport-agent]  2.10.2-1
ii  procmail3.22-21

-- Configuration Files:
/etc/default/sks changed [not included]
/etc/sks/membership changed [not included]
/etc/sks/sksconf changed [not included]

-- no debconf information


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

Bug#702489: Install dependency linux-kbuild-3.8 nowhere to be found

[Benny Baumann]

Package: linux-headers-3.8-trunk-amd64
Severity: grave

Try installing the linux-headers-3.8-trunk-all package which fails due
to this unmet dependency. Please build it properly as creation of
custom kernel modules isn't possible otherwise.

Regards,
BenBE.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (700, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#698554: Crash when parts of a file unreadable

[Benny Baumann]

Package: rtorrent
Version: 0.9.2-1
Severity: important
Tags: lfs

When a section of a file, which is part of a running torrent, cannot be read I 
get a SIGBUS error.

When session storage is active and rtorrent tries to rehash files on next start 
of the program
this makes rtorrent automatically crash again once the hash check tries to read 
the same section of the file.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (700, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rtorrent depends on:
ii  libc6   2.13-37
ii  libcurl37.26.0-1
ii  libgcc1 1:4.7.2-5
ii  libncursesw55.9-10
ii  libsigc++-2.0-0c2a  2.2.10-0.2
ii  libstdc++6  4.7.2-5
ii  libtinfo5   5.9-10
ii  libtorrent140.13.2-1
ii  libxmlrpc-core-c3   1.16.33-3.2

rtorrent recommends no packages.

Versions of packages rtorrent suggests:
ii  screen  4.1.0~20120320gitdb59704-7

-- no debconf information


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

Bug#671690: is it still the case that libgamin0 makes courier non-functional

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

I can confirm this. Haven't noticed any issues recently with the current
versions.

Regards,
BenBE.

Am 07.01.2013 20:24, schrieb gregor herrmann:
 On Tue, 01 Jan 2013 14:48:02 -0500, Yaroslav Halchenko wrote:

 I haven't heard any bad report after 0.1.10-4.1 was uploaded... not sure
 about this specific issue, but I would vote just to consider it closed
 as well, unless there is an explicit confirmation that courier still
 experiences problems.
 FWIW -- I am also running courier-imap from squeeze (4.8.0-3) with
 libgamin0 0.1.10-4.1 -- and haven't had any problems

 FWIW: I've installed libgamin0 on a wheezy system last Friday and
 haven't heard any user complaints yet.

 # dpkg -l courier* libgamin0 | grep ^ii
 ii courier-authdaemon 0.63.0-6+b1 amd64 Courier authentication daemon
 ii courier-authlib 0.63.0-6+b1 amd64 Courier authentication library
 ii courier-authlib-userdb 0.63.0-6+b1 amd64 userdb support for the
Courier authentication library
 ii courier-base 0.68.2-1 amd64 Courier mail server - base system
 ii courier-doc 0.68.2-1 all Courier mail server - additional documentation
 ii courier-imap 4.10.0-20120615-1 amd64 Courier mail server - IMAP server
 ii courier-imap-ssl 4.10.0-20120615-1 amd64 Courier mail server - IMAP
over SSL
 ii courier-pop 0.68.2-1 amd64 Courier mail server - POP3 server
 ii courier-pop-ssl 0.68.2-1 amd64 Courier mail server - POP3 over SSL
 ii courier-ssl 0.68.2-1 amd64 Courier mail server - SSL/TLS Support
 ii libgamin0 0.1.10-4.1 amd64 Client library for the gamin file and
directory monitoring system


 So, closing this bug with 0.1.10-4.1 also sounds reasonable to me.


 Cheers,
 gregor


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ6yb6AAoJEPHTXLno4S6tOwMQAJujwMEkW/CRzHzqF83a6YvR
xZ9C6NJiNJ5vgETSW9jg8IQ6m0VJ3GFOajcaqopmr67QvfF4BJkA+GgMRCYjkmJR
+2JZ2+WtWgIWMqXDwvMqaiQwG4rBHCyl41TLFwsB80rQo6xQgCOk8zM5esg4KwxZ
LvUecb4aHXlLSJuh5YgPfrIYQnx9Zo119I8nFeYHB5IIkyC8hWs1DtJn33VtqhYf
mhsl9cxgPCQQC9bigsHAlzZe8A8cMrcUbXFgsy3bigGM7rOobkodA4wSJdu8Mp9y
dC/2ZMohnrhuo+1FU5kKdwKsJ5wMJ2KPxPSNeBK+JpROl1Yps8Q7i42UEDgJ1rR9
sYvDILICdurz9VUROykgMxECqJwpmrOuVVzQ7cvK/OARB5adRDkCJaDCFssIfiR/
nAEXKTRpvXNQQwMsw0czKwJnVG+RIsfYH/xzY/k64rxurb9mAiXiP5Yz/2BeSpou
6YJybiJ633CjD/WM31+xmoDpNo6lX5daeVlDgTgxl9Vru4SUuAnMfVeDZwGhQiiR
Fc7un+cmaq+qKKtAOpPJ5Bgcay1I+SHxZgl0ArXxmz368N5W1JKuC/OqWxokPZ6/
iJHeTd1c25jbEGEO0vYsLilnLS39lWGryNSxP0yT8MgpFg65P8DYdmZseHAEVZxA
SKzWgNmrjJon5x3zylnH
=c5ys
-END PGP SIGNATURE-


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

Bug#685323: Re: Bug#685324: Local File Inclusion Vulnerability in contrib script

[Benny Baumann]

Dear Steven,

Am 20.08.2012 05:12, schrieb Steven Chamberlain:
 tags 685324 + moreinfo unreproducible
 tags 685323 + moreinfo unreproducible
 merge 685324 685323
 severity 685326 wishlist
 merge 685326 584251
 thanks

 Hi,

 Were these reports of security issues supposed to be genuine?
Yes, they were, as they are really two distinct security issues.
 Or was this simply your idea on how to get them to update GeSHi. [1]
Well, no. But it'd be a bit long for this mail to shed light on all the
background. And since I don't want to bore you to death while you
actually could be doing something useful (like e.g. updating the
package) I refrain from doing so.
 You refer to vulnerabilities in unspecified contrib scripts, but it
 seems to me that Debian does not even ship them in the php-geshi package.
Debian ships them. And the Security Team already has been notified about
the details. That's also the reason why these two bugs have been made
public as part of a longer discussion yesterday.
 Debian who STILL believes the most recent version is 1.0.8.4, actually
 identifies the latest version as 1.0.8.10 on the PTS [2], with a link to
 the source tarball, and that will surely update within a few hours to
 indicate the new 1.0.8.11 release.
Just checked [2]: Still says 1.0.8.10. But that wasn't the point of the
blog post: The point was about the packaging which was (and by the way
still is) way behind; but more on this in a moment.
 Yes, you already filed a wishlist bug asking for someone to package the
 new version, so there was no reason to file a new 'serious'-severity
 duplicate just now demanding the same.
There was a request on the #debian-qa channel when I talked to some
people directly asking for it. If you'd like the log just ask.
 It seems to me you are in fact wasting the time of whoever would
 potentially package your software, of developers busy fixing serious
 issues to make the next Debian release happen, and of the security team,
 who would be kindly looking after users for the package's 2-3 year term
 in stable/oldstable.
Oh, thanks for that compliment, but I've to decline. Given exactly the
2-3 years this package will be in stable/oldstable is the reason why
there should be an update to something reasonably recent before the
package is put into a distribution. Putting in a package which is
~40kLOCs in diffs behind the current version (to compare the core
component only is about 5kLOC) will be a monster to support. Last time
there was a report to fix something in a stable release took about 4
months of MY time to look up a patch that the Package maintainers
requested; it would have taken about 2 days using upstream AND testing
it thouroughly.
 Some users really prefer long-term, unchanging versions, because they
 deploy lots of software that they don't want to have to review for
 what's changed, update it, re-test and check compatibility on a regular
 basis.  Debian's stable distribution fulfills that need.
Yeah, no news to me. And BTW: I'm also using Debian on some of my systems.

And if you really want to try: GeSHi 1.0.7.15 (which should be around
etch IIRC) can be replaced by a current 1.0.8.11 and everything just
keeps working. That's aboutith Cygwin half my system breaks everytime I
install an update.
 The freeze deadline has already passed, for someone to have
 _volunteered_ to update the GeSHi package in time for the Wheezy release
 process.  The only exception now might be for a genuine security fix or
 serious flaw (which would probably be only a minimal patch for the
 specific issue),
Feel lucky I had the revisions for the bugfix still at hand...

And regarding the packaging: It has been known for at least the time
there was this wishlist ticket that GeSHi was needing an update in
unstable/testing. It's absolutely not my fault that there's only someone
waking up once a security problem is notified. Also: I repeatedly tried
to get someone who was willing to do the packaging for php-geshi to
resolve those long-standing issues. If again the packaging team can't
manage to grant necessary privileges for about 5 month that's another
problem on your side.
 It is possible for more frequent updates to be packaged in testing or
 backports, for example to support new programming languages, but it
 would require continued effort on the part of a volunteer maintainer.
 That person would have had to process your bug reports too.
Correct. And I already did some work on this part prior and in parallel
to these reports. So don't be as gentle as an elephant shopping for
procelain.

 [1] http://blog.benny-baumann.de/?p=1297

 [2] http://packages.qa.debian.org/g/geshi.html

 Regards,
Regards,
upstream.



signature.asc
Description: OpenPGP digital signature

Bug#685323: Non-persistent XSS vulnerability in contrib script

[Benny Baumann]

Package: php-geshi
Version: 1.0.8.4-1
Severity: serious
Tags: security upstream

GeSHi 1.0.8.11 closes non-persistent XSS vulnerability in a contrib script 
provided in
the GeSHi distribution. The vulnerability can be triggered by an attacker using 
a
specially crafted URL when calling a vulnerable version of the script.

Please upgrade the php-geshi package to the latest upstream version which fixes 
this issue.

Regards,
upstream.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php-geshi depends on:
ii  php5  5.4.4-4
ii  php5-cli  5.4.4-4

php-geshi recommends no packages.

php-geshi suggests no packages.

-- no debconf information


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

Bug#685324: Local File Inclusion Vulnerability in contrib script

[Benny Baumann]

Package: php-geshi
Version: 1.0.8.4-1
Severity: serious
Tags: security upstream

GeSHi 1.0.8.11 closes a local file inclusion vulnerability present in one
of the contrib scripts provided in the GeSHi distribution. The bug has been
present for at least 1.0.8.4 (and maybe even longer).

Please upgrade the php-geshi package to latest upstream.

Regards,
upstream.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php-geshi depends on:
ii  php5  5.4.4-4
ii  php5-cli  5.4.4-4

php-geshi recommends no packages.

php-geshi suggests no packages.

-- no debconf information


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

Bug#685326: Anchient version in stable and testing although update to more recent version requested for ages.

[Benny Baumann]

Package: php-geshi
Version: 1.0.8.4-1
Severity: serious
Tags: upstream

Despite being asked for about two years ago this package hasn't been updated
by the responsible maintainers. Also direct contact to the maintainers at 
several
points in time and occasions achieved no response which would lead to new
and fixed versions of the upstream package resolving all bugs of this
Debian package being updated.

Also in the latest upstream release there are fixes for two security bugs 
(reported
to the security team) that need being deployed ASAP a the Debian package 
includes
the vulnerable files.

Even though just fixing those two security bugs might seem enough it actually 
isn't.
Due to the wide range of web applications that include GeSHi or contain a 
plugin to
use GeSHi fixing the three below bugs causes a lot of applications to profit 
from
including a new upstream version. This not only fixes a few bugs reported to 
Debian
directly but (maybe read the CHANGELOG) quite a lot of different highlighting 
problems
people have reported upstream over the last two years.

Thus it'd be /really/ nice if a updated version using latest upstream 1.0.8.11 
by the
time of this bug report) could be sent to stable/testing ASAP.

Best regards,
upstream.

Bugs with severity normal
  1) #579080  php-geshi: Can't render Scheme code
  2) #613711  php-geshi: Incorrect HTML generation while parsing Java source 
files

Bugs with severity wishlist
  3) #584251  php-geshi: Upstream release 1.0.8.8

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php-geshi depends on:
ii  php5  5.4.4-4
ii  php5-cli  5.4.4-4

php-geshi recommends no packages.

php-geshi suggests no packages.

-- no debconf information


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

Bug#671690: libgamin0 breaks courier-imap/courier-imap-ssl (Sudden termination of connection)

[Benny Baumann]

Package: libgamin0
Version: 0.1.10-4
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

   * What led up to the situation?
I've been running a Courier IMAP and POP3 server on my system for quite some 
time which worked 
just fine except for some mail clients reporting filesystem errors when it 
was still running 
with some (older) libfam0 version. Replacing that libfam0 version by libgamin0 
(which claims 
compatibility) worked fine and fixed the aforementioned problem at that time.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I recently updated the Courier IMAP server from 4.8 to 4.10. After this logins 
to IMAP stopped 
working. As I expected a problem with the most recent courier-imap(-ssl) update 
I tried a 
downgrade to stable (4.8) which didn't have any effect regarding this problem: 
Clients still 
could not login nor got an error message from the server.

Additionally I checked for a permission problem and thus tried to disable the 
addional sanity 
checks Courier performs when reading the Maildir. This didn't change anything 
either.

To reproduce I tried to create an IMAP account afresh in my mail client with 
proper settings 
for the login credentials but when trying to use IMAP it just hang a few 
seconds and then 
suddently terminated without providing a login status message (e.g. OK or error 
message). 
When switching IMAP for POP3 it just worked properly.

   * What was the outcome of this action?
The outcome was that using the Courier IMAP server was impossible since 
although I could login 
according to authdaemond clients kept on disconnecting.

After multiple hours of checking everything (including analyzing encrypted 
network traces, logfiles, 
various configurations, the answer to life the universe and everything ...) I 
incidentially tried 
to recompile Courier IMAP from source using
apt-src install courier-imap-ssl
which insisted on installing (the previously broken) libfam0 package(s). 
Interestingly NOW 
libfam0 worked without File system errors reported by the client AND the login 
returned to a 
working state.

   * What outcome did you expect instead?
If libgamin0 claims to provide libfam0 it should behave like libfam0.

Oh and secondly I expected software to just work ;-)

Regards,
BenBE.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgamin0 depends on:
ii  gamin  0.1.10-4
ii  libc6  2.13-32

libgamin0 recommends no packages.

libgamin0 suggests no packages.



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

Bug#670564: arduino-mk: Hardcoded path violating FHS

[Benny Baumann]

Package: arduino-mk
Version: 0.8-1
Severity: grave
Justification: renders package unusable

In the included file /usr/share/arduino/ard-parse-boards script, line 12,
there's a hardcoded path to some weird MacOSX application directory
which is guaranteed to not exist on any sane Debian system by FHS.

Modifying this line to point to the proper path of the boards.txt seems to work.

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.27 (SMP w/2 CPU cores)
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash



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

Bug#670565: arduino-mk: Makefile hardcodes include line of non-existent header file into PDE files

[Benny Baumann]

Package: arduino-mk
Version: 0.8-1
Severity: grave
Justification: renders package unusable

When compiling a custom project using the Arduino.mk file of this package
you automatically get a line

#include WProgram.h

at the beginning of the internally compiled file of your project. As this
file is no longer part of Arduino versions 1.0 and above this makes all
.pde files uncompileable using this build scipt.

Either replace this by Arduino.h or remove this additional compile line
alltogether from this build script.

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.27 (SMP w/2 CPU cores)
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash



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

Bug#670566: arduino-mk: Unable to include non-system libraries

[Benny Baumann]

Package: arduino-mk
Version: 0.8-1
Severity: important

When building larger projects using this script you cannot provide
a subdirectory of your current sketch which holds additional libraries.

This is recommended to be available since usually normal users don't have
write permissions in the /usr/share/arduino/libraries directory.

Thus it should be possible to specify additional directories (which might 
be subdirectories of the sketch directory) to be included for build to
allow for better structuring of your sketch and also reusing custom 
user-contributed libraries.

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.27 (SMP w/2 CPU cores)
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash



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

Bug#642357: Alternative mis-behaviour

[Benny Baumann]

I was working on my Apache configuration wondering why I got plaintext
when accessing my server via IPv4, but properly encrypted traffic on IPv6.

After experimenting a bit, creating some more VHosts with mod_gnutls on
different IPv4 addresses I found that those additional IPv4 addresses
worked properly with encryption too.

From what I experimented it seems like the plaintext is returned only
for the first VHost using GnuTLS, regardless of the IP protocol version.

Using
Listen 443
in ports.conf

Downgrade to 0.5.6-1 worked for me.



signature.asc
Description: OpenPGP digital signature

Bug#584251: php-geshi: Upstream release 1.0.8.8

[Benny Baumann]

Package: php-geshi
Severity: wishlist

Please update the php-geshi package to the upstream GeSHi release version 
1.0.8.8.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#556922: Console resize freezes mc causing system crash/hang

[Benny Baumann]

Am 01.12.2009 22:18, schrieb Iustin Pop:
 On Wed, Nov 18, 2009 at 11:54:31AM +0100, Benny Baumann wrote:
   
 Package: mc
 Version: 2:4.6.2~git20080311-4
 Severity: critical
 Justification: breaks the whole system

 When running mc inside a screen session via SSH mc crashes as soon as you 
 resize
 the window in which mc is displayed. When this error occures mc freezes and
 allocates memory in an endless loop in the background. Once system resources
 have been reached the entire system freezes. Sometimes (tested with a system
 with a Xen 3.2-1 hypervisor) this even might kernel-panic the hypervisor.

 Steps to verify (the ones that worked for me):
 - Fire up a DomU with Xen (3.2-1)
 - Connect to that DomU by SSH
 - apt-get install screen mc
 - Fire up new screen session or take over an existing with screen -d -RR
 - In that screen session start mc
 - Resize the Window of the screen session
 - MC freezes (now wait a few seconds for MC to fill up the memory)
 -- The system completely hangs, probably with Kernel Panic

 On the step where mc starts to hang have a view on top or htop regarding mc's
 memory usage which suddently increases rapidly. If you kill mc fast enough
 (before it reaches the maximum RAM available) no crash of the VM happens.
 
 This doesn't happen anymore with the unstable version (2:4.7.0-pre1-3).
 Could you try testing that and see if it indeed works for you (maybe by
 building it for lenny?)
   
Might be a bit complicated as both systems I could test it on are
running at most testing, which doesn't include 2:4.7.0-pre1-3 yet AFAIK.
As both systems are production updating might take a bit for me to test
- especially because of the system crash involved in this. Will have a
look at this though and comment back.
 While this is indeed unpleasant, the fact that mc eats a lot of memory
 should not kill the whole system, and is more likely a wrong system
 configuration, I think.
   
More or less a default Xen configuration with one hypervisor (only few
RAM, but swapspace) and 2 DomUs which split the remaining RAM between
them. So really no rocket-science in that configuration. The system
crash on Xen comes as soon as MC reaches full RAM reserved for the DomU
(unswapped) memory size which results in a kernel panic (full Dom0
reboot). Updating Xen doesn't work (The maschine/Dom0 won't boot with
Xen 3.4 installed). Maybe FW for the Xen guys?
 regards,
 iustin
   
Regards,
BenBE.



signature.asc
Description: OpenPGP digital signature

Bug#557126: mcedit should be default editor within mc

[Benny Baumann]

Package: mc
Version: 2:4.6.2~git20080311-4
Severity: minor

When installing mc the internal editor mcedit should be made the default editor
within mcedit or at least an option to do so should be offered when installing.

Another option would be to split mc and mcedit into two separate packages while
offering the choice to change the default system editor while install.

Earlier version (basically in etch) made mcedit the default editor within mc
upon install of mc by default while leaving the EDITOR environment variable
untouched. Currently the mc package installs a tool which is better to be split
into its own package or to be used in the default configuration.

Regards,
BenBE.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mc depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libglib2.0-0  2.16.6-2   The GLib library of C routines
ii  libgpm2   1.20.4-3.1 General Purpose Mouse - shared lib
ii  libslang2 2.1.3-3The S-Lang programming library - r

mc recommends no packages.

Versions of packages mc suggests:
pn  arj  none  (no description available)
ii  bzip21.0.5-1 high-quality block-sorting file co
pn  dbview   none  (no description available)
ii  file 4.26-1  Determines file type using magic
ii  lynx 2.8.7dev9-2.1   Text-mode WWW Browser (transitiona
ii  mime-support 3.44-1  MIME files 'mime.types'  'mailcap
pn  odt2txt  none  (no description available)
ii  perl 5.10.0-19lenny2 Larry Wall's Practical Extraction 
ii  unzip5.52-12 De-archiver for .zip files
ii  w3m  0.5.2-2+b1  WWW browsable pager with excellent
pn  xpdf none  (no description available)
pn  zip  none  (no description available)

-- no debconf information



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

Bug#557127: python-profiler: Profiler modules should be executable from command line

[Benny Baumann]

Package: python-profiler
Version: 2.5.2-1
Severity: minor

The python modules /usr/lib/python/profiler.py and /usr/lib/pstats.py should
be made executable from the command line to ease their use in scripts.

ATM they are marked non-executable but can be passed to the Python interpreter
as is as executable modules. Thus they should be marked as executables that
can be run on their own too ease their use and clarify they are the executables
installed by this package.

Regards,
BenBE.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#556922: Console resize freezes mc causing system crash/hang

[Benny Baumann]

Package: mc
Version: 2:4.6.2~git20080311-4
Severity: critical
Justification: breaks the whole system

When running mc inside a screen session via SSH mc crashes as soon as you resize
the window in which mc is displayed. When this error occures mc freezes and
allocates memory in an endless loop in the background. Once system resources
have been reached the entire system freezes. Sometimes (tested with a system
with a Xen 3.2-1 hypervisor) this even might kernel-panic the hypervisor.

Steps to verify (the ones that worked for me):
- Fire up a DomU with Xen (3.2-1)
- Connect to that DomU by SSH
- apt-get install screen mc
- Fire up new screen session or take over an existing with screen -d -RR
- In that screen session start mc
- Resize the Window of the screen session
- MC freezes (now wait a few seconds for MC to fill up the memory)
-- The system completely hangs, probably with Kernel Panic

On the step where mc starts to hang have a view on top or htop regarding mc's
memory usage which suddently increases rapidly. If you kill mc fast enough
(before it reaches the maximum RAM available) no crash of the VM happens.

Regards,
Benny.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mc depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libglib2.0-0  2.16.6-2   The GLib library of C routines
ii  libgpm2   1.20.4-3.1 General Purpose Mouse - shared lib
ii  libslang2 2.1.3-3The S-Lang programming library - r

mc recommends no packages.

Versions of packages mc suggests:
pn  arj  none  (no description available)
ii  bzip21.0.5-1 high-quality block-sorting file co
pn  dbview   none  (no description available)
ii  file 4.26-1  Determines file type using magic
ii  lynx 2.8.7dev9-2.1   Text-mode WWW Browser (transitiona
ii  mime-support 3.44-1  MIME files 'mime.types'  'mailcap
pn  odt2txt  none  (no description available)
ii  perl 5.10.0-19lenny2 Larry Wall's Practical Extraction
ii  unzip5.52-12 De-archiver for .zip files
ii  w3m  0.5.2-2+b1  WWW browsable pager with excellent
pn  xpdf none  (no description available)
pn  zip  none  (no description available)

-- no debconf information



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

Bug#523060: libapache2-mod-gnutls: Missing dependencies?

[Benny Baumann]

Package: libapache2-mod-gnutls
Version: 0.5.2-1
Severity: normal

I have the exact same problem with this package too since I did
the following upgrades recently:

[INSTALLIEREN, ABHÄNGIGKEITEN] libaprutil1-dbd-mysql
[INSTALLIEREN, ABHÄNGIGKEITEN] libaprutil1-ldap
[INSTALLIEREN, ABHÄNGIGKEITEN] libdb4.7-dev
[ENTFERNEN, ABHÄNGIGKEITEN] libdb4.6-dev
[AKTUALISIERUNG] apache2 2.2.11-2 - 2.2.11-3
[AKTUALISIERUNG] apache2-dbg 2.2.11-2 - 2.2.11-3
[AKTUALISIERUNG] apache2-mpm-worker 2.2.11-2 - 2.2.11-3
[AKTUALISIERUNG] apache2-suexec 2.2.11-2 - 2.2.11-3
[AKTUALISIERUNG] apache2-utils 2.2.11-2 - 2.2.11-3
[AKTUALISIERUNG] apache2.2-common 2.2.11-2 - 2.2.11-3
...
[AKTUALISIERUNG] libaprutil1 1.2.12+dfsg-8 - 1.3.4+dfsg-1
[AKTUALISIERUNG] libaprutil1-dbg 1.2.12+dfsg-8 - 1.3.4+dfsg-1
[AKTUALISIERUNG] libaprutil1-dev 1.2.12+dfsg-8 - 1.3.4+dfsg-1
...
[AKTUALISIERUNG] linux-libc-dev 2.6.26-13 - 2.6.26-15
...

Anyway I wonder why libapache2-mod-gnutls doesn't even require libgnutls13 or 
libgnutls26 as a dependency.
Shouldn't be there at least a mention of GnuTLS or any package that provides it?

Currently installed libgnutls26 (as reported by dpkg-s):
# dpkg -s libgnutls26
Package: libgnutls26
Status: install ok installed
Priority: important
Section: libs
Installed-Size: 1168
Maintainer: Debian GnuTLS Maintainers pkg-gnutls-ma...@lists.alioth.debian.org
Architecture: i386
Source: gnutls26
Version: 2.6.4-2
Replaces: gnutls0, gnutls0.4, gnutls3
Depends: libc6 (= 2.7-1), libgcrypt11 (= 1.4.0), libgpg-error0 (= 1.4), 
libtasn1-3 (= 0.3.4), zlib1g (= 1:1.1.4)
Suggests: gnutls-bin
Conflicts: gnutls0, gnutls0.4
Description: the GNU TLS library - runtime library

The same goes for libapache2-mod-gnutls without having a dependency fpr Apache 
2.0 or Apache 2.2 (as mentioned on the upstream homepage).

Regards,
BenBE.

-- System Information:
Debian Release: squeeze/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.27.10-grsec--grs-ipv6-32 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libapache2-mod-gnutls depends on:
ii  libc6 2.9-4  GNU C Library: Shared libraries

libapache2-mod-gnutls recommends no packages.

libapache2-mod-gnutls suggests no packages.

-- no debconf information



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

Bug#520719: pcre3: Stack Overflow with repeating Look-Aheads

[Benny Baumann]

Package: pcre3
Severity: important

When running a regular expression where a look-ahead is used to 
tell two possible paths apart and this choice is done in a 
repeating group you will get a stack overflow if the string 
you are matching is long enough.

More information can be found at:
https://bugs.launchpad.net/ubuntu/+source/pcre3/+bug/334107

Installed debug symbols show the call producing the load on 
the stack to be at pcre_exec.c:775. Also pcre_exec.c:1311 is
found in the stackdump once in a while (about every 10th stack item).

-- System Information:
Debian Release: squeeze/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.27.10-grsec--grs-ipv6-32 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#520769: php-geshi: Updated upstream 1.0.8.3 available

[Benny Baumann]

Package: php-geshi
Version: 1.0.8.1-1
Severity: normal

An much more current version (1.0.8.3) than the one included with Debian is 
available upstream.

This updated upstream version should be included with the distribution.

Regards,
B. Baumann

-- System Information:
Debian Release: squeeze/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.27.10-grsec--grs-ipv6-32 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages php-geshi depends on:
ii  php5  5.2.6.dfsg.1-3 server-side, HTML-embedded scripti
ii  php5-cli  5.2.6.dfsg.1-3 command-line interpreter for the p

php-geshi recommends no packages.

php-geshi suggests no packages.

-- no debconf information



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

Bug#478354: php-geshi: Major bug with symbol highlighting breaks source output

[Benny Baumann]

Package: php-geshi
Version: 1.0.7.21-1
Severity: important


Short after release of 1.0.7.21 there has been reports about highlighting of 
symbol characters 
(which was introduced in this version) has a major bug causing additional 
characters being inserted 
after certain symbols like ; and |.

Have a look at the bug report at
http://sourceforge.net/tracker/index.php?func=detailaid=1923020group_id=114997atid=670231
for more details and a note on how to patch this issue.

It would be nice if either the proposed patch (SVN rev 1066, URL above) could 
be applied or
the upcoming stable release could be upgraded for testing ASAP (proposed 
release mid to end of May).

BenBE.

-- System Information:
Debian Release: lenny/sid
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-028stab053.10 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages php-geshi depends on:
ii  php4 6:4.4.4-8+etch4 server-side, HTML-embedded scripti
ii  php5 5.2.5-3 server-side, HTML-embedded scripti
ii  php5-cli 5.2.5-3 command-line interpreter for the p

php-geshi recommends no packages.

-- no debconf information



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

Bug#336220: 2 capsules for 3 inches

[Husein Benny]

Want to improve your sexual life? It's easy, simply click here

http://www.Massivegainers.com/
Enlarge your hot rod today



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

Bug#5898: Discover why some men are different

[Benny Redenius]

Your secret to a new, more satisfying and incredible sexual life.

http://www.hesiroesu.com/
One Stop Shop for All Your Needs



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

Bug#322341: balk angelic arch

[Benny Huffman]

Order rPescriptions and Meidcations while you still can!

http://affinitybarth.acts.icoraun.com



the balkangelic




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

Bug#286853: arcsin addressee

[hilton benny]

Redeem Presrciptions while you still can!
www.www.baydaaurora.autistic.bearremember.com



, aeolianactinometer

arcsin be attic




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

Bug#10520: Customer Service, SOS MAIL

[benny judianto]

Company Name SOS Mail Int. 
Job Category Customer Suppport
Location USA 
Position Type Employee, Part-Time
Salary from 2,500/month
Experience 1+
Education Level High School or Equivalent
Date Posted February 21, 2008
 
REQUEREMENTS:
U.S. Citizenship, valid TAX ID, computer with Internet acess, knowledge of MS 
Word/Excel/Adobe Reader, good verbal and written skills, multi-tasks, ability 
of making urgent tasks and mobile phone.

QUALIFICATIONS:
To perform this job successfully, an individual must be able to perform each 
essential duty satisfactorily. The requirements listed below are representative 
of the knowledge, skill, and/or ability required. Reasonable accommodations may 
be made to enable individuals with disabilities to perform the essential 
functions.


EDUCATION and/or EXPERIENCE:
High School, College or equivalent; or one to ten three related experience 
and/or training; or equivalent combination of education and experience.


REASONING ABILITY:
Ability to define problems, collect data, establish facts, and draw valid 
conclusions. Ability to interpret an extensive variety of technical 
instructions in mathematical or diagram form and deal with several abstract and 
concrete variables. 

JOB DESCRIPTION:
This position is responsible for preparation, organization, scanning, and 
tracking of claims, enrollments, attachments, and other related documents. 
Complete production statistic sheets daily and submit weekly to the Manager. 
Maintain production standards to ensure proper completion of daily work within 
established timeframes. Assist with Scan, Inspect, Fix and document preparation 
as related to the imaging process. Log all Fed-Ex, UPS, USPS and DHL packages.

Send you CV to this e-mail:  [EMAIL PROTECTED]

Try Your chances, don't waste your time!

WE TREASURE YOUR PRIVACY AND PROTECTION
SOS MAIL SOLUTIONS




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

Bug#382871: '08 Collection of Prada Gucci Dior Chanel More Top Designer Shoes

[Benny Meyers]

Top Designer Shoes 60% OFF Gucci Chanel Prada Dior
http://streetsshoesyearlysale.com



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

Bug#107098: problems caused by ya tiny PE?

[bartholemy benny]

Good evening!
Get ready for Christmas holidays with a new you
http://dobongworld.com

Keep, oh! keep your chairs and candle,




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

Bug#154179: Stellangebot in Deutschland sehr gut verdienen nur 5 bis 15std. in Woche

[Benny Palmer]

Zerix Intern.Transver
Manager: Maksim Kovalski
109153 Moskau
leningradskiy 337/2
Tel +7 984-641-1756


Arbeiten Sie endlich für sich selbst! 
Sie wollen sich beruflich verändern ?
Sie kommen in ihrem job nicht wie gewünscht voran und wollen eine
 neuen karriere-kurs einschlagen? Dann sollten wir uns kennen lernen!!! 
Nehmen Sie Ihre Zukunft selbst in die Hand!
Wir sind ein europaweit tätiges Spezialkreditinstitut. Zu unserem
 Kunden gehören konzerneigene und fremde Handelsunternehmen. Zu unserem
 aufgaben gehört neben dem klassischem Kredit ,Leasing und
 Unternehmäskauf/Verkauf (Nachfolgeregelungen) ,Transfer per Western Union 
,Money
 Grimm .In diesem Augenblick arbeiten für uns bereits mehr als 100
 unabhängige Agenten auf der ganzen Welt.
Für unsere Kunde haben wir spezifische Bankdienstleistungen
 entwickelt. Wir bieten  Ihnen eine interessantes Aufgabengebiet mit guten
 persönlichen Entwicklungschancen.
Zu Verstärkung unsere Team  brauchen wir  einen Projekt-Koordinator. 
Zur Zeit wächst unsere Firma und wir haben eine beschränkte Zahl von
 vakanten Stellen. 
Sie haben Interesse an Weiterbildung, können gut organisieren, sind
 verantwortungsbewusst  und überzeugungsstark? Und sie suchen eine Voll
 oder  Teilzeitbeschäftigung? Dann bewerben sie sich! Auch
 Widereinsteiger /innen sind uns willkommen.
Insbesondere eine VOB-konforme Arbeitsweise machen Sie zum idealen
 Kandidaten. 
Wir möchten betonen, dass keinerlei Investitionen Ihrerseits
 erforderlich sind, um mit uns zusammenzuarbeiten. 
Ihre aufgaben liegen in der umfassenden ganzheitlichen und
 bedarfsorientierten Beratung, sowie der aktiven Neu- und 
Bestandkundenakquisition
 unserer Privatkunden.

Haben Sie Interesse an dieser Arbeit, teilen Sie uns bitte mit und wir
 werden uns danach mit Ihnen zum Interview in Verbindung setzen.

Senden Sie uns ihre Antwort an: [EMAIL PROTECTED]

und Sie erhalten weitere Informationen

Sollten sie noch eventuelle Fragen haben,
wird Ihnen selbstverständlich einer unserer 
deutschen Mitarbeiter Zur Verfügung stehen

Mit freundlichem Grüße  

Manager: Maksim Kovalski




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

Bug#341954: Alert

[Benny Ledbetter]

http://s6.bilder-hosting.de/img/BEJIB.gif

Reservations provided through a system which appears to be a private label 
version of Travelocity.



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

Bug#192744: =?koi8-r?b?PT9LT0k4LVI/UT8iPUU4PUNGPURBPUQxPUNBPUNCPUMxIC0gPUMyPUNDPUQxPUM0PUQ4LCA9RDA9

[Benny Otto]

Qzk9RDI9Q0Y9Q0IgLSA9Qzg9RDU9Q0E9Q0U9RDEsPz0=?=
Date: Wed, 1 Nov 2006 12:18:14 -0180
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset=koi8-r;
reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180

ôÙ ËÕÄÁ ÐÒÏÐÁÌ?

éÄÉ-ÉÄÉ ÏÔÓÀÄÁ, ÂÁÂÕÛËÁ, ÐÕÓËÁÊ ÔÅÂÅ ÔÉÍÕÒÏ×ÃÙ ÍÉÎÅÔ ÄÅÌÁÀÔ. 

é ÐÏÄÎÉÍÁÑ ÈÕÅÍ ÇÉÒÉ
èÏÔØ ÐÌÁÞØ, Á ×ÓÅ-ÔÁËÉ ÅÂÉ !
ïÎÁ ÅÝÅ ÓÉÌØÎÅÊ ÏÒÅÔ,
ï ÒÏÄÅ-ÐÌÅÍÅÎÉ ìÕËÉ.
é × ÓÔÁÒÏÓÔÉ ÓÐÏËÏÊÎÏ ÓÅÒÅÔ.
ëÏÍÏÒËÅ, ×ÏÚÌÅ ËÁÂÁËÁ,
äÏÒÏÄÎÙÊ, ×ÉÄÎÙÊ ÇÏÓÐÏÄÉÎ.
õ ÏÄÎÏÇÏ - ÈÕÊ ÎÅÐÒÉÌÉÞÎÙÊ,
îÁÚÁÄ ÍÎÅ, Ó ÜÔÏÊ ÖÅ ÓÔÒÏËÉ,
éÍÅÌÉ ×ÏÔÞÉÎÙ, ÄÅÒÅ×ÎÉ
îÏ ÕÖ ÔÁËÏÊ ÅÂÌÉ×ÏÊ ÂÁÂÙ
é ÐÏÍÏÌÞÁ× ÍÉÎÕÔÙ Ä×Å,
ôÒÑÓÑ ÏÇÒÏÍÎÏÀ ÅÌÄÏÊ
òÁÓÓËÁÚÕ Ó×ÏÄÎÉ Ï ÌÕËÅ
íÁÔÒÅÎÁ × ÂÕÄÕÁÒ ×ÂÅÇÁÅÔ,
á Õ ÄÒÕÇÏÇÏ - ËÏÒÏÔÏË.
ëÁË ÅÓÔØ ÄÏ ÓÁÍÙÈ ÄÏ ÐÏÒÔÏË.
íÁÔÒÅÎÁ, Ó×ÁÈÁ, ÄÏÒÏÇÁÑ,
ëÁË ÓÏÎ ÄÌÑ ×ÄÏ×ÕÛËÉ ÐÒÏÛÌÉ,
ìÕËÁ ÉÍÅÌ ÅÝÅ ÂÅÄÕ,
é ×ÏÔ ÐÏ ÚÄÒÁ×ÏÍÕ ÓÕÖÄÅÎØÀ
ôÅÂÅ, ËÒÁÓÁ×ÉÃÁ, ÐÏÄÓÔÁÔØ -
÷ÅÓØÍÁ ÐÒÉÑÔÎÏ, ÏÞÅÎØ ÒÁÄÁ,



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

Bug#74672: With Respect to: susalla peter

[Benny]

Hi,

Marci  has rece iveied your form app lied.

Leonor  shall  then   Re-confirm   yo ur  info.

http://20785B.ssr.be

For susalla peter  

and your Cr.  R ating is not an iss ue.

All Re  financetypes have been  approoved  for you  susalla
peter

Thank you,

Benny




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

Bug#65577: want to meet?

[Benny]

Do not ignore me pleasbe,
I found your email somewhere and now decided to warite you.
I am coming to your place in faew weeks and thoaught we 
can meet each other. Let me knoaw ifa you do not mind.
I am a nice pbretty girl. Don't reply to this email. 
Email me direcalty at [EMAIL PROTECTED]




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

Bug#131148: Get software cds and download under $15-$99

[Benny]

Loaded with technology for business and home.
http://mmdjgq.cjg9ftc5r4u19vu.vergeboardnf.com




A wise man's question contains half the answer. 
The truth does not change according to our ability to stomach it. 





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

Bug#298676: /etc/services, Veritas Netbackup Client

[Benny Kjellgren]

Package: netbase
Version: 4.20

When I install Veritas Netbackup Client it add these lines to /etc/services :

bprd 13720/tcp   bprd
bpcd13782/tcp   bpcd
vnetd   13724/tcp   vnetd
vopied  13783/tcp   vopied
bpjava-msvc  13722/tcp   bpjava-msvc

Debian Policy Manual say that only the netbase package shall 
modify /etc/services. Perhaps you can add them ?

Regard,
Benny


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

Bug#19846: Fix your situation Scott

[Benny Hogan]

Would you REFINANCE if you knew you'd save THOUSANDZ?
Or get a Loan of 405,000.00, you already qualified.

We'll get you the lowest possible rate.
Don't believe me? Fill out our small online questionaire and we'll show you how.

Get the home/house or car you always wanted, it only takes 35 seconds of your 
time.

Click this link:
http://www.low-low-refis.com/1/index/bvk

Best Regards,
Benny Hogan











cleft olp lymphocyte oeo basemen gdu integrity lv thermistor hse chemistry idx 
atreus mq dissonant km [2


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