Re: [SECURITY] [DLA 1865-1] sdl-image1.2 security update
> I don't think it's explicitly documented; I inferred it from these > rules: > > 1. Corrections should be sent to the same recipients as the original > incorrect information. > 2. All messages sent to debian-lts-announce about package updates > should be numbered DLAs. > 3. DLAs that are related to prior DLAs should use the same first part > and an incremented second part. Sounds reasonable. Thanks! regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: [SECURITY] [DLA 1865-1] sdl-image1.2 security update
On Sat, 2019-07-27 at 18:30 -0300, Hugo Lefeuvre wrote: > Hi Ben, > > > > > For Debian 8 "Jessie", these problems have been fixed in version > > > > 1.2.12-5+deb9u2. > > > > > > Typo: version number is 1.2.12-5+deb8u2, not 1.2.12-5+deb9u2. > > > > The proper way to make such a correction is to issue a -2 advisory with > > the correct information and a note about what changed. > > Thanks, I wasn't aware of this. I can't find any information about it in > our documentation, did I miss something? > > (just in case: this is not a regression, just a typo in the advisory) I don't think it's explicitly documented; I inferred it from these rules: 1. Corrections should be sent to the same recipients as the original incorrect information. 2. All messages sent to debian-lts-announce about package updates should be numbered DLAs. 3. DLAs that are related to prior DLAs should use the same first part and an incremented second part. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
Re: [SECURITY] [DLA 1865-1] sdl-image1.2 security update
Hi Ben, > > > For Debian 8 "Jessie", these problems have been fixed in version > > > 1.2.12-5+deb9u2. > > > > Typo: version number is 1.2.12-5+deb8u2, not 1.2.12-5+deb9u2. > > The proper way to make such a correction is to issue a -2 advisory with > the correct information and a note about what changed. Thanks, I wasn't aware of this. I can't find any information about it in our documentation, did I miss something? (just in case: this is not a regression, just a typo in the advisory) regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Re: [SECURITY] [DLA 1865-1] sdl-image1.2 security update
On Sat, 2019-07-27 at 16:04 -0300, Hugo Lefeuvre wrote: > On Sat, Jul 27, 2019 at 03:30:14PM -0300, Hugo Lefeuvre wrote: > > Package: sdl-image1.2 > > Version: 1.2.12-5+deb9u2 > > CVE ID : CVE-2018-3977 CVE-2019-5051 CVE-2019-5052 CVE-2019-7635 > > CVE-2019-12216 CVE-2019-12217 CVE-2019-12218 > > CVE-2019-12219 > > CVE-2019-12220 CVE-2019-12221 CVE-2019-1 > > > > [...] > > > > For Debian 8 "Jessie", these problems have been fixed in version > > 1.2.12-5+deb9u2. > > Typo: version number is 1.2.12-5+deb8u2, not 1.2.12-5+deb9u2. The proper way to make such a correction is to issue a -2 advisory with the correct information and a note about what changed. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Re: [SECURITY] [DLA 1865-1] sdl-image1.2 security update
On Sat, Jul 27, 2019 at 03:30:14PM -0300, Hugo Lefeuvre wrote: > Package: sdl-image1.2 > Version: 1.2.12-5+deb9u2 > CVE ID : CVE-2018-3977 CVE-2019-5051 CVE-2019-5052 CVE-2019-7635 > CVE-2019-12216 CVE-2019-12217 CVE-2019-12218 CVE-2019-12219 > CVE-2019-12220 CVE-2019-12221 CVE-2019-1 > > [...] > > For Debian 8 "Jessie", these problems have been fixed in version > 1.2.12-5+deb9u2. Typo: version number is 1.2.12-5+deb8u2, not 1.2.12-5+deb9u2. -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
On tomcat FTBFS.
Hi,
I don't think the link you gave on commit [fe932dd39d] is the reason for
FTBFS. I tried building on a VM that matches the certificate date and it
was successful. I also tried disabling all ssl related tests and was fine.
While doing these all I found TestSendFile test is the culprit. In
CVE-2017-5647 security patch a good amount of changes is applied for
SendFile*.java and *Nio2*.java. These are mostly about conditions on how
long the socket of sendfile keep active and to take away from it. But I
couldn't see any those change in its test file. Please take a look on
the attached patch. :)
--abhijith
From: Markus Koschany
Date: Sat, 15 Apr 2017 17:25:03 +0200
Subject: CVE-2017-5647
Bug-Debian: https://bugs.debian.org/860068
Origin: http://svn.apache.org/r1788999
---
java/org/apache/coyote/AbstractProtocol.java | 7 +-
.../apache/coyote/http11/Http11AprProcessor.java | 38 +++
.../apache/coyote/http11/Http11Nio2Processor.java | 11 +++-
.../apache/coyote/http11/Http11NioProcessor.java | 26 ++--
java/org/apache/tomcat/util/net/AprEndpoint.java | 49 +-
java/org/apache/tomcat/util/net/Nio2Endpoint.java | 25 ---
java/org/apache/tomcat/util/net/NioEndpoint.java | 76 --
.../tomcat/util/net/SendfileKeepAliveState.java| 39 +++
java/org/apache/tomcat/util/net/SendfileState.java | 37 +++
9 files changed, 222 insertions(+), 86 deletions(-)
create mode 100644 java/org/apache/tomcat/util/net/SendfileKeepAliveState.java
create mode 100644 java/org/apache/tomcat/util/net/SendfileState.java
diff --git a/java/org/apache/coyote/AbstractProtocol.java b/java/org/apache/coyote/AbstractProtocol.java
index 9886cef..cabfbf6 100644
--- a/java/org/apache/coyote/AbstractProtocol.java
+++ b/java/org/apache/coyote/AbstractProtocol.java
@@ -710,10 +710,9 @@ public abstract class AbstractProtocol implements ProtocolHandler,
release(wrapper, processor, false, true);
} else if (state == SocketState.SENDFILE) {
// Sendfile in progress. If it fails, the socket will be
-// closed. If it works, the socket will be re-added to the
-// poller
-connections.remove(socket);
-release(wrapper, processor, false, false);
+// closed. If it works, the socket either be added to the
+// poller (or equivalent) to await more data or processed
+// if there are any pipe-lined requests remaining.
} else if (state == SocketState.UPGRADED) {
// Don't add sockets back to the poller if this was a
// non-blocking write otherwise the poller may trigger
diff --git a/java/org/apache/coyote/http11/Http11AprProcessor.java b/java/org/apache/coyote/http11/Http11AprProcessor.java
index e4ecd1a..a08da6f 100644
--- a/java/org/apache/coyote/http11/Http11AprProcessor.java
+++ b/java/org/apache/coyote/http11/Http11AprProcessor.java
@@ -37,6 +37,7 @@ import org.apache.tomcat.util.ExceptionUtils;
import org.apache.tomcat.util.net.AbstractEndpoint.Handler.SocketState;
import org.apache.tomcat.util.net.AprEndpoint;
import org.apache.tomcat.util.net.SSLSupport;
+import org.apache.tomcat.util.net.SendfileKeepAliveState;
import org.apache.tomcat.util.net.SocketStatus;
import org.apache.tomcat.util.net.SocketWrapper;
@@ -197,22 +198,31 @@ public class Http11AprProcessor extends AbstractHttp11Processor {
// Do sendfile as needed: add socket to sendfile and end
if (sendfileData != null && !getErrorState().isError()) {
sendfileData.socket = socketWrapper.getSocket().longValue();
-sendfileData.keepAlive = keepAlive;
-if (!((AprEndpoint)endpoint).getSendfile().add(sendfileData)) {
-// Didn't send all of the data to sendfile.
-if (sendfileData.socket == 0) {
-// The socket is no longer set. Something went wrong.
-// Close the connection. Too late to set status code.
-if (log.isDebugEnabled()) {
-log.debug(sm.getString(
-"http11processor.sendfile.error"));
-}
-setErrorState(ErrorState.CLOSE_NOW, null);
+if (keepAlive) {
+if (getInputBuffer().available() == 0) {
+sendfileData.keepAliveState = SendfileKeepAliveState.OPEN;
} else {
-// The sendfile Poller will add the socket to the main
-// Poller once sendfile processing is complete
-sendfileInProgress = true;
+sendfileData.keepAliveState = SendfileKeepAliveState.PIPELINED;
+}
+} else {
+sendfileData.keepAliveState = SendfileKeepAliveState.NONE;
+}
Re: MariaDB uploaders: Please use Salsa and Salsa-CI
Hi, On 25/07/2019 22:03, Otto Kekäläinen wrote: > Hello Emilio and anybody else who might at some point upload MariaDB > to jessie-security or stretch-security! > > Please use as the starting point the latest version in the MariaDB > team Salsa repos > - mariadb-10.0 branch 'jessie' > - mariadb-10.1 branch 'stretch' (from 2020 onwards LTS) > > I have prepared there Gitlab-CI automation that does not affect the > package itself in any way, but does help quite a bit in ensuring that > whatever you upload is well tested and unlikely to cause regressions. > > Do not just checkout the latest version in Jessie or Stretch, but work > using the repository instead. Also, please push to the branch when you > are done. I am happy to include LTS maintainers in the mariadb-team so > you can use the official repository. (Emilio is already there.) > > Repo and example of pipeline: > - https://salsa.debian.org/mariadb-team/mariadb-10.0/pipelines > - https://salsa.debian.org/mariadb-team/mariadb-10.1/pipelines > > Slides on my talk on MariaDB packaging and Salsa-CI/Gitlab-CI use in > case you are interested in the longer story: > https://www.slideshare.net/ottokekalainen/how-mariadb-packaging-uses-salsaci-to-ensure-smooth-upgrades-and-avoid-regressions > > > - Otto > > PS. I've done this all assuming the security uploads in this case do > allow changes to the debian/gitlab-ci.yml file since it does not cause > functional changes to the package itself and is perfectly safe. Thanks for improving security by providing easier testing :) I referenced your e-mail at: https://wiki.debian.org/LTS/TestSuites Cheers! Sylvain
