Bug#897668: [breeze-cursor] Severe Visibility Issue

2018-05-03 Thread Lumin
Package: breeze-cursor-theme
Version: 4:5.12.4-1
Severity: important

Dear maintainer,

I'm setting severity to important because the visibility of a cursor
theme is really important.

The problematic cursor is the cross cursor of Breeze and Breeze_Snow,
which are located at the svg files in source tree:

  ./cursors/Breeze_Snow/src/cursors.svg
  ./cursors/Breeze/src/cursors.svg

They look good, but when we actually use the cross cursor in a
low-contrast background it is definitely a pain to find the location of
cursor on the screen.

For example, my cursor theme is Breeze. When I'm taking a screenshot
with flameshot, the whole screen is shadowed, according to source code,
the cursor will be set to the cross. However, unlike other breeze cursors
which are padded with a white margin, the cross cursor is padded with
nothing. In this case the cursor has a very low contrast to the
background hence very hard to caught by eyes.

Similarly, I checked Breeze_Snow. And I guess the cross cursor will also
be hard to find when the background is basically grey or white.

I suggest a fix with high-contrast margin added to the cross cursor.

Thanks.



Bug#897667: qt4-x11: Please add support for new architecture "riscv64"

2018-05-03 Thread Manuel A. Fernandez Montecelo
Source: qt4-x11
Version: 4:4.8.7+dfsg-15
Severity: normal
Tags: patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

We need support in this package to bootstrap the riscv64 architecture.

Yes, I know that you want to get rid of Qt4 once and for all and ASAP, and I
fully agree with the goal.  However, a bazillion of packages depend on qt4-x11
indirectly, for example libsdl2 needs it (through fcitx, then
cmake-extra-modules, then qt5-qmake, then qtchooser that depends on Qt4 stuff);
many package still need it directly; etc.

So without support in this package, progress becomes impossible at an early
stage.


I am attaching a patch that adds support for the architecture.  AFAIK (please
confirm) upstream doesn't accept patches since long ago, so no point in sending
it there.  For Qt5 we're already sending it upstream, e.g. webkit stuff.

It would be great if you could include these changes and release a new version
for unstable, for the time being the patched version lives in "unreleased".


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru qt4-x11-4.8.7+dfsg/debian/changelog 
qt4-x11-4.8.7+dfsg/debian/changelog
--- qt4-x11-4.8.7+dfsg/debian/changelog 2018-04-18 22:45:31.0 +0200
+++ qt4-x11-4.8.7+dfsg/debian/changelog 2018-04-27 21:01:58.0 +0200
@@ -1,3 +1,10 @@
+qt4-x11 (4:4.8.7+dfsg-15+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64 support
+
+ -- Manuel A. Fernandez Montecelo   Fri, 27 Apr 2018 21:01:58 
+0200
+
 qt4-x11 (4:4.8.7+dfsg-15) unstable; urgency=medium
 
   * Actually upload it to unstable.
diff -Nru qt4-x11-4.8.7+dfsg/debian/patches/riscv64-support.patch 
qt4-x11-4.8.7+dfsg/debian/patches/riscv64-support.patch
--- qt4-x11-4.8.7+dfsg/debian/patches/riscv64-support.patch 1970-01-01 
01:00:00.0 +0100
+++ qt4-x11-4.8.7+dfsg/debian/patches/riscv64-support.patch 2018-04-27 
21:01:58.0 +0200
@@ -0,0 +1,86 @@
+--- a/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h
 b/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h
+@@ -167,6 +167,15 @@
+ #define WTF_CPU_BIG_ENDIAN 1
+ #endif
+ 
++/* CPU(RISCV64) - RISC-V 64-bit */
++#if defined(__riscv)
++#if (__riscv_xlen == 64)
++#define WTF_CPU_RISCV64 1
++#elif (__riscv_xlen == 32)
++#define WTF_CPU_RISCV32 1
++#endif
++#endif
++
+ /* CPU(SH4) - SuperH SH-4 */
+ #if defined(__SH4__)
+ #define WTF_CPU_SH4 1
+@@ -919,7 +928,7 @@
+ #endif
+ 
+ #if !defined(WTF_USE_JSVALUE64) && !defined(WTF_USE_JSVALUE32) && 
!defined(WTF_USE_JSVALUE32_64)
+-#if (CPU(X86_64) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || OS(HPUX))) || 
(CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || CPU(SPARC64) || 
CPU(MIPS64) || CPU(AARCH64) || CPU(S390X)
++#if (CPU(X86_64) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || OS(HPUX))) || 
(CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || CPU(SPARC64) || 
CPU(MIPS64) || CPU(AARCH64) || CPU(S390X) || CPU(RISCV64)
+ #define WTF_USE_JSVALUE64 1
+ #elif CPU(ARM) || CPU(PPC64)
+ #define WTF_USE_JSVALUE32 1
+--- a/src/3rdparty/webkit/Source/JavaScriptCore/wtf/Platform.h
 b/src/3rdparty/webkit/Source/JavaScriptCore/wtf/Platform.h
+@@ -187,6 +187,15 @@
+ #define WTF_CPU_BIG_ENDIAN 1
+ #endif
+ 
++/* CPU(RISCV64) - RISC-V 64-bit */
++#if defined(__riscv)
++#if (__riscv_xlen == 64)
++#define WTF_CPU_RISCV64 1
++#elif (__riscv_xlen == 32)
++#define WTF_CPU_RISCV32 1
++#endif
++#endif
++
+ /* CPU(SH4) - SuperH SH-4 */
+ #if defined(__SH4__)
+ #define WTF_CPU_SH4 1
+@@ -1000,6 +1009,7 @@
+ #if (CPU(X86_64) && (OS(UNIX) || OS(WINDOWS))) \
+ || (CPU(IA64) && !CPU(IA64_32)) \
+ || CPU(ALPHA) \
++|| CPU(RISCV64) \
+ || CPU(SPARC64) \
+ || CPU(S390X) \
+ || CPU(PPC64) \
+--- a/src/corelib/arch/qatomic_arch.h
 b/src/corelib/arch/qatomic_arch.h
+@@ -76,6 +76,8 @@
+ #  include "QtCore/qatomic_parisc.h"
+ #elif defined(QT_ARCH_POWERPC)
+ #  include "QtCore/qatomic_powerpc.h"
++#elif defined(QT_ARCH_RISCV64)
++#  include "QtCore/qatomic_generic.h"
+ #elif defined(QT_ARCH_S390)
+ #  include "QtCore/qatomic_s390.h"
+ #elif defined(QT_ARCH_SPARC)
+--- /dev/null
 b/src/corelib/arch/riscv64/arch.pri
+@@ -0,0 +1,8 @@
++#
++# RISC-V 64 architecture
++#
++
++unix:SOURCES += ../generic/qatomic_generic_unix.cpp
++win32:SOURCES += ../generic/qatomic_generic_windows.cpp
++
++QMAKE_CXXFLAGS += -fpermissive
+--- a/src/dbus/qdbusintegrator.cpp
 b/src/dbus/qdbusintegrator.cpp
+@@ -73,7 +73,7 @@
+ static bool isDebugging;
+ #define qDBusDebug  if (!::isDebugging); else qDebug
+ 
+-Q_GLOBAL_STATIC_WITH_ARGS(const QString, orgFreedesktopDBusString, 
(QLatin1String(DBUS_SERVICE_DBUS)))
++Q_GLOBAL_STATIC_WITH_ARGS(QString, orgFreedesktopDBusString, 
(QLatin1String(DBUS_SERVICE_DBUS)))
+ 
+ static inline QString dbusServiceString()
+ { return *orgFreedesktopDBusString(); }
diff -Nru qt4-x11-4.8.7+dfsg/debian/patches/series 

Re: CVE-2018-10380: kwallet-pam: Access to privileged files

2018-05-03 Thread Maximiliano Curia

¡Hola Moritz!

El 2018-05-03 a las 22:56 +0200, Moritz Muehlenhoff escribió:

On Thu, May 03, 2018 at 07:29:42PM +0200, Maximiliano Curia wrote:

Hi,



Following up the upstream announcement of a security flaw in
kwallet-pam [1] I would like to upload the upstream fixes to
stretch. All the versions prior the (not yet released) 5.12.6 are
affected by this. The fix was backported by upstream to plasma 5.8,
which is what we shipped in stretch.



The latest 5.8 upstream version (5.8.9), only has a version bump,
and a minor translation update, which are not relevant. [2]



I have already uploaded the fixes to unstable.



I'm attaching the corresponding debdiff.



Looks good. Please build with -sa since kwallet-pam is new in stretch-security
and upload to security-master. I'll take care of the DSA.


Uploaded, thanks for taking care of this!

Happy hacking,
--
"La duración de un minuto depende de que lado del baño estés."
-- Ley de la Relatividad (Burke)
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature


Re: CVE-2018-10380: kwallet-pam: Access to privileged files

2018-05-03 Thread Moritz Muehlenhoff
On Thu, May 03, 2018 at 07:29:42PM +0200, Maximiliano Curia wrote:
> Hi,
> 
> Following up the upstream announcement of a security flaw in
> kwallet-pam [1] I would like to upload the upstream fixes to
> stretch. All the versions prior the (not yet released) 5.12.6 are
> affected by this. The fix was backported by upstream to plasma 5.8,
> which is what we shipped in stretch.
> 
> The latest 5.8 upstream version (5.8.9), only has a version bump,
> and a minor translation update, which are not relevant. [2]
> 
> I have already uploaded the fixes to unstable.
> 
> I'm attaching the corresponding debdiff.

Looks good. Please build with -sa since kwallet-pam is new in stretch-security
and upload to security-master. I'll take care of the DSA.

Cheers,
Moritz



Bug#897649: kdeclarative: Please update symbols for riscv64

2018-05-03 Thread Manuel A. Fernandez Montecelo
Source: kdeclarative
Version: 5.42.0-2
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

We are in the process of bootstrapping a Debian port for the riscv64
architecture (https://wiki.debian.org/RISC-V).

The symbols need to be updated for this arch, please see the patch attached.

We would appreciate if you could upload a version soonish to unstable including
this fix, to keep the delta as small as possible.

If you need help or want us to NMU, etc., please tell.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru kdeclarative-5.44.0/debian/changelog 
kdeclarative-5.44.0/debian/changelog
--- kdeclarative-5.44.0/debian/changelog2018-03-21 14:40:36.0 
+0100
+++ kdeclarative-5.44.0/debian/changelog2018-05-02 19:16:47.0 
+0200
@@ -1,3 +1,10 @@
+kdeclarative (5.44.0-1+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64: symbols update
+
+ -- Manuel A. Fernandez Montecelo   Wed, 02 May 2018 19:16:47 
+0200
+
 kdeclarative (5.44.0-1) sid; urgency=medium
 
   * New upstream release (5.44.0).
diff -Nru kdeclarative-5.44.0/debian/libkf5declarative5.symbols 
kdeclarative-5.44.0/debian/libkf5declarative5.symbols
--- kdeclarative-5.44.0/debian/libkf5declarative5.symbols   2018-03-21 
14:40:36.0 +0100
+++ kdeclarative-5.44.0/debian/libkf5declarative5.symbols   2018-05-02 
19:16:47.0 +0200
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 5.25.0 alpha amd64 arm64 armel armhf hppa hurd-i386 
i386 mips mips64el mipsel powerpc ppc64el s390x x32
+# SymbolsHelper-Confirmed: 5.25.0 alpha amd64 arm64 armel armhf hppa hurd-i386 
i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x x32
 libKF5Declarative.so.5 libkf5declarative5 #MINVER#
  _ZN12KDeclarative12KDeclarative10initializeEv@Base 4.96.0
  _ZN12KDeclarative12KDeclarative13setupBindingsEv@Base 4.96.0
@@ -67,42 +67,42 @@
  _ZNK12KDeclarative9QmlObject6sourceEv@Base 4.96.0
  _ZNK12KDeclarative9QmlObject6statusEv@Base 5.12.0
  _ZNK12KDeclarative9QmlObject7packageEv@Base 5.7.0+git20150305.0804+15.04
- 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 5.12.0
- 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
 5.12.0
- 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE14_M_get_deleterERKSt9type_info@Base
 5.12.0
- 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED0Ev@Base
 5.12.0
- 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED1Ev@Base
 5.12.0
- 
(optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED2Ev@Base
 5.12.0
- 
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 5.12.0
- 
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 5.12.0
- 
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 5.12.0
- 
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 5.12.0
- 
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 5.12.0
- 
(optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 5.12.0
+ (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 5.12.0
+ (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
 5.12.0
+ (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE14_M_get_deleterERKSt9type_info@Base
 5.12.0
+ (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED0Ev@Base
 5.12.0
+ (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED1Ev@Base
 5.12.0
+ (optional=templinst|arch=armel 
riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED2Ev@Base
 5.12.0
+ (optional=templinst|arch=!armel 
!riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 5.12.0
+ (optional=templinst|arch=!armel 

Bug#897338: Tested on hardware

2018-05-03 Thread Lisandro Damián Nicanor Pérez Meyer
El jueves, 3 de mayo de 2018 06:17:14 -03 Maximiliano Curia escribió:
> ¡Hola Александр!
> 
> El 2018-05-03 a las 07:54 +0300, Александр Керножицкий escribió:
> > I tried Debian Testing on real hardware and SDDM seems to work there. So I
> > can reproduce the bug only on VirtualBox.
> It seems that the new sddm requires virtualbox-guest-dkms and
> virtualbox-guest-x11 to run inside a virtualbox, I'm not sure why.

OpenGL probably? Wild guess here...


-- 
11: En Word, como se hace para pasar al proximo renglon si se alcanzo
el extramo derecho de la hoja.
* Se reinicia la maquina, se abre el Guord, se va a archivo, Nuevo
renglon, Preferencias, Abajo del otro renglon, Poner el cursor al
proncipio del nuevo renglon, Elegir misma letra que el anterior,
respetar la pagina anterior, respetar el margen anterior, respetar
numeracion de pagina, comenzar a escribir, click en "Ok deseo comenzar
a escribir", click en "Esta seguro que desea comenzar a Escribir",
click en "Ultima advertencia", click en "Comience a escribir"
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.


CVE-2018-10380: kwallet-pam: Access to privileged files

2018-05-03 Thread Maximiliano Curia

Hi,

Following up the upstream announcement of a security flaw in kwallet-pam [1] I 
would like to upload the upstream fixes to stretch. All the versions prior the 
(not yet released) 5.12.6 are affected by this. The fix was backported 
by upstream to plasma 5.8, which is what we shipped in stretch.


The latest 5.8 upstream version (5.8.9), only has a version bump, and a minor 
translation update, which are not relevant. [2]


I have already uploaded the fixes to unstable.

I'm attaching the corresponding debdiff.

Happy hacking,
[1]: https://marc.info/?l=kde-announce=152534806103730=2
[2]: https://cgit.kde.org/kwallet-pam.git/log/?h=Plasma/5.8
--
"If it ain't broke, don't fix it" -- Bert Lance

"If we can't fix it, it ain't broke" -- Lieutenant Colonel Walt Weir
Saludos /\/\ /\ >< `/
diff -Nru kwallet-pam-5.8.4/debian/changelog kwallet-pam-5.8.4/debian/changelog
--- kwallet-pam-5.8.4/debian/changelog  2016-11-23 18:36:40.0 +0100
+++ kwallet-pam-5.8.4/debian/changelog  2018-05-03 19:01:35.0 +0200
@@ -1,3 +1,11 @@
+kwallet-pam (5.8.4-1+deb9u1) stretch-security; urgency=high
+
+  * CVE-2018-10380 fix
+Add upstream patches Move-salt-creation-to-an-unprivileged-process.patch
+and Move-socket-creation-to-unprivileged-codepath.patch.
+
+ -- Maximiliano Curia   Thu, 03 May 2018 19:01:35 +0200
+
 kwallet-pam (5.8.4-1) unstable; urgency=medium
 
   * New upstream release (5.8.4)
diff -Nru 
kwallet-pam-5.8.4/debian/patches/Move-salt-creation-to-an-unprivileged-process.patch
 
kwallet-pam-5.8.4/debian/patches/Move-salt-creation-to-an-unprivileged-process.patch
--- 
kwallet-pam-5.8.4/debian/patches/Move-salt-creation-to-an-unprivileged-process.patch
1970-01-01 01:00:00.0 +0100
+++ 
kwallet-pam-5.8.4/debian/patches/Move-salt-creation-to-an-unprivileged-process.patch
2018-05-03 19:01:35.0 +0200
@@ -0,0 +1,201 @@
+From: Albert Astals Cid 
+Date: Tue, 1 May 2018 12:29:02 +0200
+Subject: Move salt creation to an unprivileged process
+
+Opening files for writing as root is very tricky since through the power
+of symlinks we can get tricked to write in places we don't want to and
+we don't really need to be root to create the salt file
+---
+ pam_kwallet.c | 120 ++
+ 1 file changed, 71 insertions(+), 49 deletions(-)
+
+diff --git a/pam_kwallet.c b/pam_kwallet.c
+index 809ab9a..2617311 100644
+--- a/pam_kwallet.c
 b/pam_kwallet.c
+@@ -61,7 +61,7 @@ const static char *envVar = "PAM_KWALLET_LOGIN";
+ 
+ static int argumentsParsed = -1;
+ 
+-int kwallet_hash(const char *passphrase, struct passwd *userInfo, char *key);
++int kwallet_hash(pam_handle_t *pamh, const char *passphrase, struct passwd 
*userInfo, char *key);
+ 
+ static void parseArguments(int argc, const char **argv)
+ {
+@@ -282,7 +282,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int 
flags, int argc, cons
+ }
+ 
+ char *key = malloc(sizeof(char) * KWALLET_PAM_KEYSIZE);
+-if (kwallet_hash(password, userInfo, key) != 0) {
++if (kwallet_hash(pamh, password, userInfo, key) != 0) {
+ pam_syslog(pamh, LOG_ERR, "%s: Fail into creating the hash", 
logPrefix);
+ return PAM_IGNORE;
+ }
+@@ -306,6 +306,26 @@ PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, 
int flags, int argc, cons
+ return PAM_SUCCESS;
+ }
+ 
++static int drop_privileges(struct passwd *userInfo)
++{
++/* When dropping privileges from root, the `setgroups` call will
++* remove any extraneous groups. If we don't call this, then
++* even though our uid has dropped, we may still have groups
++* that enable us to do super-user things. This will fail if we
++* aren't root, so don't bother checking the return value, this
++* is just done as an optimistic privilege dropping function.
++*/
++setgroups(0, NULL);
++
++//Change to the user in case we are not it yet
++if (setgid (userInfo->pw_gid) < 0 || setuid (userInfo->pw_uid) < 0 ||
++setegid (userInfo->pw_gid) < 0 || seteuid (userInfo->pw_uid) < 0) {
++return -1;
++}
++
++return 0;
++}
++
+ static void execute_kwallet(pam_handle_t *pamh, struct passwd *userInfo, int 
toWalletPipe[2], int envSocket)
+ {
+ //In the child pam_syslog does not work, using syslog directly
+@@ -320,18 +340,8 @@ static void execute_kwallet(pam_handle_t *pamh, struct 
passwd *userInfo, int toW
+ //This is the side of the pipe PAM will send the hash to
+ close (toWalletPipe[1]);
+ 
+-/* When dropping privileges from root, the `setgroups` call will
+-* remove any extraneous groups. If we don't call this, then
+-* even though our uid has dropped, we may still have groups
+-* that enable us to do super-user things. This will fail if we
+-* aren't root, so don't bother checking the return value, this
+-* is just done as an optimistic privilege dropping function.
+-*/
+-setgroups(0, 

kwallet-pam_5.12.1-2_amd64.changes ACCEPTED into unstable

2018-05-03 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 03 May 2018 18:26:15 +0200
Source: kwallet-pam
Binary: libpam-kwallet-common libpam-kwallet4 libpam-kwallet5
Architecture: source all amd64
Version: 5.12.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian/Kubuntu Qt/KDE Maintainers 
Changed-By: Maximiliano Curia 
Description:
 libpam-kwallet-common - KWallet integration with PAM (common files)
 libpam-kwallet4 - KWallet (KDE 4) integration with PAM
 libpam-kwallet5 - KWallet (Kf5) integration with PAM
Changes:
 kwallet-pam (5.12.1-2) unstable; urgency=medium
 .
   * CVE-2018-10380 fix
 Add upstream patches Move-salt-creation-to-an-unprivileged-process.patch
 and Move-socket-creation-to-unprivileged-codepath.patch.
   * Release to unstable
Checksums-Sha1:
 e9654565f5a1a6f30ba880f2f2c496e5b10ac47f 2246 kwallet-pam_5.12.1-2.dsc
 2a88f514ddaa10b7c9a34d0aa75c4ce833e26011 12236 
kwallet-pam_5.12.1-2.debian.tar.xz
 a33d1befe1c06a785862e7ccf47bed85d286586d 12449 
kwallet-pam_5.12.1-2_amd64.buildinfo
 5ae5ce3e83e800ee2d147e37a5083b7c0ca95e32 6468 
libpam-kwallet-common_5.12.1-2_all.deb
 76853fdc7beb001f7bd0528ba8a008b4bb405f50 17644 
libpam-kwallet4-dbgsym_5.12.1-2_amd64.deb
 c66380c5c5d328d14477bacdb7e48cd878cbd0eb 11612 
libpam-kwallet4_5.12.1-2_amd64.deb
 dbf8cc1e3e70458f919c3689e8577d9d2c82cfdb 17652 
libpam-kwallet5-dbgsym_5.12.1-2_amd64.deb
 4248ffdafff263a569280ebf734b43735b180f53 11580 
libpam-kwallet5_5.12.1-2_amd64.deb
Checksums-Sha256:
 b261f33235fc74059ab963b79dae12788d17c894f27c323c2ec2561cb6ce5840 2246 
kwallet-pam_5.12.1-2.dsc
 473c1be9ecd7f4d5a36379cd736b28a8791e8e684fe06eef87fea853d071 12236 
kwallet-pam_5.12.1-2.debian.tar.xz
 b014a25a104238ed97701398a29d1d41ae681c262aa73ac8534c4745893d2241 12449 
kwallet-pam_5.12.1-2_amd64.buildinfo
 cb930dd6010b734a7c3acaea0f0755b5ff85b43094ce89625b5f282d6eba97f1 6468 
libpam-kwallet-common_5.12.1-2_all.deb
 360b1bf286d3de880361760896ea392e20f06331d0817a25a840a145e3d78f86 17644 
libpam-kwallet4-dbgsym_5.12.1-2_amd64.deb
 68c82601dab0abd960125ba1100fa9b8e0477cac3930bda296d04fbf712b80ee 11612 
libpam-kwallet4_5.12.1-2_amd64.deb
 9b888fb53ada7ac5e7ff205bd12621d615514548aa885b7df44686fd7cf18a96 17652 
libpam-kwallet5-dbgsym_5.12.1-2_amd64.deb
 0bb072b935cdf29a2429dc71d2e138e194e71bb19f4446823f20526f2879239e 11580 
libpam-kwallet5_5.12.1-2_amd64.deb
Files:
 daa78c7ba04dd0d6805ed6be33a221ae 2246 kde optional kwallet-pam_5.12.1-2.dsc
 b03644b298fd21b36e3f1d184cc3a1df 12236 kde optional 
kwallet-pam_5.12.1-2.debian.tar.xz
 d572ffdc23f024311d73315270f14321 12449 kde optional 
kwallet-pam_5.12.1-2_amd64.buildinfo
 a802aa5518ca7bbbf48a8ce1d7223152 6468 kde optional 
libpam-kwallet-common_5.12.1-2_all.deb
 ed3104c9c89e8462df098c8a20a7f22f 17644 debug optional 
libpam-kwallet4-dbgsym_5.12.1-2_amd64.deb
 982eaa13a83eb9e8a390d4dabd7d4be2 11612 kde optional 
libpam-kwallet4_5.12.1-2_amd64.deb
 61021eb33ed50616c4f06bd108bc8402 17652 debug optional 
libpam-kwallet5-dbgsym_5.12.1-2_amd64.deb
 b2a8343eb21f35aa3c682ff5fdf50a28 11580 kde optional 
libpam-kwallet5_5.12.1-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+JIdOnQEyG4RNSIVxxl2mbKbIyoFAlrrOOcACgkQxxl2mbKb
IyqDlw//YN+vjYOA7Mk8pU8hV5xjvt6Xa5UY7J1A6wSV7QKozzHVX50qXa9FGdBO
poyoom16hJbST5KCM7PHPs3CKYwMEyJ5oo1eVJsNLpxWpwwLXP88v1OGWY0dE7fx
T1ip0tS6lU5Rfadh+4tb8/jXB60x/eSlgiFuPxwtOrQj8OnrLcp9L1SoQyJmBn7E
jKqSbILa5JveY6ALzlEvcumnEaxaBjwiAO1qAUhY/vosusGRhWV0mI+f93gmB58O
sgk0dpEgFIKZEXhwWq6dhbEPmAuogfmlAkai9tkKfpJaK3MfwdffEgyUcHPDzkTZ
451Cr+4vQ1Ze2tdpOGiedrjSTrUX7dSrlDitx5giY4AEDkKy1+2RvrHR3R3SkifC
0E7+8K/CNxQRvfB02jQAkLQae8M0ueEUX9MsfAesZFtCr4bgMJZRNuai/mrzjpVX
eA9YCvFDM0iW/N6fnhCeDD/6IsXzbSbHG2mAagzflw3HQWgN6yKcMh1Jd0V+2oj9
wHvX7R6ogHVAgVG5WoFUrArYImrgbd+ZrgY1Kf1SKW4pORvvEaNuz5xKWmTPFMz9
DMo8h9o8QIaYZEdMNxSPaDGP1p7vLKaxdgXCo88PbFBz+YFxwu+DECdgVgcz9aM3
Odp6+nIL4OINNcGQmqMZvLQwUV4dmylyMzLuLikp7D6vZHJquyc=
=9QSd
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Processing of kwallet-pam_5.12.1-2_amd64.changes

2018-05-03 Thread Debian FTP Masters
kwallet-pam_5.12.1-2_amd64.changes uploaded successfully to localhost
along with the files:
  kwallet-pam_5.12.1-2.dsc
  kwallet-pam_5.12.1-2.debian.tar.xz
  kwallet-pam_5.12.1-2_amd64.buildinfo
  libpam-kwallet-common_5.12.1-2_all.deb
  libpam-kwallet4-dbgsym_5.12.1-2_amd64.deb
  libpam-kwallet4_5.12.1-2_amd64.deb
  libpam-kwallet5-dbgsym_5.12.1-2_amd64.deb
  libpam-kwallet5_5.12.1-2_amd64.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)



Bug#897221: Session logout doesn't TERMinate all processes

2018-05-03 Thread Maximiliano Curia

¡Hola Didier!

El 2018-04-30 a las 12:21 +0200, Didier 'OdyX' Raboud escribió:

Package: sddm
Version: 0.17.0-1
Severity: important
Tags: upstream



I routinely run two sessions in parallel (pro & private); and I noticed that
sddm (which I assume is handling the logind session) doesn't coherently
TERMinate (or KILL after some delay) processes from a logged-out session.



Some of these consume ressources (akonadiserver is the usual culprit), but more
importantly; keeping these alive will  break subsequent sessions for the same
user (plasma, akonadi, etc).


I guess akonadiserver is started as a detached process, so ksmserver doesn't 
know about it.


Anyway the problem are the processes that are in the systemd concept of 
session but not in the kde concept of session, those are the ones that systemd 
is waiting for, and ksmserver has long forgotten about them.


Please check loginctl session-status  (The id can be obtained with 
loginctl list-sessions)



Running:
# loginctl terminate-user 
circumvents the issue, but that should really be done by the login manager.



Please tell me if there's something I can do to help here.


Mmh, this is a complex problem. Debian systemd reverts the default logind 
configuration KillUserProcesses, that effectively terminates the session when 
the user logs out, and most desktop environments assume this is set to it's 
default value, so they don't have to deal with the processes started by 
systemd --user, which, by the way, the desktop environment had nothing to do 
with.


Also, kde does nothing to remember which processes were started as autostart 
desktop files.


Gnome "fixes" this by terminating the logind session, as if 
KillUserProcesses was set, at the cost of breaking tmux and screen (which is 
the reason why Debian reverts the KillUserProcesses setting on the first 
place).


So, either we need to fix tmux and screen to they can be detached from the 
logind session, or fix the kde concept of session so it matches better what 
logind expects.


Happy hacking,
--
"I decry the current tendency to seek patents on algorithms. There are better 
ways to earn a living than to prevent other people from making use of one's 
contributions to computer science."

-- Donald Knuth
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature


Bug#897338: Tested on hardware

2018-05-03 Thread Maximiliano Curia

¡Hola Александр!

El 2018-05-03 a las 07:54 +0300, Александр Керножицкий escribió:

I tried Debian Testing on real hardware and SDDM seems to work there. So I can 
reproduce the bug only on VirtualBox.


It seems that the new sddm requires virtualbox-guest-dkms and 
virtualbox-guest-x11 to run inside a virtualbox, I'm not sure why.


Happy hacking,
--
"We must be very careful when we give advice to younger people: sometimes they 
follow it!"

-- Edsger W. Dijkstra
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature