privoxy: Update to 3.0.24
Message ID | 1453594308-7026-1-git-send-email-matthias.fischer@ipfire.org |
---|---|
State | Superseded |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.tremer.info [172.28.1.200]) by septima.ipfire.org (Postfix) with ESMTP id E1D796095F for <patchwork@ipfire.org>; Sun, 24 Jan 2016 01:11:54 +0100 (CET) Received: from hedwig.ipfire.org (localhost [IPv6:::1]) by mail01.ipfire.org (Postfix) with ESMTP id 97FB541B1; Sun, 24 Jan 2016 01:11:54 +0100 (CET) Received: from Devel.localdomain (p5DD82FA3.dip0.t-ipconnect.de [93.216.47.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 486033F04 for <development@lists.ipfire.org>; Sun, 24 Jan 2016 01:11:52 +0100 (CET) From: Matthias Fischer <matthias.fischer@ipfire.org> To: development@lists.ipfire.org Subject: [PATCH] privoxy: Update to 3.0.24 Date: Sun, 24 Jan 2016 01:11:48 +0100 Message-Id: <1453594308-7026-1-git-send-email-matthias.fischer@ipfire.org> X-Mailer: git-send-email 2.7.0 X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <http://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <http://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Message
Matthias Fischer
Jan. 24, 2016, 11:11 a.m. UTC
Changelog - in short:
- Security fixes (denial of service):
- Prevent invalid reads in case of corrupt chunk-encoded content.
CVE-2016-1982. Bug discovered with afl-fuzz and AddressSanitizer.
- Remove empty Host headers in client requests.
Previously they would result in invalid reads. CVE-2016-1983.
Bug discovered with afl-fuzz and AddressSanitizer.
Also several bug fixes as well as general, action file, and documentation improvements.
For details see:
http://www.privoxy.org/announce.txt
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
---
lfs/privoxy | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Comments
Hi, there is no privoxy in IPFire :) What branch is this patch for? -Michael On Sun, 2016-01-24 at 01:11 +0100, Matthias Fischer wrote: > Changelog - in short: > - Security fixes (denial of service): > - Prevent invalid reads in case of corrupt chunk-encoded content. > CVE-2016-1982. Bug discovered with afl-fuzz and AddressSanitizer. > - Remove empty Host headers in client requests. > Previously they would result in invalid reads. CVE-2016-1983. > Bug discovered with afl-fuzz and AddressSanitizer. > > Also several bug fixes as well as general, action file, and > documentation improvements. > > For details see: > http://www.privoxy.org/announce.txt > > Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org> > --- > lfs/privoxy | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/lfs/privoxy b/lfs/privoxy > index bc4848a..de650a2 100644 > --- a/lfs/privoxy > +++ b/lfs/privoxy > @@ -1,7 +1,7 @@ > #################################################################### > ########### > # > # > # IPFire.org - A linux based firewall > # > -# Copyright (C) 2007-2015 IPFire Team <info@ipfire.org> > # > +# Copyright (C) 2007-2016 IPFire Team <info@ipfire.org> > # > # > # > # This program is free software: you can redistribute it and/or > modify # > # it under the terms of the GNU General Public License as published > by # > @@ -24,14 +24,14 @@ > > include Config > > -VER = 3.0.23 > +VER = 3.0.24 > THISAPP = privoxy-$(VER) > DL_FILE = $(THISAPP)-stable-src.tar.gz > DL_FROM = $(URL_IPFIRE) > DIR_APP = $(DIR_SRC)/$(THISAPP) > TARGET = $(DIR_INFO)/$(THISAPP) > PROG = privoxy > -PAK_VER = 2 > +PAK_VER = 3 > > DEPS = "" > > @@ -43,7 +43,7 @@ objects = $(DL_FILE) > > $(DL_FILE) = $(DL_FROM)/$(DL_FILE) > > -$(DL_FILE)_MD5 = bbe47d5ff1a54d9f9fc93a160532697f > +$(DL_FILE)_MD5 = 44a47d1a5000db8cccd61ace0e25e7f7 > > install : $(TARGET) > > @@ -53,7 +53,7 @@ download :$(patsubst %,$(DIR_DL)/%,$(objects)) > > md5 : $(subst %,%_MD5,$(objects)) > > -dist: > +dist: > $(PAK) > > #################################################################### > ###########
Hi Michael, On 24.01.2016 20:42, Michael Tremer wrote: > there is no privoxy in IPFire :) I know...but I'm working on it... ;-) > What branch is this patch for? Named 'privoxy', based on current 'next'. Details: http://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=shortlog;h=refs/heads/privoxy Diskussion (*thousands* of "comitted prospects"! :) ): https://forum.ipfire.org/viewtopic.php?f=4&t=8441&hilit=privoxy#p55972 To be honest: Its just a leftover from the 'FireFilter'-Project (remember?). *sigh!* The first Copfilter-part I got running on IPFire. Besides: I didn't hear anything from Kare, I don't know if he will ever be in a state/mood/or anything working on this. Its running here on my productive machine and its doing its job. Best, Matthias
Hi, I got some short questions about using the feature "FEATURE_DYNAMIC_PCRE" in privoxy and would be grateful if someone could give me some shorts hint or explanations. In the past this feature was always disabled through the configure-option "--disable-dynamic-pcre". The only explanation 'privoxy' gives is the 'configure --help' text: "--disable-dynamic-pcre Use the built-in, static pcre, even if libpcre is available". The 'privoxy' status tells me: "FEATURE_DYNAMIC_PCRE => Dynamically link to the PCRE library. This is set automatically by ./configure if you do not have libpcre installed. Dynamically linking to an external libpcre is recommended as the one that is distributed with Privoxy itself is outdated and lacks various features and bug-fixes you may be interested in." So for testing purposes - being curious - I enabled this feature by deleting "--disable-dynamic-pcre" from 'privoxy'-lfs-file. Everything was built, everything seems to be running fine. But although I searched for a better statement what this option really does I didn't find some and now I would like to know what are the dis/advantages of this option. Disable or enable dynamic PCRE - what is better for 'privoxy' and IPFire? And what does it do? Some short statements or hints would be sufficient! Sorry, if this seems to be some dumb question, but I want to be sure... Best, Matthias
Hi, indeed. Never bundle a library. Never. Never. Never. PCRE had some severe security issues recently and I assume that these are not fixed in the privoxy release tarball. If we fix the issues in pcre it will automatically be fixed in privoxy too when dynamically linked. If pcre is statically linked we usually wouldn't know that a vulnerable version of pcre is in there and even if we would this would create extra work to fix the same issue there, too. So just don't do it. They should actually remove the bundled version upstream. -Michael On Mon, 2016-01-25 at 21:25 +0100, Matthias Fischer wrote: > Hi, > > I got some short questions about using the feature > "FEATURE_DYNAMIC_PCRE" in privoxy and would be grateful if someone could > give me some shorts hint or explanations. > > In the past this feature was always disabled through the > configure-option "--disable-dynamic-pcre". The only explanation > 'privoxy' gives is the 'configure --help' text: > > "--disable-dynamic-pcre Use the built-in, static pcre, even if > libpcre is available". > > The 'privoxy' status tells me: > "FEATURE_DYNAMIC_PCRE => Dynamically link to the PCRE library. This is > set automatically by ./configure if you do not have libpcre installed. > Dynamically linking to an external libpcre is recommended as the one > that is distributed with Privoxy itself is outdated and lacks various > features and bug-fixes you may be interested in." > > So for testing purposes - being curious - I enabled this feature by > deleting "--disable-dynamic-pcre" from 'privoxy'-lfs-file. Everything > was built, everything seems to be running fine. But although I searched > for a better statement what this option really does I didn't find some > and now I would like to know what are the dis/advantages of this option. > > Disable or enable dynamic PCRE - what is better for 'privoxy' and > IPFire? And what does it do? Some short statements or hints would be > sufficient! > > Sorry, if this seems to be some dumb question, but I want to be sure... > > Best, > Matthias > >
Hi, On 29.03.2016 16:04, Michael Tremer wrote: > Hi, > > indeed. Never bundle a library. Never. Never. Never. > > PCRE had some severe security issues recently and I assume that these are not > fixed in the privoxy release tarball. If we fix the issues in pcre it will > automatically be fixed in privoxy too when dynamically linked. Thanks - I thought of something like that but wasn't sure. Prior to my question I deleted "--disable-dynamic-pcre" from the privoxy lfs-file and will keep it this way. By the way - feedback is sparse, as ever - but how are the chances of 'privoxy' becoming an official addon? Anything I could improve? Best, Matthias
Hi, I am still not sure what benefit this will bring to the IPFire users. What will it bring to addition of squidGuard and the "URL Filter"? I know that it can remove ads within the HTML, but as pretty much most of the websites are encrypted where I think this would be useful, what is the point? Technically I have nothing against it. I just cannot see where the benefit is to build and maintain this. -Michael On Tue, 2016-03-29 at 17:48 +0200, Matthias Fischer wrote: > Hi, > > On 29.03.2016 16:04, Michael Tremer wrote: > > > > Hi, > > > > indeed. Never bundle a library. Never. Never. Never. > > > > PCRE had some severe security issues recently and I assume that these are > > not > > fixed in the privoxy release tarball. If we fix the issues in pcre it will > > automatically be fixed in privoxy too when dynamically linked. > Thanks - I thought of something like that but wasn't sure. > > Prior to my question I deleted "--disable-dynamic-pcre" from the privoxy > lfs-file and will keep it this way. > > By the way - feedback is sparse, as ever - but how are the chances of > 'privoxy' becoming an official addon? Anything I could improve? > > Best, > Matthias >