Bug#901148: Bug still present

[Antoine Amarilli]

Hi,

I'm still affected by this (must close timidity and restart pulseaudio
after a reboot), and judging from the comment
https://superuser.com/questions/1312163/dummy-output-instead-of-audio-device-on-debian-9/1346784?noredirect=1#comment2168375_1346784
I'm not the only person affected. So afaict the bug is still present.

-- 
Antoine Amarilli



signature.asc
Description: PGP signature

Bug#880047: marked as done (postgrey doesn't start because it can't write its pid)

[Debian Bug Tracking System]

Your message dated Wed, 15 May 2019 08:10:11 +
with message-id <20190515081011.ga13...@sarek.noreply.org>
and subject line Re: Bug#880047: postgrey doesn't start because it can't write 
its pid
has caused the Debian Bug report #880047,
regarding postgrey doesn't start because it can't write its pid
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
880047: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880047
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postgrey
Version: 1.36-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The default init script that comes with Postgrey on Debian 9 fails to start 
after a reboot. The installer creates /var/run/postgrey and writes its pid 
there but /var/run is a tmpfs file system and so on a reboot /var/run/postgrey 
ceases to exist. The init script for Postgrey does not attempt to create 
/var/run/postgrey and just fails to start when it can't write to 
/var/run/postgrey. When postgrey fails to start then Postfix starts complaining 
that it is misconfigured and begins bouncing emails. I was able to fix this by 
adding these lines to the do_start function in the init script:

# Assure that /var/run/postgrey exists
[ -d /var/run/postgrey ] || mkdir -p /var/run/postgrey

if [ "$DAEMON_USER" != "root" ]; then
chown "$DAEMON_USER" /var/run/postgrey
fi


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages postgrey depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
pn  libberkeleydb-perl 
pn  libnet-dns-perl
pn  libnet-server-perl 
pn  libnetaddr-ip-perl 
ii  perl   5.24.1-3+deb9u2
ii  ucf3.0036

Versions of packages postgrey recommends:
pn  libnet-rblclient-perl  
pn  libparse-syslog-perl   
ii  postfix3.1.6-0+deb9u1

postgrey suggests no packages.
--- End Message ---
--- Begin Message ---
On Sat, 28 Oct 2017, Paul Lockaby wrote:

> Dear Maintainer,
> 
> The default init script that comes with Postgrey on Debian 9 fails to start 
> after a reboot.
> The installer creates /var/run/postgrey and writes its pid there

It seems to me that the default init script that ships with Debian 9
does not use the directory /var/run/postgrey.

Thus closing this bug.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/--- End Message ---

Processed: Re: Bug#928986: CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so:

[Debian Bug Tracking System]

Processing control commands:

> found -1 2.10.2-1
Bug #928986 [cloudcompare] CloudCompare: error while loading shared libraries: 
libQCC_IO_LIB.so:
Marked as found in versions cloudcompare/2.10.2-1.

-- 
928986: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928986
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928986: CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so:

[Juhani Numminen]

Control: found -1 2.10.2-1

Hi,

On Tue, 14 May 2019 19:25:25 +0200 Johannes 'josch' Schauer  
wrote:

> after installing the package, when attempting to start CloudCompare I
> get the following error message:
> 
> CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so:
> cannot open shared object file: No such file or directory

I also get the same message, for both versions 2.10.1-1 (from buster) and
2.10.2-1 (from experimental).

> Indeed that file seems to be contain in no binary package in the
> archive?

Such a file is actually shipped in the cloudcompare package itself.

$ dpkg -L cloudcompare | grep libQCC_IO_LIB.so
/usr/lib/x86_64-linux-gnu/cloudcompare/libQCC_IO_LIB.so


Regards,
Juhani

Bug#916375: AW: [debian-mysql] Bug#916375: Update libaprutil1-dbd-mysql

[Daniel Högele - adelphi]

Hi Otto

>If I don't get any more info on these bugs or precise steps on how to
>reproduce, I will just close this bug report. No point in keeping it
>hanging if nobody of the affected users supply more input.

Sorry, I've been in holiday and thereafter busy in other projects. I will 
create a snapshot of the current status of the VM to play around a little bit 
(including Updating libaprutil1-dbd-mysql to 1.6.1-4 and removing php5) and 
give you an update next week.

What I already can tell is the history of the system:
- First LAMP setup with Debian 6 (Squeeze) on December 28th 2012.
- Upgrade from fully patched Debian 6 to Debian 7 (Wheezy) on May 6th 2013.
- Upgrade from fully patched Debian 7 to Debian 8.2 (Jessie) was done on 
September 7th 2015
- Upgrade from fully patched Debian 8 to Debian 9 (Stretch) was done on June 
28th 2017.

All updates have been done according to the official guides, e.g. 
https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html 

Where are using following repositories only:
deb http://ftp.de.debian.org/debian/ [version] main contrib non-free
deb-src http://ftp.de.debian.org/debian/ [version] main contrib non-free
deb http://security.debian.org/ [version]/updates main contrib non-free
deb-src http://security.debian.org/ [version]/updates main contrib non-free
deb http://ftp.de.debian.org/debian/ [version]-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ [version]-updates main contrib non-free

Therefore it may be possible to reproduce the bug by repeating this update 
sequence, at least for the steps from 8 to 9 (or maybe 7->8->9).

List of all installed packages for php, mysql and mariadb:

apt list --installed | grep -E 'mysql|php|maria'
dbconfig-mysql/stable,now 2.0.8 all [installed,automatic]
default-mysql-server/stable,now 1.0.2 all [installed,automatic]
libapache2-mod-php/stable,now 1:7.0+49 all [installed]
libapache2-mod-php5/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
libapache2-mod-php7.0/stable,stable,now 7.0.33-0+deb9u3 amd64 
[installed,automatic]
libdbd-mysql-perl/stable,now 4.041-2 amd64 [installed]
libmariadbclient18/now 10.1.26-0+deb9u1 amd64 [installed,upgradable to: 
10.1.38-0+deb9u1]
libmysqlclient-dev/now 5.5.55-0+deb8u1 amd64 [installed,local]
libmysqlclient18/now 5.5.55-0+deb8u1 amd64 [installed,local]
libphp-adodb/stable,now 5.20.9-1 all [installed]
libphp-pclzip/now 2.8.2-3 all [installed,local]
mariadb-client-10.1/stable,now 10.1.38-0+deb9u1 amd64 [installed,automatic]
mariadb-client-core-10.1/stable,now 10.1.38-0+deb9u1 amd64 [installed,automatic]
mariadb-common/stable,now 10.1.38-0+deb9u1 all [installed,automatic]
mariadb-server-10.1/stable,now 10.1.38-0+deb9u1 amd64 [installed,automatic]
mariadb-server-core-10.1/stable,now 10.1.38-0+deb9u1 amd64 [installed,automatic]
mysql-common/stable,now 5.8+1.0.2 all [installed,automatic]
mysql-server/stable,now 5.5.+default amd64 [installed]
mysqltuner/stable,now 1.6.18-1 all [installed]
php/stable,now 1:7.0+49 all [installed,automatic]
php-apcu/stable,now 5.1.8+4.0.11-1 amd64 [installed]
php-apcu-bc/stable,now 1.0.3-2 amd64 [installed,automatic]
php-bz2/stable,now 1:7.0+49 all [installed,automatic]
php-common/stable,now 1:49 all [installed,automatic]
php-curl/stable,now 1:7.0+49 all [installed,automatic]
php-fpm/stable,now 1:7.0+49 all [installed]
php-gd/stable,now 1:7.0+49 all [installed,automatic]
php-gettext/stable,now 1.0.12-0.1 all [installed,automatic]
php-gmp/stable,now 1:7.0+49 all [installed]
php-intl/stable,now 1:7.0+49 all [installed]
php-mbstring/stable,now 1:7.0+49 all [installed,automatic]
php-mysql/stable,now 1:7.0+49 all [installed,automatic]
php-pclzip/stable,now 2.8.2-4 all [installed,automatic]
php-pear/stable,stable,now 1:1.10.1+submodules+notgz-9+deb9u1 all 
[installed,automatic]
php-php-gettext/stable,now 1.0.12-0.1 all [installed,automatic]
php-phpseclib/stable,now 2.0.4-1 all [installed,automatic]
php-snmp/stable,now 1:7.0+49 all [installed]
php-soap/stable,now 1:7.0+49 all [installed]
php-tcpdf/stable,now 6.2.12+dfsg2-1 all [installed,automatic]
php-xdebug/stable,now 2.5.0-1 amd64 [installed]
php-xml/stable,now 1:7.0+49 all [installed,automatic]
php-xmlrpc/stable,now 1:7.0+49 all [installed]
php-zip/stable,now 1:7.0+49 all [installed,automatic]
php5-apcu/now 4.0.7-1 amd64 [installed,local]
php5-cli/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-common/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-curl/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-gd/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-imap/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-json/now 1.3.6-1 amd64 [installed,local]
php5-ldap/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-mcrypt/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-mysql/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-readline/now 5.6.30+dfsg-0+deb8u1 amd64 [installed,local]
php5-sasl/now 0.1.0-3+b1 amd64 [installed,local]
php5-snmp/now 5.6.30+

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed 929007 3.20190514.1
Bug #929007 [intel-microcode] intel-microcode: Update intel-microcode to 
20190514
Marked as fixed in versions intel-microcode/3.20190514.1.
> close 929007
Bug #929007 [intel-microcode] intel-microcode: Update intel-microcode to 
20190514
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929007: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929007
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#929017: mutt: undefined behavior on huge integer in a RFC 2231 header

[Vincent Lefevre]

Package: mutt
Version: 1.10.1-2
Severity: serious
Tags: security upstream fixed-upstream

The rfc2231.c file contains:

  index = atoi (s);

where the string s is part of a RFC 2231 parameter in a header. For
instance, if in a message (invalid, but which can occur due to spam,
attack, etc.), one has:

Content-Disposition: inline;
filename*17="na";
filename*99="me"

atoi() will be called on the string "99",
which is undefined behavior and may have security implications
depending on the atoi() implementation.

I've just fixed this issue in the following commit:

https://gitlab.com/muttmua/mutt/commit/3b6f6b829718ec8a7cf3eb6997d86e83e6c38567

-- Package-specific info:
Mutt 1.11.4+211 (79563636) vl-117499 (2019-05-13)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.19.0-5-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-7' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-7) 

Configure options: '--prefix=/home/vlefevre' 
'--exec-prefix=/home/vlefevre/x86_64' '--enable-debug' '--enable-pop' 
'--enable-imap' '--with-ssl' '--enable-compressed' 
'--with-exec-shell=/home/vlefevre/bin/sh.screen' '--enable-gpgme' 
'--with-system-dotlock=/usr/bin/mutt_dotlock' 'CC=gcc' 'CFLAGS=-g -O3 
-march=native -fsanitize=undefined -fno-sanitize-recover'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O3 -march=native 
-fsanitize=undefined -fno-sanitize-recover

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  -USE_SMTP  
+USE_SSL_OPENSSL  -USE_SSL_GNUTLS  -USE_SASL  -USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  -HAVE_LIBIDN2  +HAVE_GETSID  
-USE_HCACHE  
-USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
ISPELL="/usr/bin/ispell"
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/home/vlefevre/share/mutt"
SYSCONFDIR="/home/vlefevre/etc"
EXECSHELL="/home/vlefevre/bin/sh.screen"
-MIXMASTER

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues

patch-20190423.vl.simplesearchkw.1
patch-20190106.pdmef.progress.vl.1
patch-20190423.tamovl.patterns.1
patch-20180503.tamo.iso8601.1
patch-20180503.tamovl.sysdotlock.1

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mutt depends on:
ii  libassuan02.5.2-1
ii  libc6 2.28-10
ii  libcom-err2   1.45.1-1
ii  libgnutls30   3.6.7-2
ii  libgpg-error0 1.35-1
ii  libgpgme111.12.

Bug#928986: CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so:

[Gürkan Myczko]

Indeed, I had noticed so 2 months ago with 2.10.2
https://github.com/CloudCompare/CloudCompare/issues/861

And it was no problem with 2.10.1, back then. Trying to figure out what 
the problem is...

Help is welcome.

Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries

[Thibaut Paumard]

On Fri, 3 May 2019 23:09:33 +0300 Kari Pahula  wrote:
> tags 926182 + patch
> thanks
> 
> Hi.
> 
> /usr/bin/guile uses alternatives system and the real binary is under
> /usr/lib, as well as providing /usr/bin/guile-2.2 as a symlink.
> 
> My patch gives the same treatment for the binaries in guile-2.2-dev.

Dear Kari,

I'm checking your patch, which looks good (compiling guile for testing
takes a lot o time but the patch itself is pretty straightforward and
clean). Do you intend on NMUing this? Given the age of this RC bug, I
think you should.

Regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Bug#927142: Cyrus-Imapd expel from Buster?

[Anthony Prades]

On 5/15/19 4:10 PM, Xavier wrote:
> I can't reproduce this exact issue. After the upgrade process (with
> actual Buster packages), sieve rules are inoperative, but lmtpd won't
> segfault:
>  * Starting with a fresh stretch install, I create mailboxes with and
>without dot in names.
>  * In imapd.conf unixhierarchysep is set to yes and altnamespace to no
>  * I create a vacation rule and check that mails are sent back to the
>sender.
>  * I upgrade to buster.
>  * Then sieve rules will never fire, but lmtpd won't crash.
>
> I haven't got anything special in the logs regarding sieve. Sieve
> scripts are simply ignored.
>
> Then I tested your .postinst script, nothing changes. New sieve scripts
> are also ignored.

Hi,

Do you reproduce on a fresh buster install ?

Anthony

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 14/05/2019 à 11:00, Anthony Prades a écrit :
> Already done... Thank you Xavier.
> 
> Anthony
> 
> On 5/14/19 10:53 AM, Xavier wrote:
>> Le 09/05/2019 à 15:30, Xavier a écrit :
>>> Le 09/05/2019 à 15:13, Anthony Prades a écrit :
 Hi,

 I'll add this patch. We use it in production and it works fine.

 For upgrade steps, what do you think about:
 https://salsa.debian.org/debian/cyrus-imapd/commit/e76b566f92d7153a053f7e03f7c406e64970cb3e

 Anthony
>>> Thanks, that's exactly what I was looking for \o/ !
>>>
>>> Should we consider that this patch can close this bug ? If yes, I'll do
>>> upload+unblock
>> Hello,
>>
>> patch + new postinst seems OK here. I'm ready to push patched version if
>> it's OK for you.
>>
>> Cheers,
>> Xavier

I can't reproduce this exact issue. After the upgrade process (with
actual Buster packages), sieve rules are inoperative, but lmtpd won't
segfault:
 * Starting with a fresh stretch install, I create mailboxes with and
   without dot in names.
 * In imapd.conf unixhierarchysep is set to yes and altnamespace to no
 * I create a vacation rule and check that mails are sent back to the
   sender.
 * I upgrade to buster.
 * Then sieve rules will never fire, but lmtpd won't crash.

I haven't got anything special in the logs regarding sieve. Sieve
scripts are simply ignored.

Then I tested your .postinst script, nothing changes. New sieve scripts
are also ignored.

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 15/05/2019 à 16:13, Anthony Prades a écrit :
> On 5/15/19 4:10 PM, Xavier wrote:
>> I can't reproduce this exact issue. After the upgrade process (with
>> actual Buster packages), sieve rules are inoperative, but lmtpd won't
>> segfault:
>>  * Starting with a fresh stretch install, I create mailboxes with and
>>without dot in names.
>>  * In imapd.conf unixhierarchysep is set to yes and altnamespace to no
>>  * I create a vacation rule and check that mails are sent back to the
>>sender.
>>  * I upgrade to buster.
>>  * Then sieve rules will never fire, but lmtpd won't crash.
>>
>> I haven't got anything special in the logs regarding sieve. Sieve
>> scripts are simply ignored.
>>
>> Then I tested your .postinst script, nothing changes. New sieve scripts
>> are also ignored.
> 
> Hi,
> 
> Do you reproduce on a fresh buster install ?
> 
> Anthony

This is the next try, but we have another problem to solve today
(urgent). We will try tomorrow ;-)

Cheers,
Xavier

Processed: Re: Bug#928717: in normal builds local urresponsive flas are parsed to build process

[Debian Bug Tracking System]

Processing control commands:

> severity 928717 normal
Bug #928717 [src:asterisk] Build link error bundled pjproject : relocation 
against symbol cant be used when shared object
Severity set to 'normal' from 'grave'
> tags 928717 unreproducible
Bug #928717 [src:asterisk] Build link error bundled pjproject : relocation 
against symbol cant be used when shared object
Added tag(s) unreproducible.
> tags 928712 unreproducible
Bug #928712 [src:asterisk] ASTERISK-28409 due enabled deprecated modules
Added tag(s) unreproducible.

-- 
928712: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928712
928717: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928717
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928990: dmarc-cat: attempts internet communication during build

[Antoine Beaupré]

Control: tags -1 +confirmed

On 2019-05-14 20:47:26, Gianfranco Costamagna wrote:
> Hello, as said, the package attempts to do internet communication
> during build... this is forbidden by policy.

Agreed.

I don't know how to handle this in the package build... Maybe I should
just disable the test suite?

Is there a knob (like an environment variable) that I can use to disable
the test suite selectively when building under the buildds?

In another package I maintain (monkeysign), I added an environment
variable that disables network tests in debian/rules, but that turns off
all network tests in the debian package build. Is this the same as what
I should do here?

Are autokgtests allowed to do network requests? Maybe I should just move
the test suite there?

Any help would be greatly welcome.

A.

-- 
Qui vit sans folie n'est pas si sage qu'il croit.
- François de La Rochefoucauld

Processed: Re: Bug#928990: dmarc-cat: attempts internet communication during build

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +confirmed
Bug #928990 [dmarc-cat] dmarc-cat: attempts internet communication during build
Added tag(s) confirmed.

-- 
928990: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928990
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

Hi Michael,

Thank you for sharing your take.

On Sat, May 11, 2019 at 11:21:22AM +0200, Michael Biebl wrote:

Then there is the case, that I sometimes need to use software like
teamviewer (I know, bad proprietary software), which is not Wayland
ready. I need something cross-plattform though, and I'm not aware of
another solution which runs on top of Wayland.


I think we should have some sympathy towards users of non-free software
on top of Debian, even if we aren't packaging it. Pragmatically many of
our users rely on it or want it. E.g. NVIDIA driver users, Google Chrome,
Steam… and IMHO we further our goals if we are sensitive to their needs
rather than making life harder for them.


Incidentally, I was the one responsible for switching back the default
to Xorg in stretch and the main reasons which guided my decision back
then mostly still apply today.


I thought you might have been, I started reading the git log of some
packages to try and figure out what patch would need to be written, I
saw your name in (I think) gdm3 (I haven't yet come up with a working
patch but this gave me some clues thank you)


That said, I'm no longer an active GNOME team member and haven't really
done any GNOME related work during the buster development cycle.


I hadn't realised you were no longer active in the GNOME team. I hope
you are still active in Debian :-) I've always enjoyed interacting with
you (and you may not remember but I think we met at DebConf '07)


And I'm convinced, that the people doing the work should decide.


Mostly agree :-)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 15/05/2019 à 16:17, Xavier a écrit :
> Le 15/05/2019 à 16:13, Anthony Prades a écrit :
>> On 5/15/19 4:10 PM, Xavier wrote:
>>> I can't reproduce this exact issue. After the upgrade process (with
>>> actual Buster packages), sieve rules are inoperative, but lmtpd won't
>>> segfault:
>>>  * Starting with a fresh stretch install, I create mailboxes with and
>>>without dot in names.
>>>  * In imapd.conf unixhierarchysep is set to yes and altnamespace to no
>>>  * I create a vacation rule and check that mails are sent back to the
>>>sender.
>>>  * I upgrade to buster.
>>>  * Then sieve rules will never fire, but lmtpd won't crash.
>>>
>>> I haven't got anything special in the logs regarding sieve. Sieve
>>> scripts are simply ignored.
>>>
>>> Then I tested your .postinst script, nothing changes. New sieve scripts
>>> are also ignored.
>>
>> Hi,
>>
>> Do you reproduce on a fresh buster install ?
>>
>> Anthony
> 
> This is the next try, but we have another problem to solve today
> (urgent). We will try tomorrow ;-)
> 
> Cheers,
> Xavier

Hi all,

I took a look on 3.0.9 changes. All changes are related to bug fixes
(including this one) & documentation except the support of Clamav 0.101.x.
We have Clamav 0.101.2 in Buster! So I think it would be safe to upgrade
Cyrus-Imapd in Buster

@nthykier, do you think I can fill a pre-approval-unblock ? Attached the
diff without doc changes
diff --git a/Makefile.am b/Makefile.am
index df77bbf92..fef9554f0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -121,7 +121,7 @@ EXTRA_DIST = \
 
 if COM_ERR
 COMPILE_ET_DEP = com_err/et/compile_et
-BUILT_SOURCES += com_err/et/compile_et
+BUILT_SOURCES += com_err/et/compile_et com_err/et/libcyrus_com_err.la
 lib_LTLIBRARIES += com_err/et/libcyrus_com_err.la
 endif # COM_ERR
 
@@ -879,6 +879,7 @@ imap_cyr_sphinxmgr_SOURCES = imap/cli_fatal.c imap/cyr_sphinxmgr.c imap/mutex_fa
 imap_cyr_sphinxmgr_LDADD = $(LD_UTILITY_ADD)
 
 imap_cyr_virusscan_SOURCES = imap/cli_fatal.c imap/cyr_virusscan.c imap/mutex_fake.c
+imap_cyr_virusscan_CFLAGS = $(AM_CFLAGS) $(CLAMAV_CFLAGS) $(CFLAG_VISIBILITY)
 imap_cyr_virusscan_LDADD = $(LD_UTILITY_ADD) $(CLAMAV_LIBS)
 
 imap_ctl_zoneinfo_SOURCES = imap/cli_fatal.c imap/ctl_zoneinfo.c imap/mutex_fake.c imap/zoneinfo_db.c
diff --git a/backup/ctl_backups.c b/backup/ctl_backups.c
index cbc37e5b7..77607ca34 100644
--- a/backup/ctl_backups.c
+++ b/backup/ctl_backups.c
@@ -898,6 +898,7 @@ static int lock_run_pipe(const char *userid, const char *fname,
 
 if (r) {
 printf("NO failed (%s)\n", error_message(r));
+r = backup_close(&backup);
 return EC_SOFTWARE; // FIXME would something else be more appropriate?
 }
 
@@ -934,6 +935,7 @@ static int lock_run_sqlite(const char *userid, const char *fname,
 fprintf(stderr, "unable to lock %s: %s\n",
 userid ? userid : fname,
 error_message(r));
+r = backup_close(&backup);
 return EC_SOFTWARE;
 }
 
@@ -994,6 +996,7 @@ static int lock_run_exec(const char *userid, const char *fname,
 fprintf(stderr, "unable to lock %s: %s\n",
 userid ? userid : fname,
 error_message(r));
+r = backup_close(&backup);
 return EC_SOFTWARE;
 }
 
diff --git a/backup/lcb.c b/backup/lcb.c
index f01371283..354d25d21 100644
--- a/backup/lcb.c
+++ b/backup/lcb.c
@@ -182,6 +182,7 @@ HIDDEN int backup_real_open(struct backup **backupp,
 if (r) {
 syslog(LOG_ERR, "IOERROR: (f)stat %s: %m", backup->data_fname);
 r = IMAP_IOERROR;
+close(fd);
 goto error;
 }
 
diff --git a/configure.ac b/configure.ac
index 965b2594f..18049eca5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -112,10 +112,6 @@ AC_ARG_WITH(cyrus-user,
 cyrus_user="$withval",cyrus_user="cyrus")
 AC_SUBST(cyrus_user)
 AC_DEFINE_UNQUOTED(CYRUS_USER, "$cyrus_user",[What user will we run as?])
-AC_ARG_WITH(cyrus-group,
-[AS_HELP_STRING([--with-cyrus-group=GROUPID], [use GROUPID cyrus group])],
-cyrus_group="$withval",cyrus_group="mail")
-AC_SUBST(cyrus_group)
 
 dnl allow users to override $sysconfdir, but retain old default (/etc)
 dnl if not specified
@@ -2254,6 +2250,7 @@ Cyrus Server configured components
calalarmd:  $enable_calalarmd
objectstore:$enable_objectstore
backup: $enable_backup
+   com_err:$with_com_err
 
 External dependencies:
ldap:   $have_ldap
diff --git a/imap/conversations.c b/imap/conversations.c
index 56eccff63..46042e3cb 100644
--- a/imap/conversations.c
+++ b/imap/conversations.c
@@ -1842,7 +1842,6 @@ EXPORTED int conversations_update_record(struct conversations_state *cstate,
 int *delta_counts = NULL;
 int i;
 modseq_t modseq = 0;
-const struct index_record *record = NULL;
 int r = 0;
 
 if (old && new) {
@@ -1864,21 +1863,15 @@ EXPORTED int conversations_update_record(struct conversations_st

Processed: Re: Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed  929007 3.20190514.1~
Bug #929007 {Done: Markus Schade } [intel-microcode] 
intel-microcode: Update intel-microcode to 20190514
There is no source info for the package 'intel-microcode' at version 
'3.20190514.1~' with architecture ''
Unable to make a source version for version '3.20190514.1~'
Marked as fixed in versions 3.20190514.1~.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929007: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929007
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#927142: [pre-approval] unblock: cyrus-imapd/3.0.9-1

[Xavier]

Le 15/05/2019 à 19:32, Xavier Guimard a écrit :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package cyrus-imapd
> 
> Hi all,
> 
> Buster has currently cyrus-imapd 3.0.8. Upstram last version is 3.0.9.
> This version has one new little feature:
>  "The new ``cyrus_group`` option in :cyrusman:`imapd.conf(5)` can be used to
>   set the UNIX group that Cyrus processes run as (thanks Jakob Gahde).  The
>   default is to use the primary group of the configured ``cyrus_user``.  The
>   old ``--with-cyrus-group`` configure option has been non-functional for many
>   years, and has been removed."
> 
> and fixes many bugs
>  - LMTP segfault (RC bug #927142)
>  - some memory leaks
>  - mailboxes with space in name
>  - idle sockets
>  - UTF problems
> 
> It add also Clamav 0.101.x support.
> 
> Since Buster has Clamav 0.101.2 and Cyrus-Imapd has no reverse dependencies,
> I think it would be a good thing to upgrate cyrus-imapd instead of
> backporting the majority of these changes.
> 
> Diff contains also many documentation updates that have no consequences
> on upgrade.
> 
> Cheers,
> Xavier
> 
> unblock cyrus-imapd/3.0.9-1

Sorry, it was a bad idea: upstream changed also some things in their
archive build and diff is now too large (2 lines).

Also we have already patches for clamav.

Bug#929034: evolvotron: Evolvotron can't stat (segmentation fault)

[Saverio Brancaccio]

Package: evolvotron
Version: 0.7.1-2+b1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evolvotron depends on:
ii  libboost-program-options1.67.0  1.67.0-13
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.1.0-1
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libqt5xml5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-6

evolvotron recommends no packages.

evolvotron suggests no packages.

-- no debconf information

log:
Application: evolvotron (evolvotron), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f818567e780 (LWP 5480))]

Thread 6 (Thread 0x7f8167fff700 (LWP 5489)):
#0  0x7f81889ae00c in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f8178f6f65b in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#2  0x7f8178f6f4d7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#3  0x7f81889a7fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#4  0x7f81885214cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 5 (Thread 0x7f8178d5f700 (LWP 5487)):
#0  0x7f81889ae00c in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f8178f6f65b in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#2  0x7f8178f6f4d7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#3  0x7f81889a7fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#4  0x7f81885214cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x7f817a88b700 (LWP 5486)):
#0  0x7f818851bf59 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f8188a76a35 in QBasicMutex::lockInternal() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x5581d1e677b1 in ?? ()
#3  0x5581d1e79527 in ?? ()
#4  0x7f8188a83aa7 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f81889a7fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f81885214cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 3 (Thread 0x7f817b08c700 (LWP 5485)):
#0  0x7f818851bf59 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f8188a76a35 in QBasicMutex::lockInternal() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x5581d1e677b1 in ?? ()
#3  0x5581d1e79527 in ?? ()
#4  0x7f8188a83aa7 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f81889a7fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f81885214cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7f8180ad1700 (LWP 5482)):
#0  0x7f8188516819 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f8187ab6136 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f8187ab625c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f8188c7c87b in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7f8188c2a27b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f8188a79ec6 in QThread::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7f818512f545 in ?? () from /lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7f8188a83aa7 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7f81889a7fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7f81885214cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f818567e780 (LWP 5480)):
[KCrash Handler]
#6  0x5581d1e66fb1 in ?? ()
#7  0x5581d1e6a49d in ?? ()
#8  0x5581d1e6b53e in ?? ()
#9  0x7f8189623588 in QWidget::event(QEvent*) () from 
/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x7f81895e54b1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x7f81895ec950 in QApplication::notify(

Bug#929042: singularity-container: CVE-2019-11328

[Salvatore Bonaccorso]

Source: singularity-container
Version: 3.1.1+ds-1
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for singularity-container.

CVE-2019-11328[0]:
| An issue was discovered in Singularity 3.1.0 to 3.2.0-rc2, a malicious
| user with local/network access to the host system (e.g. ssh) could
| exploit this vulnerability due to insecure permissions allowing a user
| to edit files within
| `/run/singularity/instances/sing//`. The
| manipulation of those files can change the behavior of the starter-
| suid program when instances are joined resulting in potential
| privilege escalation on the host.

Could you furthermore check, is this only introduced in the 3.1.0
series really or just are those the versions checked for the issue,
but earlier versions might be affected as well?

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11328
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11328

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#929042: marked as done (singularity-container: CVE-2019-11328)

[Debian Bug Tracking System]

Your message dated Wed, 15 May 2019 16:51:24 -0400
with message-id <485aede8-7653-49da-97ec-be9fd454b...@debian.org>
and subject line Re: Bug#929042: singularity-container: CVE-2019-11328
has caused the Debian Bug report #929042,
regarding singularity-container: CVE-2019-11328
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
929042: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929042
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: singularity-container
Version: 3.1.1+ds-1
Severity: grave
Tags: security upstream

Hi,

The following vulnerability was published for singularity-container.

CVE-2019-11328[0]:
| An issue was discovered in Singularity 3.1.0 to 3.2.0-rc2, a malicious
| user with local/network access to the host system (e.g. ssh) could
| exploit this vulnerability due to insecure permissions allowing a user
| to edit files within
| `/run/singularity/instances/sing//`. The
| manipulation of those files can change the behavior of the starter-
| suid program when instances are joined resulting in potential
| privilege escalation on the host.

Could you furthermore check, is this only introduced in the 3.1.0
series really or just are those the versions checked for the issue,
but earlier versions might be affected as well?

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11328
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11328

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Control: notfound -1 3.1.1+ds-1

Hi,

On May 15, 2019 4:29:54 PM EDT, Salvatore Bonaccorso  wrote:
>Source: singularity-container
>Version: 3.1.1+ds-1
>Severity: grave
>Tags: security upstream
>
>Hi,
>
>The following vulnerability was published for singularity-container.
>
>CVE-2019-11328[0]:
>| An issue was discovered in Singularity 3.1.0 to 3.2.0-rc2, a
>malicious
>| user with local/network access to the host system (e.g. ssh) could
>| exploit this vulnerability due to insecure permissions allowing a
>user
>| to edit files within
>| `/run/singularity/instances/sing//`. The
>| manipulation of those files can change the behavior of the starter-
>| suid program when instances are joined resulting in potential
>| privilege escalation on the host.
>

The version I uploaded yesterday includes the patches for this CVE.

>Could you furthermore check, is this only introduced in the 3.1.0
>series really or just are those the versions checked for the issue,
>but earlier versions might be affected as well?
>

I filed an unblock request to hopefully replace 3.0.3 in Testing. 2.6.1 doesn't 
have the affected code (it predates the Go implementation).


>If you fix the vulnerability please also make sure to include the
>CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>

I did this already.

>For further information see:
>
>[0] https://security-tracker.debian.org/tracker/CVE-2019-11328
>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11328
>
>Please adjust the affected versions in the BTS as needed.
>

regards
Afif--- End Message ---

Bug#929042: closed by Afif Elghraoui (Re: Bug#929042: singularity-container: CVE-2019-11328)

[Salvatore Bonaccorso]

Hi Afif,

On Wed, May 15, 2019 at 08:54:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:singularity-container package:
> 
> #929042: singularity-container: CVE-2019-11328
> 
> It has been closed by Afif Elghraoui .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Afif Elghraoui 
>  by
> replying to this email.
> 
> 
> -- 
> 929042: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929042
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Wed, 15 May 2019 16:51:24 -0400
> From: Afif Elghraoui 
> To: 929042-d...@bugs.debian.org
> Subject: Re: Bug#929042: singularity-container: CVE-2019-11328
> User-Agent: K-9 Mail for Android
> Message-ID: <485aede8-7653-49da-97ec-be9fd454b...@debian.org>
> 
> Control: notfound -1 3.1.1+ds-1
> 
> Hi,
> 
> On May 15, 2019 4:29:54 PM EDT, Salvatore Bonaccorso  
> wrote:
> >Source: singularity-container
> >Version: 3.1.1+ds-1
> >Severity: grave
> >Tags: security upstream
> >
> >Hi,
> >
> >The following vulnerability was published for singularity-container.
> >
> >CVE-2019-11328[0]:
> >| An issue was discovered in Singularity 3.1.0 to 3.2.0-rc2, a
> >malicious
> >| user with local/network access to the host system (e.g. ssh) could
> >| exploit this vulnerability due to insecure permissions allowing a
> >user
> >| to edit files within
> >| `/run/singularity/instances/sing//`. The
> >| manipulation of those files can change the behavior of the starter-
> >| suid program when instances are joined resulting in potential
> >| privilege escalation on the host.
> >
> 
> The version I uploaded yesterday includes the patches for this CVE.

Thanks saw that, and fixed the security-tracker information.

> >Could you furthermore check, is this only introduced in the 3.1.0
> >series really or just are those the versions checked for the issue,
> >but earlier versions might be affected as well?
> >
> 
> I filed an unblock request to hopefully replace 3.0.3 in Testing. 2.6.1 
> doesn't have the affected code (it predates the Go implementation).

Thanks that was important bit to know.

Then there is nothing further to be done.

Regards,
Salvatore

Processed: notfound 929042 in 3.1.1+ds-1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> notfound 929042 3.1.1+ds-1
Bug #929042 {Done: Afif Elghraoui } 
[src:singularity-container] singularity-container: CVE-2019-11328
No longer marked as found in versions singularity-container/3.1.1+ds-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929042: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929042
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 929034

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 929034 + confirmed
Bug #929034 [evolvotron] evolvotron: Evolvotron can't stat (segmentation fault)
Added tag(s) confirmed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929034
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#929042: closed by Afif Elghraoui (Re: Bug#929042: singularity-container: CVE-2019-11328)

[Salvatore Bonaccorso]

Hi Afif,

On Wed, May 15, 2019 at 10:57:49PM +0200, Salvatore Bonaccorso wrote:
> Then there is nothing further to be done.

Oh, actually there is an open point: Is it confirmed that 3.0.3 is not
affected by the CVE? Did you got any information why this is only
introduced in 3.1.0?

Regards,
Salvatore

Bug#929034: evolvotron: Evolvotron can't stat (segmentation fault)

[Axel Beckert]

Hi,

thanks for the bug report.

Saverio Brancaccio wrote:
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?

Please answer at least these two questions next time. Anyways, I can
reproduce this issue, at least sometimes.

> Application: evolvotron (evolvotron), signal: Segmentation fault
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [Current thread is 1 (Thread 0x7f818567e780 (LWP 5480))]
[...]
> Thread 1 (Thread 0x7f818567e780 (LWP 5480)):
> [KCrash Handler]
> #6  0x5581d1e66fb1 in ?? ()
> #7  0x5581d1e6a49d in ?? ()
> #8  0x5581d1e6b53e in ?? ()
> #9  0x7f8189623588 in QWidget::event(QEvent*) () from 
> /lib/x86_64-linux-gnu/libQt5Widgets.so.5

The backtrace is missing quite some symbols, so I installed all
relevant debug symbols packages, started evolvotron in gdb to get a
full backtrace, and then it no more crashed and started up without
issues. "Luckily" it didn't do that all times I tried that, so in the
third or fourth try, I did get a full backtrace:

→ gdb evolvotron
GNU gdb (Debian 8.2.1-2) 8.2.1
[…]
Reading symbols from evolvotron...Reading symbols from 
/usr/lib/debug/.build-id/aa/9b59c5e413cdcfcb78b68c2c3dccc04ebaddba.debug...done.
done.
(gdb) r
Starting program: /usr/bin/evolvotron
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x71f58700 (LWP 12844)]
qt5ct: using qt5ct plugin
[New Thread 0x71152700 (LWP 12845)]
qt5ct: D-Bus global menu: no
[New Thread 0x70951700 (LWP 12846)]
[New Thread 0x7fffebfff700 (LWP 12847)]
[New Thread 0x7fffea643700 (LWP 12848)]

Thread 1 "evolvotron" received signal SIGSEGV, Segmentation fault.
MutatableImageComputerFarm::abort_for (this=0x55956640, 
disp=disp@entry=0x55865bf0)
at mutatable_image_computer_task.h:148
148 mutatable_image_computer_task.h: No such file or directory.
(gdb) bt
#0  MutatableImageComputerFarm::abort_for (this=0x55956640, 
disp=disp@entry=0x55865bf0) at mutatable_image_computer_task.h:148
#1  0x555a849d in MutatableImageDisplay::image_function 
(this=0x55865bf0, i=..., one_of_many=false) at 
mutatable_image_display.cpp:237
#2  0x555a953e in MutatableImageDisplay::paintEvent 
(this=0x55865bf0) at mutatable_image_display.cpp:467
#3  0x77829588 in QWidget::event (this=0x55865bf0, 
event=0x7fffa810) at kernel/qwidget.cpp:8925
#4  0x777eb4b1 in QApplicationPrivate::notify_helper 
(this=this@entry=0x55682a20, receiver=receiver@entry=0x55865bf0, 
e=e@entry=0x7fffa810) at kernel/qapplication.cpp:3726
#5  0x777f2950 in QApplication::notify (this=0x7fffd790, 
receiver=0x55865bf0, e=0x7fffa810) at kernel/qapplication.cpp:3485
#6  0x76e315a9 in QCoreApplication::notifyInternal2 
(receiver=receiver@entry=0x55865bf0, event=event@entry=0x7fffa810) at 
../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
#7  0x7782215a in QCoreApplication::sendSpontaneousEvent 
(event=0x7fffa810, receiver=0x55865bf0) at 
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
#8  QWidgetPrivate::sendPaintEvent (this=this@entry=0x55aa8990, 
toBePainted=...) at kernel/qwidget.cpp:5683
#9  0x77822a17 in QWidgetPrivate::drawWidget (this=0x55aa8990, 
pdev=0x55ef6080, rgn=..., offset=..., flags=4, sharedPainter=, backingStore=) at kernel/qwidget.cpp:5623
#10 0x77823611 in QWidgetPrivate::paintSiblingsRecursive 
(this=0x55a5b750, pdev=0x55ef6080, siblings=..., index=, 
rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x55ce1cb0) 
at ../../include/QtCore/../../src/corelib/tools/qpoint.h:122
#11 0x77823500 in QWidgetPrivate::paintSiblingsRecursive 
(this=0x55a5b750, pdev=0x55ef6080, siblings=..., index=, 
rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x55ce1cb0) 
at kernel/qwidget.cpp:5804
#12 0x77823500 in QWidgetPrivate::paintSiblingsRecursive 
(this=0x55a5b750, pdev=0x55ef6080, siblings=..., index=, 
rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x55ce1cb0) 
at kernel/qwidget.cpp:5804
#13 0x77823500 in QWidgetPrivate::paintSiblingsRecursive 
(this=0x55a5b750, pdev=0x55ef6080, siblings=..., index=, 
rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x55ce1cb0) 
at kernel/qwidget.cpp:5804
#14 0x77823500 in QWidgetPrivate::paintSiblingsRecursive 
(this=0x55a5b750, pdev=0x55ef6080, siblings=..., index=, 
rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x55ce1cb0) 
at kernel/qwidget.cpp:5804
#15 0x77823500 in QWidgetPrivate::paintSiblingsRecursive 
(this=0x55a5b750, pdev=0x55ef6080, siblings=..., 

Bug#928986: CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so:

[Bernhard Übelacker]

Dear Maintainer,
I just tried to have a look and might found something.


As far as I see ldd searches the shared objects based on the RPATH in
the executable:

benutzer@debian:~$ ldd /usr/bin/CloudCompare | grep "not found"
libQCC_IO_LIB.so => not found
libQCC_DB_LIB.so => not found
libCC_CORE_LIB.so => not found

benutzer@debian:~$ chrpath /usr/bin/CloudCompare 
/usr/bin/CloudCompare: RUNPATH=lib/x86_64-linux-gnu/cloudcompare


I tried to find a similar situation in another binary and found paplay:

benutzer@debian:~$ chrpath -l /usr/bin/paplay
/usr/bin/paplay: RUNPATH=/usr/lib/x86_64-linux-gnu/pulseaudio


So I guess this relative path in CloudCompare seems to be the issue.
This seems to be set when installed to the packaging directory [1]:

-- Installing: /<>/debian/cloudcompare/usr/bin/CloudCompare
-- Set runtime path of 
"/<>/debian/cloudcompare/usr/bin/CloudCompare" to 
"lib/x86_64-linux-gnu/cloudcompare"
-- Installing: 
/<>/debian/cloudcompare/usr/share/cloudcompare/CHANGELOG.md


I found this file in which CMAKE_INSTALL_RPATH gets set:
./CMakeLists.txt:34:set(CMAKE_INSTALL_RPATH 
"${CMAKE_INSTALL_LIBDIR}/cloudcompare")

As far as I see CMAKE_INSTALL_LIBDIR is given by dh_auto_configure
and therefore may be meant to be a relative path.


Therefore I searched other examples of setting CMAKE_INSTALL_RPATH
and found that a package built with following change at least
shows no longer an error in ldd.

+++ cloudcompare-2.10.1/CMakeLists.txt
-   set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_LIBDIR}/cloudcompare")
+   set(CMAKE_INSTALL_RPATH 
"${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}/cloudcompare")


Kind regards,
Bernhard

[1] 
https://buildd.debian.org/status/fetch.php?pkg=cloudcompare&arch=amd64&ver=2.10.1-1&stamp=1547783795&raw=0
Description: Modify CMAKE_INSTALL_RPATH to have an absolute path
Author: Bernhard Übelacker 
Bug: https://github.com/CloudCompare/CloudCompare/issues/861
Bug-Debian: https://bugs.debian.org/928986
Forwarded: no
Last-Update: 2019-05-15

--- cloudcompare-2.10.1.orig/CMakeLists.txt
+++ cloudcompare-2.10.1/CMakeLists.txt
@@ -31,7 +31,7 @@ if( UNIX AND NOT APPLE )
 	if( NOT CMAKE_INSTALL_LIBDIR )
 		set( CMAKE_INSTALL_LIBDIR ${CMAKE_INSTALL_PREFIX}/lib CACHE PATH "CloudCompare lib dir" )
 	endif( NOT CMAKE_INSTALL_LIBDIR )
-	set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_LIBDIR}/cloudcompare")
+	set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}/cloudcompare")
 endif()
 
 # CCViewer

Processed: retitle 929034 to evolvotron: Segfaults most of the time (ca. 80%) at startup

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 929034 evolvotron: Segfaults most of the time (ca. 80%) at startup
Bug #929034 [evolvotron] evolvotron: Evolvotron can't stat (segmentation fault)
Changed Bug title to 'evolvotron: Segfaults most of the time (ca. 80%) at 
startup' from 'evolvotron: Evolvotron can't stat (segmentation fault)'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929034
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928726: marked as done (json: CVE-2019-11834 CVE-2019-11835)

[Debian Bug Tracking System]

Your message dated Thu, 16 May 2019 01:03:36 +
with message-id 
and subject line Bug#928726: fixed in cjson 1.7.10-1.1
has caused the Debian Bug report #928726,
regarding json: CVE-2019-11834 CVE-2019-11835
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928726
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: cjson
Version: 1.7.10-1
Severity: grave
Tags: security upstream fixed-upstream

Hi,

The following vulnerabilities were published for cjson.

CVE-2019-11834[0]:
| cJSON before 1.7.11 allows out-of-bounds access, related to \x00 in a
| string literal.


CVE-2019-11835[1]:
| cJSON before 1.7.11 allows out-of-bounds access, related to multiline
| comments.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11834
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11834
https://github.com/DaveGamble/cJSON/issues/337
[1] https://security-tracker.debian.org/tracker/CVE-2019-11835
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11835
https://github.com/DaveGamble/cJSON/issues/338

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: cjson
Source-Version: 1.7.10-1.1

We believe that the bug you reported is fixed in the latest version of
cjson, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gordon Ball  (supplier of updated cjson package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 14 May 2019 08:52:20 +
Source: cjson
Binary: libcjson-dev libcjson1 libcjson1-dbgsym
Architecture: source amd64
Version: 1.7.10-1.1
Distribution: unstable
Urgency: medium
Maintainer: Yanhao Mo 
Changed-By: Gordon Ball 
Description:
 libcjson-dev - Ultralightweight JSON parser in ANSI C (development files)
 libcjson1  - Ultralightweight JSON parser in ANSI C
Closes: 928726
Changes:
 cjson (1.7.10-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Cherry pick upstream commit a43fa56a63920343d0ac8f8e73a6b0447867f459,
 which contains fixes for CVEs (Closes: #928726)
 + CVE-2019-11834
 + CVE-2019-11835
Checksums-Sha1:
 e318dff02d0c4c087e04b7d78d12e703a4f53657 1910 cjson_1.7.10-1.1.dsc
 c0ff23a085e66de4eb04970d0859985db8c68916 5424 cjson_1.7.10-1.1.debian.tar.xz
 1cc270b31b9e41845e657e6dfcb05060900a261c 6791 cjson_1.7.10-1.1_amd64.buildinfo
 1c16c35727c2c876083ba2929a180b4f43ff367f 22156 
libcjson-dev_1.7.10-1.1_amd64.deb
 5e1b27bda1363c1ab8d1efb320602e91df2140ff 30576 
libcjson1-dbgsym_1.7.10-1.1_amd64.deb
 039383eb0827622458036ff3d08120fe9526141a 20552 libcjson1_1.7.10-1.1_amd64.deb
Checksums-Sha256:
 b1817b30c0992441065d838d1e3c35ea2b6cca4c7b70a4f16511ab623d38ab2f 1910 
cjson_1.7.10-1.1.dsc
 81d5ca5e56d0e1427bb643d7334696c1a0621dc40ececde79dfd6676bf3aed06 5424 
cjson_1.7.10-1.1.debian.tar.xz
 7fbe2dfdfd6f82cd8664795f133686224c5d2ca0adf3caaddcf05e071939c582 6791 
cjson_1.7.10-1.1_amd64.buildinfo
 688837012daa563932fdb22ebe14917f40c67904c2f7eacc6f824a9f8330bca1 22156 
libcjson-dev_1.7.10-1.1_amd64.deb
 2f422dafb966d2d347a89d5746977c88bdce15b27336c81a790a4e22fb0721d9 30576 
libcjson1-dbgsym_1.7.10-1.1_amd64.deb
 d41ba630a26f1bd33eb4ed63e841d95ebfdf8182e9297f5f0d44e61becf05f5a 20552 
libcjson1_1.7.10-1.1_amd64.deb
Files:
 d1a19ba45aa9c1e6c582bbb2113b 1910 libs optional cjson_1.7.10-1.1.dsc
 4cabfba60e9bbec2dcae53895383b1e9 5424 libs optional 
cjson_1.7.10-1.1.debian.tar.xz
 543c5170f0a9e1b16df994d1d5e68e82 6791 libs optional 
cjson_1.7.10-1.1_amd64.buildinfo
 cd34a8e0ae8e0bebb2f57385588c3462 22156 libdevel optional 
libcjson-dev_1.7.10-1.1_amd64.deb
 5246380ebd95acdb59f1972c696639cf 30576 debug optional 
libcjson1-dbgsym_1.7.10-1.1_amd64.deb
 bd6332f2a5fb1c0592dcf1ae1bffb289 20552 libs optional 
libcjson1_1.7.10-1.1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEEb9bJQfCTGv6uM2+ujv2XAviIsq4FAlzcsWITHHlhbmhhb2Nz
QGdtYWlsLmNvbQAKCRCO/ZcC+Iiyrt4

Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries

[Rob Browning]

Thibaut Paumard  writes:

> I'm checking your patch, which looks good (compiling guile for testing
> takes a lot o time but the patch itself is pretty straightforward and
> clean). Do you intend on NMUing this? Given the age of this RC bug, I
> think you should.

I'm not certain, but I'm planning to work on guile over the next week.
If so, I should be able to take a look.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#929048: tracker-extract: Allocates between 5 and 10 GiB of memory when examining certain DDS files

[Bálint Kovács]

Two more things:

1. I have a few more samples in both categories, if needed

2. I do realize that this bears resemblance to #679581. However, there the 
offending process was different.

On 16 May 2019 01:42:44 BST, "Bálint Kovács"  wrote:
>Package: tracker-extract
>Version: 2.1.6-1
>Severity: critical
>Justification: breaks the whole system
>
>Dear Maintainer,
>
>   * What led up to the situation?
>I have been extracting resources from a game. When I extracted a
>handful of DDS
>files, my memory usage shot up and in about 5 seconds the entire system
>locked
>up, no moving to virtual consoles, no nothing. This kept happening,
>every time
>I logged into my profile. To investigate I killed all tracker-related
>processes.
>
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>I have been able to identify that the misbehaving process is
>tracker-extract. I
>started running tracker-extract with an rlimit on the DDS files.
>
>   * What was the outcome of this action?
>Some files worked fine, some failed under an RLIMIT_AS of 5 GiB but not
>under
>an RLIMIT_AS of 10 GiB (but it still allocated a not insignificant
>amount of
>memory)
>
>Full output from an affected file:
>
>$ /usr/lib/tracker/tracker-extract -v 2 -f bad.dds
>00:57
>** Message: 00:57:52.901: Starting tracker-extract 2.1.6
>** Message: 00:57:52.901: General options:
>** Message: 00:57:52.901:   Verbosity    2
>** Message: 00:57:52.901:   Sched Idle  ...  1
>** Message: 00:57:52.901:   Max bytes (per file)  . 
>1048576
>(tracker-extract:9171): dconf-DEBUG: 00:57:52.901: watch_established:
>"/org/freedesktop/tracker/extract/" (establishing: 1)
>Setting scheduler policy to SCHED_IDLE
>Setting priority nice level to 19
>Loading extractor rules... (/usr/share/tracker-miners/extract-rules)
>Extractor rules loaded
>MIME type guessed as 'image/x-dds' (from GIO)
>../../../glib/gmem.c:105: failed to allocate 65687 bytes
>
>   * What outcome did you expect instead?
>Full output from an unaffected file:
>
>$ /usr/lib/tracker/tracker-extract -v 2 -f good.dds
>00:57
>** Message: 00:57:46.382: Starting tracker-extract 2.1.6
>** Message: 00:57:46.382: General options:
>** Message: 00:57:46.382:   Verbosity    2
>** Message: 00:57:46.382:   Sched Idle  ...  1
>** Message: 00:57:46.382:   Max bytes (per file)  . 
>1048576
>(tracker-extract:9113): dconf-DEBUG: 00:57:46.382: watch_established:
>"/org/freedesktop/tracker/extract/" (establishing: 1)
>Setting scheduler policy to SCHED_IDLE
>Setting priority nice level to 19
>Loading extractor rules... (/usr/share/tracker-miners/extract-rules)
>Extractor rules loaded
>MIME type guessed as 'image/x-dds' (from GIO)
>@prefix rdf:  .
>@prefix nmm:  .
>@prefix nfo:
> .
>
> a nfo:Image ,
>nmm:Photo .
>
>   * Other information
>All of the files work with imagemagick display perfectly well, they are
>even
>the same resolution.
>
>To remedy the situation, I have deleted all affected DDS files, but I
>have kept
>a tarball of an affected and an unaffected sample (along with one that
>is not
>recognized for some reason.) I have attached it to my report. Handle
>with care,
>especially if you have a desktop with tracker on it.
>
>-- System Information:
>Debian Release: buster/sid
>  APT prefers testing
>APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
>Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>LANGUAGE=en_US:en (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages tracker-extract depends on:
>ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
>ii  libc62.28-10
>ii  libcue2  2.2.1-2
>ii  libexempi8   2.5.0-2
>ii  libexif120.6.21-5.1
>ii  libflac8 1.3.2-3
>ii  libgexiv2-2  0.10.9-1
>ii  libgif7  5.1.4-3
>ii  libglib2.0-0 2.58.3-1
>ii  libgsf-1-114 1.14.45-1
>ii  libgstreamer-plugins-base1.0-0   1.14.4-1
>ii  libgstreamer1.0-01.14.4-1
>ii  libgxps2 0.3.1-1
>ii  libicu63 63.1-6
>ii  libiptcdata0 1.0.5-2.1
>ii  libjpeg62-turbo  1:1.5.2-2+b1
>ii  libos

Bug#756492: marked as done (system-config-printer-kde: Authentication Dialog cannot receive focus)

[Debian Bug Tracking System]

Your message dated Thu, 16 May 2019 05:45:51 +0200
with message-id 
and subject line system-config-printer-kde has been removed from Debian
has caused the Debian Bug report #756492,
regarding system-config-printer-kde: Authentication Dialog cannot receive focus
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
756492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756492
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: system-config-printer-kde
Severity: grave
Justification: renders package unusable

When configuring an existing printer through the printer KCM module (as normal
user), authentication is not possible when clicking Configure, makig changes
there, and pressing Apply. The authentication dialog pops up, but cannot
receive focus.

When the authentication dialog pops up as a result of checking the 'Default
Printer' or 'Reject Print Jobs' checkbox, the authentication dialog is able to
receive focus, and these settings seems to apply after auth.

So it is likely due to two modal dialogs competing for focus



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (750, 'testing'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- End Message ---
--- Begin Message ---
Version: 4:4.10.2-1

system-config-printer-kde was last released with Debian 7.0 (wheezy) in
May 2013 and has been dropped upstream in KDE 4.10, therefore it was
removed from the Debian archive afterwards.
Since support for wheezy and wheezy-LTS has now ended and the suites
have been archived, I'm closing all the remaining bugs reported against
this package.


Andreas--- End Message ---

Processed: found 929007 in intel-microcode/0.20080131-1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 929007 intel-microcode/0.20080131-1
Bug #929007 {Done: Markus Schade } [intel-microcode] 
intel-microcode: Update intel-microcode to 20190514
Marked as found in versions intel-microcode/0.20080131-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929007: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929007
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: fixed 929007 in intel-microcode/3.20190514.1~

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed 929007 intel-microcode/3.20190514.1~
Bug #929007 {Done: Markus Schade } [intel-microcode] 
intel-microcode: Update intel-microcode to 20190514
The source intel-microcode and version 3.20190514.1~ do not appear to match any 
binary packages
Marked as fixed in versions intel-microcode/3.20190514.1~.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
929007: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929007
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#924509: Regd: CVE-2016-9840 CVE-2016-9841 CVE-2016-9842 CVE-2016-9843

[Gunjan Gupta]

Hi Paul,

The changelog of the latest rsync package available in stretch does say
that these are fixed, but I can still see that stretch is shown as
vulnerable on the security tracker.

https://security-tracker.debian.org/tracker/CVE-2016-9840

If these are fixed, could you please get the security tracker updated?

Thanks & Regards
Gunjan Gupta

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 15/05/2019 à 16:17, Xavier a écrit :
> Le 15/05/2019 à 16:13, Anthony Prades a écrit :
>> On 5/15/19 4:10 PM, Xavier wrote:
>>> I can't reproduce this exact issue. After the upgrade process (with
>>> actual Buster packages), sieve rules are inoperative, but lmtpd won't
>>> segfault:
>>>  * Starting with a fresh stretch install, I create mailboxes with and
>>>without dot in names.
>>>  * In imapd.conf unixhierarchysep is set to yes and altnamespace to no
>>>  * I create a vacation rule and check that mails are sent back to the
>>>sender.
>>>  * I upgrade to buster.
>>>  * Then sieve rules will never fire, but lmtpd won't crash.
>>>
>>> I haven't got anything special in the logs regarding sieve. Sieve
>>> scripts are simply ignored.
>>>
>>> Then I tested your .postinst script, nothing changes. New sieve scripts
>>> are also ignored.
>>
>> Hi,
>>
>> Do you reproduce on a fresh buster install ?
>>
>> Anthony
> 
> This is the next try, but we have another problem to solve today
> (urgent). We will try tomorrow ;-)
> 
> Cheers,
> Xavier

Only vacation scripts fails here. So in resume:
 - unable to reproduce this issue, but upstream commits show that this
   bug exists and is fixed by the 0020 patch
 - postinst script works (with a little fix, see my commits)
 - sieve works, only vacation script are not understood here (maybe a
   syntax change? We are waiting for upstream response here)

Bug#929034: evolvotron: Evolvotron can't stat (segmentation fault)

[Saverio Brancaccio]

Hi Axel,

considering that Evolvotron (the version in subject) was working before, it
seems that the cause of the bug is related to some library like Qt5 or
Boost that has been updated, so the application can't find the correct
calls downside, leading to segmentation fault...

Is there any possibility to fix the bug considering some change in the
building configuration (pointing to the wanted version of Qt5 or Boost) and
recompile again Evolvotron from sources?

Many thanks in advance for the attention and the information you can
provide.


Il mer 15 mag 2019, 23:32 Axel Beckert  ha scritto:

> Hi,
>
> thanks for the bug report.
>
> Saverio Brancaccio wrote:
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> >* What led up to the situation?
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
>
> Please answer at least these two questions next time. Anyways, I can
> reproduce this issue, at least sometimes.
>
> > Application: evolvotron (evolvotron), signal: Segmentation fault
> > Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > [Current thread is 1 (Thread 0x7f818567e780 (LWP 5480))]
> [...]
> > Thread 1 (Thread 0x7f818567e780 (LWP 5480)):
> > [KCrash Handler]
> > #6  0x5581d1e66fb1 in ?? ()
> > #7  0x5581d1e6a49d in ?? ()
> > #8  0x5581d1e6b53e in ?? ()
> > #9  0x7f8189623588 in QWidget::event(QEvent*) () from
> /lib/x86_64-linux-gnu/libQt5Widgets.so.5
>
> The backtrace is missing quite some symbols, so I installed all
> relevant debug symbols packages, started evolvotron in gdb to get a
> full backtrace, and then it no more crashed and started up without
> issues. "Luckily" it didn't do that all times I tried that, so in the
> third or fourth try, I did get a full backtrace:
>
> → gdb evolvotron
> GNU gdb (Debian 8.2.1-2) 8.2.1
> […]
> Reading symbols from evolvotron...Reading symbols from
> /usr/lib/debug/.build-id/aa/9b59c5e413cdcfcb78b68c2c3dccc04ebaddba.debug...done.
> done.
> (gdb) r
> Starting program: /usr/bin/evolvotron
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x71f58700 (LWP 12844)]
> qt5ct: using qt5ct plugin
> [New Thread 0x71152700 (LWP 12845)]
> qt5ct: D-Bus global menu: no
> [New Thread 0x70951700 (LWP 12846)]
> [New Thread 0x7fffebfff700 (LWP 12847)]
> [New Thread 0x7fffea643700 (LWP 12848)]
>
> Thread 1 "evolvotron" received signal SIGSEGV, Segmentation fault.
> MutatableImageComputerFarm::abort_for (this=0x55956640, disp=disp@entry
> =0x55865bf0)
> at mutatable_image_computer_task.h:148
> 148 mutatable_image_computer_task.h: No such file or directory.
> (gdb) bt
> #0  MutatableImageComputerFarm::abort_for (this=0x55956640,
> disp=disp@entry=0x55865bf0) at mutatable_image_computer_task.h:148
> #1  0x555a849d in MutatableImageDisplay::image_function
> (this=0x55865bf0, i=..., one_of_many=false) at
> mutatable_image_display.cpp:237
> #2  0x555a953e in MutatableImageDisplay::paintEvent
> (this=0x55865bf0) at mutatable_image_display.cpp:467
> #3  0x77829588 in QWidget::event (this=0x55865bf0,
> event=0x7fffa810) at kernel/qwidget.cpp:8925
> #4  0x777eb4b1 in QApplicationPrivate::notify_helper
> (this=this@entry=0x55682a20, receiver=receiver@entry=0x55865bf0,
> e=e@entry=0x7fffa810) at kernel/qapplication.cpp:3726
> #5  0x777f2950 in QApplication::notify (this=0x7fffd790,
> receiver=0x55865bf0, e=0x7fffa810) at kernel/qapplication.cpp:3485
> #6  0x76e315a9 in QCoreApplication::notifyInternal2
> (receiver=receiver@entry=0x55865bf0, event=event@entry=0x7fffa810)
> at
> ../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
> #7  0x7782215a in QCoreApplication::sendSpontaneousEvent
> (event=0x7fffa810, receiver=0x55865bf0) at
> ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237
> #8  QWidgetPrivate::sendPaintEvent (this=this@entry=0x55aa8990,
> toBePainted=...) at kernel/qwidget.cpp:5683
> #9  0x77822a17 in QWidgetPrivate::drawWidget (this=0x55aa8990,
> pdev=0x55ef6080, rgn=..., offset=..., flags=4, sharedPainter= out>, backingStore=) at kernel/qwidget.cpp:5623
> #10 0x77823611 in QWidgetPrivate::paintSiblingsRecursive
> (this=0x55a5b750, pdev=0x55ef6080, siblings=..., index= out>, rgn=..., offset=..., flags=4, sharedPainter=0x0,
> backingStore=0x55ce1cb0) at
> ../../include/QtCore/../../src/corelib/tools/qpoint.h:122
> #11 0x77823500 in QWidgetPrivate::paintSiblingsRecursive
> (this=0x55a5b750, pdev=0x55ef6080, siblings=..., index= out>, rgn=..., offset=..., flags=4, sharedPainter=0x0,
> backingStore=0x55ce1cb0) at kernel/qwidget.cpp:5804
> #12 0x77823500 in QWidgetPrivate::paintSiblingsRecursive
> (this

Bug#929042: closed by Afif Elghraoui (Re: Bug#929042: singularity-container: CVE-2019-11328)

[Afif Elghraoui]

على ١٠‏/٩‏/١٤٤٠ هـ ‫٤:٥٧ م، كتب Salvatore Bonaccorso:
>>> Could you furthermore check, is this only introduced in the 3.1.0
>>> series really or just are those the versions checked for the issue,
>>> but earlier versions might be affected as well?
>>>
>> I filed an unblock request to hopefully replace 3.0.3 in Testing. 2.6.1 
>> doesn't have the affected code (it predates the Go implementation).
> Thanks that was important bit to know.

That request is here, by the way:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929011

But my reason for making it had nothing to do with this CVE.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#929042: closed by Afif Elghraoui (Re: Bug#929042: singularity-container: CVE-2019-11328)

[Afif Elghraoui]

على ١٠‏/٩‏/١٤٤٠ هـ ‫٥:١٣ م، كتب Salvatore Bonaccorso:
> Hi Afif,
> 
> On Wed, May 15, 2019 at 10:57:49PM +0200, Salvatore Bonaccorso wrote:
>> Then there is nothing further to be done.
> 
> Oh, actually there is an open point: Is it confirmed that 3.0.3 is not
> affected by the CVE? Did you got any information why this is only
> introduced in 3.1.0?
> 

The release notes say >=3.1.0. The bulk of the patches are in sources
having to do with the oci runtime, which was introduced in 3.1.0. That
would explain the cutoff described by upstream.

In any case, this will hopefully be moot if we can unblock the version
now in Unstable.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Processed: fixed 928944 in 1.9.7-3+deb9u1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed 928944 1.9.7-3+deb9u1
Bug #928944 {Done: Xavier Guimard } 
[liblemonldap-ng-portal-perl] CVE-2019-12046: lemonldap-ng tokens allows 
anonymous session when stored in session DB
Marked as fixed in versions lemonldap-ng/1.9.7-3+deb9u1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928944: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems