RE: RFC: proposed fix for CVE-2018-19518 in uw-imap
Unsubscribe pls -Message d'origine- De : Roberto C. Sánchez Envoyé : samedi 29 décembre 2018 16:25 À : debian-lts@lists.debian.org; debian-secur...@lists.debian.org; Debian Security Team Cc : holmg...@debian.org Objet : Re: RFC: proposed fix for CVE-2018-19518 in uw-imap On Sat, Dec 22, 2018 at 10:27:18PM -0500, Roberto C. Sánchez wrote: > [note: I am not subscribed to debian-security; please keep me or > debian-lts addressed on replies] > > If this seems like a sensible approach, I propose to apply the > attached patch to uw-imap 8:2007f~dfsg-5 (the current > stretch/buster/sid version) to create version 8:2007f~dfsg-6 for > upload to sid and eventual inclusion in stretch (perhaps via a point > release) and then also in parallel create a 8:2007f~dfsg-4+deb8u1 package for > upload to jessie. > > Please reply with your comments. In particular, feedback from the > security team on the appropriateness of this for a stable point > release and my suggested route for the update to take to get there > would be very useful. > Hi all, Since Tomas and Ola have reviewed the patch and we have had some discussion which makes it seem like this is the most sensible approach to the vulnerability given the constraints, I wonder if the Security team could weigh in. I have forwarded my initial message and the patch to Magnus Holngren (the uw-imap maintainer) and also added him as a recipient of this message, as he may wish to be the one to upload to unstable and coordinate the future point release inclusion. I ask for some indication now from the security team and/or the maintainer since I don't think it makes sense to fix this only in jessie and not in stretch/buster/sid. Regards, -Roberto -- Roberto C. Sánchez
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
On Sat, Dec 22, 2018 at 10:27:18PM -0500, Roberto C. Sánchez wrote: > [note: I am not subscribed to debian-security; please keep me or > debian-lts addressed on replies] > > If this seems like a sensible approach, I propose to apply the attached > patch to uw-imap 8:2007f~dfsg-5 (the current stretch/buster/sid version) > to create version 8:2007f~dfsg-6 for upload to sid and eventual > inclusion in stretch (perhaps via a point release) and then also in > parallel create a 8:2007f~dfsg-4+deb8u1 package for upload to jessie. > > Please reply with your comments. In particular, feedback from the > security team on the appropriateness of this for a stable point release > and my suggested route for the update to take to get there would be very > useful. > Hi all, Since Tomas and Ola have reviewed the patch and we have had some discussion which makes it seem like this is the most sensible approach to the vulnerability given the constraints, I wonder if the Security team could weigh in. I have forwarded my initial message and the patch to Magnus Holngren (the uw-imap maintainer) and also added him as a recipient of this message, as he may wish to be the one to upload to unstable and coordinate the future point release inclusion. I ask for some indication now from the security team and/or the maintainer since I don't think it makes sense to fix this only in jessie and not in stretch/buster/sid. Regards, -Roberto -- Roberto C. Sánchez
Re: Jessie update of qtbase-opensource-src?
El viernes, 28 de diciembre de 2018 18:35:00 -03 Ola Lundqvist escribió: > Hi > > I started to look at excluding the uploaders and just include the > maintainer but it turned out to be problematic. At least to make it a > general thing. I can make a dirty hack but I do not think that would be > very useful since we do not contact you that often. > > The problem is that the uploaders and maintainers are reported the same in > https://packages.qa.debian.org/q/qtbase-opensource-src.rdf > or more generally > https://packages.qa.debian.org/$section/$package.rdf > > Do anyone know why this is so, and whether we have any other source of data > to conclude this? Without actually parsing html content... I can only think on grepping the current output of your scripts. If it contains "lists" or maybe even the typical debian's mailing list string in them, just keep that entry. Thanks for looking into this! -- The box said 'Requires Windows 95 or better'. So I installed Linux. Anonymous 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.
Re: phpmyadmin / CVE-2016-5739.patch
Should we check for ~ character too? Sent from a phone Den lör 29 dec. 2018 14:03Brian May skrev: > Ola Lundqvist writes: > > > My conclusion however is about the same as you. I do not think many are > > using the transformations so I think we can safely remove that. > > Another option is to make a check for .. in the filename, because I think > > we can safely assume an attacher do not have write permission in the > > plugins directory, or can that be a problem too? > > I would think this should work too. If we are sure we are 100% > preventing an attacker "escaping" the plugins directory that is. > -- > Brian May >
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello! pe 28. jouluk. 2018 klo 9.27 Jan Ingvoldstad (jan-debian-lts-2...@oyet.no) kirjoitti: > > On 2018-12-27 18:51, Lars Tangvald wrote: > > > Upgrading to 5.6 would be less risky than MariaDB 10.1, but it's a > > similar sort of risk. > > I don't know what the risk with switching to MariaDB 10.1 would be, but > as a general principle, MariaDB lags behind (the already annoyingly > delayed) Oracle security patches often days, sometimes weeks. Just to set facts clear: most of the Oracle CVE's are fixed in MariaDB releases way before the Oracle releases, some times even 6 months ahead. What happens when the Oracle CVEs are released is to a large degree just an update to the list of CVEs on what version of MariaDB fixed what. Sometimes there for sure are cases when Oracle publishes something first, but it would be very wrong to say that MariaDB is in any way 'annoyingly delayed'. If we take as an example MySQL 5.5.62 released on 2018-10-22, it contained the following CVE fixes: - CVE-2018-3133 - Fixed in MariaDB 5.5.59 released on 2018-01-19 - CVE-2018-3174 - Fixed in MariaDB 5.5.62 released on 2018-10-26 - CVE-2018-3282 - Fixed in MariaDB 5.5.62 released on 2018-10-26 Source: https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-62.html https://mariadb.com/kb/en/library/mariadb-5559-release-notes/ https://mariadb.com/kb/en/library/mariadb-5562-release-notes/ https://mariadb.com/kb/en/library/security/ However, the severity if these CVEs vary very much and there are many details that blur what should be used as a relevant argument and what not, so I would not use this as a main factor in the decision. > Based on our experience with a few thousand databases, though, upgrading > from 5.5 to 5.6 is as good as invisible for DB users and software using > MySQL. > > A few users noticed the differences between MySQL 5.5 and MariaDB 10.0 > (5.6-based), nearly no-one noticed the upgrade from MariaDB 10.0 to 10.3. MariaDB has a tradition of honoring backwards compatibility, thus the upgrade from 10.0 to 10.3 should go pretty smooth, but to be safe we should maybe build some gitlab-ci.yml file to test this particular scenario extensively to be safer. Pull requests on https://salsa.debian.org/mariadb-team/mariadb-10.3/pipelines are welcome :) > It would be very welcome if upgrade scripts in Debian would substitute > configuration options correctly, with the usual dselect option list of > "compare, keep current, install package maintainer's" versions. Good idea! Would you want to contribute such functionality to the MariaDB preinstall scripts (or even upstream mariadb_upgrade binary)? https://wiki.debian.org/Teams/MySQL/patches https://mariadb.org/get-involved/ > The risk mostly lies in software relying on the removed features listed > in the URL you linked > (https://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html#mysql-nutshell-removals). > > As a side note, anyone using MySQL WorkBench with MariaDB 10.x or MySQL > 5.5 will probably be very annoyed about the version warnings. I expect > the current issues with 5.6 compatibility alerts to be fixed. :) This "bug" has been known for years and it does not look like Oracle will fix their product to be any more MariaDB-compatible (https://www.mysql.com/products/workbench/). Only thing here is to either patch it in Debian, or suggest users to migrate to alternatives (https://mariadb.com/kb/en/library/graphical-and-enhanced-clients/).
