privoxy: Update to 3.0.24

  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(-)
  

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
>