Bug#844535: akonadi: akonadiserver fails to start for normal users without mysql-server-5.5 installed
Control: reassign -1 mysql-5.5 5.5.53-0+deb8u1 Control: retitle -1 mysql-server-core-5.5 should install mysql-files 2016-11-16 22:00 GMT+01:00 Maximiliano Curia : > ¡Hola Bálint! > > El 2016-11-16 a las 19:58 +0100, Bálint Réczey escribió: >>> >>> Do you have the updated conffile? > > >> It seem so: >> vagrant@vagrant:~$ grep secure -A1 -B1 /etc/akonadi/mysql-global.conf # >> Unset the export dir check as only the full mysql-server package creates it >> secure_file_priv= > > > Ok, this file is then used to update the ~/.local/share/akonadi/mysql.conf > file. Does this file has the secure_file_priv= line in it? No, but removing it made akonadi update it and now akonadi works. > >> Do you have /var/lib/mysql-files on you fixed system? > > > No, I don't have that directory. I think the package shipping mysqld should create it since mysqld expects it to exist. Reassigning to mysql to see if maintainer agrees. Thanks for the help in triaging! Cheers, Balint
Bug#844535: akonadi: akonadiserver fails to start for normal users without mysql-server-5.5 installed
Hi Maximiliano, 2016-11-16 18:46 GMT+01:00 Maximiliano Curia : > ¡Hola Bálint! > > El 2016-11-16 a las 17:55 +0100, Bálint Réczey escribió: >> >> Mysql-server-core-5.5 5.5.53-0+deb8u1 broke akonadi for root user: >> #843534. Akonadi got updated, but now it expects /var/lib/mysql-files to be >> present on the system: > > > The directory /var/lib/mysql-files is the default value of the configuration > option "secure_file_priv" (of the section mysqld), the only change in > akonadi 1.13.0-2+deb8u2 is to set: > secure_file_priv= > in the global akonadi configuration for the mysql backend > (/etc/akonadi/mysql-global.conf) this is in the akonadi-backend-mysql > package. > > Was your akonadi-backend-mysql updated? Yes: vagrant@vagrant:~$ dpkg -l akonadi-backend-mysql Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++--===-===-= ii akonadi-backend-mysql1.13.0-2+deb8u2 all MySQL storage backend for Akonadi > > Do you have the updated conffile? It seem so: vagrant@vagrant:~$ grep secure -A1 -B1 /etc/akonadi/mysql-global.conf # Unset the export dir check as only the full mysql-server package creates it secure_file_priv= Do you have /var/lib/mysql-files on you fixed system? Cheers, Balint
Bug#844535: akonadi: akonadiserver fails to start for normal users without mysql-server-5.5 installed
Package: akonadi-server
Version: 1.13.0-2+deb8u2
Severity: important
Dear akonadi Maintainers,
Mysql-server-core-5.5 5.5.53-0+deb8u1 broke akonadi for root user: #843534.
Akonadi got updated, but now it expects /var/lib/mysql-files to be
present on the system:
ProcessControl: Application 'akonadiserver' returned with exit code
255 (Unknown error)
search paths: ("/usr/local/bin", "/usr/bin", "/bin",
"/usr/local/games", "/usr/games", "/usr/sbin", "/usr/local/sbin",
"/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec",
"/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
Found mysql_install_db: "/usr/bin/mysql_install_db"
Found mysqlcheck: "/usr/bin/mysqlcheck"
Database process exited unexpectedly during initial connection!
executable: "/usr/sbin/mysqld"
arguments: ("--defaults-file=/home/vagrant/.local/share/akonadi/mysql.conf",
"--datadir=/home/vagrant/.local/share/akonadi/db_data/",
"--socket=/tmp/akonadi-vagrant.9LSx7K/mysql.socket")
stdout: ""
stderr: "/usr/sbin/mysqld: Error on realpath() on
'/var/lib/mysql-files' (Error 2)
161116 10:36:33 [ERROR] Failed to access directory for
--secure-file-priv. Please make sure that directory exists and is
accessible by MySQL Server. Supplied value : /var/lib/mysql-files
161116 10:36:33 [ERROR] Aborting
This directory is created in mysql-server-5.5's postinst script in
5.5.53-0+deb8u1.
I suggest fixing this issue in two steps:
1. Creating the directory in mysql-server-core-5.5's postinst in 5.5.53-0+deb8u2
2. Depending on mysql-server-core-5.5 (>= 5.5.53-0+deb8u2) in akonadi
1.13.0-2+deb8u3
If you agree with the suggested solution please clone the bug to
mysql-5.5 to let step 1. start.
Cheers,
Balint
PS: /var/lib/mysql-files is left on the system after mysqld-server-5.5
is removed which may be a problem to solve in the mysql fix.
Wheezy update of kde-runtime?
Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of kde-runtime: https://security-tracker.debian.org/tracker/CVE-2016-7787 Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-...@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. You can also opt-out from receiving future similar emails in your answer and then the LTS Team will take care of kde-runtime updates for the LTS releases. (In case we don't get any answer for months, we may also take it as an opt-out, too.) Thank you very much. Balint Reczey, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
Re: Enabling PIE by default for Stretch
Hi Maximiliano, 2016-10-10 14:21 GMT+02:00 Maximiliano Curia : > ¡Hola Niels! > > El 2016-10-10 a las 05:44 +, Niels Thykier escribió: >> >> Niels Thykier: >>> >>> As brought up on the meeting last night, I think we should try to go for >>> PIE by default in Stretch on all release architectures! * It is a >>> substantial hardening feature * Upstream has vastly reduced the performance >>> penalty for x86 * The majority of all porters believe their release >>> architecture isready for it. * We have sufficient time to solve any >>> issues or revert if it turns outto be too problematic. > > >>> [...] > > >>> * Deadline for major concerns: Fri, 7th of October 2016. > > >> It appears that there were no major concerns. I will follow up #835148 >> and request PIE by default for the following architectures. > > >> * amd64 * arm64 * armel * armhf * i386 * mips * mips64el * mipsel * >> ppc64el * s390x > > > Such a change will produce unneeded FTBFS's in libraries using -fPIC (such > as qt5 and all it's dependencies). > > Afaik, -fPIC is stronger than -fPIE, at the same time, -fPIE is incompatible > with -fPIC and -fPIE makes little sense in shared libraries. > > And while a single patch should be trivial, I fear they would be many > specific ones. Have you seen the results of the test-rebuild performed with the changed defaults? I have put together a page with related links and information where you can find the rebuild results, too: https://wiki.debian.org/Hardening/PIEByDefaultTransition Cheers, Balint
Re: Wheezy update of kde4libs?
Hi Maximiliano,
2016-07-25 15:41 GMT+02:00 Bálint Réczey :
> Hi,
>
> 2016-07-19 23:12 GMT+02:00 Brian May :
>> Maximiliano Curia writes:
>>
>>> I just did the upload to unstable, with the karchive fix from upstream and
>>> an
>>> modified version of that one for kde4libs. The second one needs some test,
>>> sadly adding the (binary) test file used in karchive is a bit of a burden.
Apparently one line, the actual fix is missing from the patch.
The warning is issued, but the wrong path is still used in unstable:
cat debian/patches/cve-2016-6232.patch
...
const KArchiveDirectory* curDir = dirStack.pop();
-const QString curDirName = dirNameStack.pop();
+
+// extract only to specified folder if it is located within
archive's extraction folder
+// otherwise put file under root position in extraction folder
+QString curDirName = dirNameStack.pop();
+if (!QDir(curDirName).absolutePath().startsWith(destDir)) {
+qWarning() << "Attempted export into folder" << curDirName
+<< "which is outside of the extraction root folder" <<
destDir << "."
+<< "Changing export of contained files to extraction root
folder.";
+}
root.mkdir(curDirName);
...
In the original fix there is an additional line right after the if ( ...:
https://git.reviewboard.kde.org/r/128185/diff/2#3
...
+ if (!QDir(curDirName).absolutePath().startsWith(destDir)) {
+ curDirName = destDir;
...
I have tested the incomplete fix with the following little program:
vagrant@debian-wheezy:~/extract/test$ cat kextract.cpp
#include
#include
int main (int argc, char * argv[]) {
if (argc < 3) exit (1);
KTar tar(argv[1]);
tar.open(QIODevice::ReadOnly);
const KArchiveDirectory *dir = tar.directory();
dir->copyTo(argv[2]);
return 0;
}
vagrant@debian-wheezy:~/extract/test$ rm ../foo
vagrant@debian-wheezy:~/extract/test$ g++ -I/usr/include/qt4 -lkdecore
kextract.cpp
vagrant@debian-wheezy:~/extract/test$ cat ../foo
cat: ../foo: No such file or directory
vagrant@debian-wheezy:~/extract/test$ ./a.out
tar_relative_path_outside_archive.tar.bz2 ./
bzDecompress returned 4
KBzip2Filter::uncompress 1
Attempted export into folder "/home/vagrant/extract/test/.." which is
outside of the extraction root folder "/home/vagrant/extract/test" .
Changing export of contained files to extraction root folder.
vagrant@debian-wheezy:~/extract/test$ cat ../foo
asdf
I have built an update for wheezy with the missing line added.
Please find the proposed diff attached which I plan uploading for Wheezy
on Wednesday.
The binary packages for amd64 are also available for testing here:
https://people.debian.org/~rbalint/ppa/wheezy-lts/wheezy-security/
Cheers,
Balint
diff -Nru kde4libs-4.8.4/debian/changelog kde4libs-4.8.4/debian/changelog
--- kde4libs-4.8.4/debian/changelog 2014-08-07 22:44:05.0 +0200
+++ kde4libs-4.8.4/debian/changelog 2016-07-25 15:13:22.0 +0200
@@ -1,3 +1,10 @@
+kde4libs (4:4.8.4-4+deb7u2) wheezy-security; urgency=medium
+
+ * Add new patch: cve-2016-6232.patch
+- Fixes: CVE-2016-6232
+
+ -- Balint Reczey Mon, 25 Jul 2016 15:12:35 +0200
+
kde4libs (4:4.8.4-4+deb7u1) wheezy-security; urgency=medium
* Fix kauth authentication bypass. (Closes: #755814)
diff -Nru kde4libs-4.8.4/debian/patches/cve-2016-6232.patch kde4libs-4.8.4/debian/patches/cve-2016-6232.patch
--- kde4libs-4.8.4/debian/patches/cve-2016-6232.patch 1970-01-01 01:00:00.0 +0100
+++ kde4libs-4.8.4/debian/patches/cve-2016-6232.patch 2016-07-25 19:58:12.0 +0200
@@ -0,0 +1,50 @@
+From aa4d7b23ca046daeffd0695ee519315d5d6ae1bb Mon Sep 17 00:00:00 2001
+From: Debian/Kubuntu Qt/KDE Maintainers
+Date: Tue, 19 Jul 2016 10:38:59 +0200
+Subject: [PATCH] Ensure extraction location to be in subfolder
+
+Behavior change: Switch to Tar's default behavior to avoid extraction
+to arbitrary system locations outside of extraction folder. Instead,
+extract such files to root location in extraction folder.
+
+REVIEW: 128185
+Author: Andreas Cord-Landwehr
+Taken from karchive commit 0cb243f64eef45565741b27364cece7d5c349c37
+the test was dropped in this patch as it depends on a binary file.
+Fixes: CVE-2016-6232
+---
+ kdecore/io/karchive.cpp | 13 +++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/kdecore/io/karchive.cpp
b/kdecore/io/karchive.cpp
+@@ -778,6 +778,7 @@
+ void KArchiveDirectory::copyTo(const QString& dest, bool recursiveCopy ) const
+ {
+ QDir root;
++ const QString destDir(QDir(dest).absolutePath()); // get directory path without any "." or ".."
+
+ QList fileList;
+ QMap fileToDir;
+@@ -787,10 +788,19 @@
+ QStack dirNameStack;
+
+ dirStack.push( this ); // init stack at current directory
+- dirNameStack.push( dest ); // ... with given path
++ dirNameStack.pu
Re: Wheezy update of kde4libs?
Hi, 2016-07-19 23:12 GMT+02:00 Brian May : > Maximiliano Curia writes: > >> I just did the upload to unstable, with the karchive fix from upstream and an >> modified version of that one for kde4libs. The second one needs some test, >> sadly adding the (binary) test file used in karchive is a bit of a burden. >> >> After these packages are available we would need to backport the change to >> stable. Right now, I can't promise that I would have the time to take care of >> this. So volunteers for taking care of this are welcome. > > I had a look at doing this for wheezy LTS several days ago. It looks > like it should be reasonably straight forward (famous last words?) to > apply the changes manually to the wheezy version, although the files > have moved (and automatic patching failed). If nobody takes this up by > next month I should have some time then to continue this. I seems really straight forward indeed and I can fix it today thus let me take care of it. It is compiling already. Cheers, Balint
Bug#796956: Explanation
Hi Lisandro, 2016-01-19 15:12 GMT+01:00 Lisandro Damián Nicanor Pérez : > Hi Bálint! > > On Monday 18 January 2016 10:38:05 Bálint Réczey wrote: >> Hi Lisandro, > > [snip] > >> 5.6.x is beta in experimental and I can't tell when it enters >> unstable. If it does not >> get uploaded to unstable in a few days with a good chance of migrating >> to testing >> soon please upload a fix to 5.5.x. > > I'm working for pushing it in 5.5.2, hopefully real soon. Thanks! Cheers, Balint
Bug#796956: Explanation
Hi Lisandro, 2016-01-15 15:16 GMT+01:00 Lisandro Damián Nicanor Pérez : > severity 796956 important > thanks > > OK everyone this is really not a serious bug (actually I still don't think > this is a bug at all). I'll keep it open until we get Qt 5.6 into the archive > with a "fix". > > Let's start with the basics: sadly libqt5xcbqpa5 is a missnamed package. it > should have been something along qt5-xcb-platform-plugin... because it's a > plugin which happens to ship a private lib (that's why we accidentally > misnamed it). > > Now the reasoning: Qt 5 now works with "platform" plugins and not necessarily > just on X. That means that as long as you don't depend on X-exclusive stuff > (or any other platform-dependant code) you can run a Qt5 app on the > frambuffer, Wayland and other interesting places. > > So, strictly speaking, libqt5xcbqpa5 (which again should have been named as a > plugin) is not a strict dependency, and thus the recommendation. And people > not using recommendations should handle it by hand. Since a missing libqt5xcbqpa5 would make applications crash on X which is far more popular than framebuffer or Wayland it does not seem to be a good idea to handle it as a pure recommendation. Libqt5xcbqpa5 being a true plugin or not is a semantic question. Users probably does not call a component a plugin, when and application does not start at all on their system. Developers can call those plugins, but making them mandatory can make users not to think about that question. ... > I'm now leaving this non-bug opened as important just to let people now that > there is really no bug and how to solve this issue. I will close it with Qt > 5.6.x if we get to merge the plugins. 5.6.x is beta in experimental and I can't tell when it enters unstable. If it does not get uploaded to unstable in a few days with a good chance of migrating to testing soon please upload a fix to 5.5.x. Otherwise wireshark would have to be updated twice, once for adding libqt5xcbqpa5 as a dependency and once for removing it for Qt 5.6.x. Fixing this bug for Qt fixes many other packages and it will be fixed in Qt anyway thus please consider updating Qt 5.5 in a few days. This problem may be an "important" one in Qt, but for every other package affected it creates an RC bug. Thanks, Balint
Re: Bug#811036: wireshark-qt: aborts immediately
Hi Olaf, 2016-01-15 10:28 GMT+01:00 Olaf Meeuwissen : > > Bálint Réczey writes: > >> Hi Olaf, >> >> 2016-01-15 5:51 GMT+01:00 Olaf Meeuwissen : >>> Package: wireshark-qt >>> Version: 2.0.0+g9a73b82-1 >>> Severity: grave >>> >>> Dear Maintainer, >>> >>> I tried starting wireshark from the comman-line and it immediately >>> aborted. Like so: >>> >>> $ wireshark >>> This application failed to start because it could not find or load the Qt >>> platform plugin "xcb". >>> >>> Available platform plugins are: linuxfb, minimal, minimalegl, offscreen. >>> >>> Reinstalling the application may fix this problem. >>> Aborted >>> >>> I had expected it to start like it used to do. I don't recall when I >>> last used it. I keep my system up-to-date with unattended-upgrades and >>> my logs indicate wireshark-qt was installed on 2015-12-01 with the >>> upgrade of wireshark from 1.12.8+g5b6e543-2 to 2.0.0+g9a73b82-1. I do >>> remember being surprised at the changed look-and-feel of wireshark, so I >>> am pretty sure that I have run wireshark-qt successfully in the past. > >> Please install libqt5xcbqpa5 to let it run again. >> >> I suspect you installed wireshark/libqt5gui5 with --no-install-recommends, >> since libqt5gui5 recommends libqt5xcbqpa5: > > Almost, I ran unattended-upgrade and my apt.conf has > > APT::Install-Recommends "false"; > Apt::AutoRemove::RecommendsImportant "false"; > Unattended-Upgrade::Remove-Unused-Dependencies "true"; > >> Package: libqt5gui5 >> Source: qtbase-opensource-src >> Version: 5.5.1+dfsg-12 >> Installed-Size: 7096 >> Maintainer: Debian Qt/KDE Maintainers >> Architecture: amd64 >> ... >> Recommends: libqt5svg5, libqt5xcbqpa5 >> >> --no-install-recommends may cause parts of functionality not available >> in packages. > > Well, in this case *all* of the functionality was not available. The > wireshark executable is the only thing in /usr/bin/ of wireshark-qt. > >> It that was the case, please close the bug since the default behavior >> of installing all >> needed packages for proper operation was overridden. > > I think we have different opinions on what is "needed" for proper > operation. From Debian Policy, section 7.2 under `Depends`: > > The `Depends` field should be used if the depended-on package is > required for the depending package to provide a significant amount > of functionality. > > I would argue that showing the GUI is a prerequisite for any of the > functionality. The GUI isn't shown, hence, zero functionality. It still had wireshark manpage which is not present in wireshark-gtk and can be useful, but I see your point. :-) > I don't know how wireshark-qt obtained the dependency but it needs that > xcb plugin very badly to provide any functionality. Can't you add the > libqt5xcbqpa5 dependency to wireshark-qt (even if only temporarily)? I can, but fixing that a fixed libqt5gui5 would reach testing as fast a fix in wireshark-qt, thus I would like to as KDE Maintaintainers to share their thoughts first. IMO packages should not follow how Qt packages are structured to set their dependencies, but Qt should provide helper scripts which set the needed dependencies for the binary packages. Many other frameworks do that. If the KDE team still decides to split the packages with no helper scripts, please coordinate with reverse dependencies in advance to avoid bugs like this one. Cheers, Balint
Re: Bug#811036: wireshark-qt: aborts immediately
Hi Olaf, 2016-01-15 5:51 GMT+01:00 Olaf Meeuwissen : > Package: wireshark-qt > Version: 2.0.0+g9a73b82-1 > Severity: grave > > Dear Maintainer, > > I tried starting wireshark from the comman-line and it immediately > aborted. Like so: > > $ wireshark > This application failed to start because it could not find or load the Qt > platform plugin "xcb". > > Available platform plugins are: linuxfb, minimal, minimalegl, offscreen. > > Reinstalling the application may fix this problem. > Aborted > > I had expected it to start like it used to do. I don't recall when I > last used it. I keep my system up-to-date with unattended-upgrades and > my logs indicate wireshark-qt was installed on 2015-12-01 with the > upgrade of wireshark from 1.12.8+g5b6e543-2 to 2.0.0+g9a73b82-1. I do > remember being surprised at the changed look-and-feel of wireshark, so I > am pretty sure that I have run wireshark-qt successfully in the past. Please install libqt5xcbqpa5 to let it run again. I suspect you installed wireshark/libqt5gui5 with --no-install-recommends, since libqt5gui5 recommends libqt5xcbqpa5: Package: libqt5gui5 Source: qtbase-opensource-src Version: 5.5.1+dfsg-12 Installed-Size: 7096 Maintainer: Debian Qt/KDE Maintainers Architecture: amd64 ... Recommends: libqt5svg5, libqt5xcbqpa5 --no-install-recommends may cause parts of functionality not available in packages. It that was the case, please close the bug since the default behavior of installing all needed packages for proper operation was overridden. BTW this looks like the following Qt bug appearing again which I just reopened: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796956 KDE Mainainers may mark it as wontfix or solve the circular dependency introduced by the fix in a different way. Cheers, Balint > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'testing-updates'), (500, > 'stable-updates'), (500, 'unstable'), (500, 'stable') > Architecture: amd64 (x86_64) ... > ii libqt5gui5 5.5.1+dfsg-12 ...
Bug#782063: qtwebkit-opensource-src: FTBFS on sparc
Source: qtwebkit-opensource-src Version: 5.3.2+dfsg-4 Severity: important Dear Maintainer, The package fails to build properly on build official build boxes due to many missing symbols on sparc [1]. The lack of Qt development libraries prevent many other packages from building on sparc including Wireshark. Thanks, Balint https://buildd.debian.org/status/fetch.php?pkg=qtwebkit-opensource-src&arch=sparc&ver=5.3.2%2Bdfsg-4&stamp=1427981198 -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAK0OdpyrnRxS5WcXbYTefgAcu1Ts1-DZebgOJdHZkWtYcb=r...@mail.gmail.com
