Bug#1049926: squid: 6.1 autopkgtest failures and FTP support

[Amos Jeffries]

Forwarded 1049926 https://bugs.squid-cache.org/show_bug.cgi?id=5290
thanks

Upstream patch will be included in upcoming 6.2 release.

Bug#1002854: Missing C API protection in socks.h

[Amos Jeffries]

Package: dante
Version:  1.4.2+dfsg-7
Tags: + patch

The /usr/include/socks.h file installed by libsocksd0-dev is missing 
precompiler wrappers to protect against include loops. It is good 
practice with modern software to provide these wrappers in library 
headers files and avoid mistakes with third-party attempts to provide 
their own.Description: Missing C API protections
 The installed socks.h header lacks protection for C API
 being built by C++ compilers when included into C++ code.
 As well as missing protection against circular/repeated
 includes.
Author: Amos Jeffries 
Last-Update: 2021-12-30
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

--- dante-1.4.2+dfsg.orig/capi/socks.h.in
+++ dante-1.4.2+dfsg/capi/socks.h.in
@@ -43,6 +43,9 @@
 
 /* $Id: socks.h.in,v 1.22 2009/12/19 14:14:28 karls Exp $ */
 
+#ifndef __DANTE__SOCKS_H_
+#define __DANTE__SOCKS_H_
+
 #include 
 #include 
 
@@ -80,6 +83,10 @@
 #define write Rwrite
 #define writev Rwritev
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 int
 SOCKSinit(char *progname);
 /*
@@ -119,3 +126,9 @@
 
 int Rlisten(int, int);
 int Rselect(int, fd_set *, fd_set *, fd_set *, struct timeval *);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __DANTE__SOCKS_H_ */

Bug#984351: squid: ftbfs with GCC-11

[Amos Jeffries]

FYI, these build issues have already been resolved upstream in the 
Squid-4.16+ waiting for upload after the current Debian freeze is over.


Amos

Bug#986804: CVE-2021-28116

[Amos Jeffries]

forwarded -1 https://bugs.squid-cache.org/show_bug.cgi?id=5131
thanks

Bug#966395: Double building?

[Amos Jeffries]

On 7/02/21 1:24 pm, Santiago Garcia Mantinan wrote:

On current build we ship usr/share/squid/mime.conf on squid-common, but on
my build it gets installed on etc/squid/mime.conf, which place is the right
one?


My current guess looking at things around the package is that it is ok on my
build to have it in etc/squid, plus is a good place for a config file, so...
everything looks ok.



Yes. It is supposed to be a config file to tell Squid where to load 
static web content from (based on FTP mime type).



Amos

Bug#966395: Double building?

[Amos Jeffries]

On Fri, 11 Dec 2020 08:10:02 +0100 Santiago Garcia Mantinan wrote:


For what I know, the openssl enabled binary will have all the features, it
is only that some options are gnutls specific, and this options are not
standard ones, I mean, the standard config or a normal cache usage doesn't
have any of those options, right?


The values configured for all the tls-options=, tls-flags=, etc are 
library specific strings.


There is also the GnuTLS ability to load multiple certificates for 
virtual-hosting HTTPS websites which OpenSSL simply cannot do itself. I 
know a few users are liking that.



Amos

Bug#966395: Any plans on doing this for Bullseye?

[Amos Jeffries]

On 9/12/20 12:35 pm, Luigi Gangitano wrote:

Hi Amos,

Can you please tell me more about the technicalities needed to support 
libssl1?


By "technicality" I was referring to the GPL clause which allows us to 
violate the OpenSSL advertising requirement simply by Debian considering 
OpenSSL part of the OS libraries.




I would like to make a plan for finally enable SSL/TLS in 
squid, if possible.




Okay.

People who don't want the SSL-Bump feature and have already configured 
with GnuTLS specific options in squid.conf will find Squid no longer 
able to load or not running correctly with the OpenSSL-enabled binary.


What do you think of an squid-sslbump package that installs squid built 
against openssl ?


Can we build twice in the same source packaging?


Amos

Bug#966395: Any plans on doing this for Bullseye?

[Amos Jeffries]

On 2/12/20 10:36 pm, Santiago Garcia Mantinan wrote:

I'd like to know if there are any plans on having Bullseye version compiled
with --with-openssl,



I am leaving the decision to Luigi for libssl1 builds.


For my part I will only add it for libssl3 or later where we do not have 
to rely on a technicality. The upstream work still needs some help 
testing changes against libssl 1.1.



Amos

Bug#969357: squid-4.6: segfault for unknown reason

[Amos Jeffries]

Control: retitle -1 squid-4.6: segfault for unknown reason
Control: tags -1 + moreinfo

On Mon, 31 Aug 2020 23:45:28 -0400 js1 wrote:
> Package: squid
> Version: 4.6-1+deb10u4
> Severity: normal
> 
> Dear Maintainer,
> 
> Squid segfaults but seems usable.  No segfaults until this current version 
> (4.6-1+deb10u4). 
> 

Please install the debug symbols package (squid-dbgsym) and provide a
backtrace from your segfault if it occurs again.

Upstream provide details on how to obtain backtraces without downtime
from a running Squid proxy at
.


Amos

Bug#968473: Newer alpha available

[Amos Jeffries]

Package: libssl3
Version: 3.0.0~~alpha4-1
Severity: important

Dear Maintainer,

Please update the package version in Debian experimental to latest
alpha. There have been many feature additions and deprecation's which
software checking libssl3 support need to be tested against.


Cheers,
Amos

Bug#966395: Please support SSL bumping with '--with-openssl' configure option

[Amos Jeffries]

On Mon, 27 Jul 2020 17:54:01 -0400 Simon Deziel wrote:
> 
> Now that OpenSSL is available under the Apache License v. 2.0, there
> should no longer be any incompatibility with Debian.


Apache is not yet available with the new License and will likely not be
until the next Debian major release after it becomes available.


FWIW; Upstream is working on a few updates necessary for Squid to build
with libssl3 so this should happen normally when all the supporting
versions are available to install.

Amos

Bug#958708: squid: Squid is still unusable

[Amos Jeffries]

Control: notfound 958708 squid/4.11-4

On Tue, 12 May 2020 13:11:19 +0200 mahashakti89 wrote:
> Package: squid
> Version: 4.11-4
> Followup-For: Bug #958708
> 
> Same problem as described above . Squid would'nt start. I got following
> message on upgrade :
> 
...
> 
> mai 12 13:08:15 ishwara systemd[1]: Starting Squid Web Proxy Server...
> mai 12 13:08:15 ishwara squid[52706]: 2020/05/12 13:08:15| FATAL: failed to 
> open /run/squid/squid.pid: (13) Permission denied
> mai 12 13:08:15 ishwara squid[52706]: exception location: File.cc(190) 
> open

Which is a completely different problem from the one this bug is about.


Amos

Bug#956581: Fwd: squid: Starting sdquid by systemd fails when local fs /var is not ready.

[Amos Jeffries]

On Mon, 13 Apr 2020 11:27:31 +0200 Tilman Heinrich wrote:
> 
> I installed squid early when I set up a special router. The start
> repeatedlyfails by inaccessibility of files at the dedicated /var
> partition (dev/md1). The result was a stopped squid service due to a
> failed restart.
> 
> The first solution was to change the triggered path for restart in
> /etc/resolvconf/update-libc.d/squid from /usr/sbin to /var/log. Later I
> found that the unit decription in the systemd configuration file
> /lib/systemd/system/squid.service is incomlete, because of the omitted
> depency for the local-fs.target. So I copied the file to
> /etc/systemd/system/squid.service and added the missing depency to the
> "After=" statement - this should be the default for the unit description
> under /lib/systemd/system/ when started up by systemd.


The FHS paths are supposed to be mounted by systemd basic.target which
is itself supposed to be automatically added to the dependencies by
systemd itself.

It sounds like the non-local mounting is done in a non-systemd way on
your filesystem, or with some mount options that confuse systemd (not hard).


To integrate local requirements with squid.service defaults, run:

 sudo systemctl edit squid.service

then enter any systemd settings you need for the local customizations.
AFAIK, the settings there will be added to the Squid package ones. So
should be no need to copy the normal squid.service contents.


Amos

Bug#960819: squid command failure without systemd

[Amos Jeffries]

On Mon, 18 May 2020 18:27:04 -0400 Sergio Durigan Junior wrote:
> On Monday, May 18 2020, I wrote:
> 
> > Just a few more details I've been able to gather this afternoon.
> >
> > I'm using a Debian sid VM where I installed sysvinit to replace systemd.
> > I wasn't able to reproduce the problem reported above, even after
> > activating the apparmor profile before upgrading.
> >
> > If you look at the /etc/init.d/squid script, you can see that the
> > startup function does create the /run/squid/ directory.
> >
> > I will need more info to investigate this bug.
> 
> I submitted
> https://salsa.debian.org/squid-team/squid/-/merge_requests/13 to fix the
> latent bug that I am experiencing when upgrading to the latest squid
> (unstable) and when the apparmor profile is enabled.
> 

Good catch. Thanks.


But that is not related to this problem. Apparmor profile and all
package install/configure is fine for access to the /run/squid directory
in latest packages.

The issue is seen with manually run commands directly using the squid
binary. Debian init scripts are caught by systemctl and do not show
issues - though I expect it will be seen on Blends or installs without
systemd at all (eg Devaun).


The commands to replicate are:

1) the command documented as required to initialize caches before
starting Squid:

# squid -z -f /etc/squid/cache.cnf
2020/05/23 19:11:39| FATAL: failed to open /run/squid/squid.pid: (2) No
such file or directory
exception location: File.cc(190) open

# tail -n 20 /var/log/squid/cache.log
2020/05/23 19:11:39| FATAL: failed to open /run/squid/squid.pid: (2) No
such file or directory
exception location: File.cc(190) open



2) command required to start multiple instances of Squid (may be run by
a custom init script):

# squid -n gateway -f /etc/squid/gateway.cnf
# squid -n cache -f /etc/squid/cache.cnf
# tail -n 20 /var/log/squid/cache.log
2020/05/23 19:10:32| FATAL: failed to open /run/squid/squid.pid: (2) No
such file or directory
exception location: File.cc(190) open

2020/05/23 19:10:32| FATAL: failed to open /run/squid/squid.pid: (2) No
such file or directory
exception location: File.cc(190) open

#



To fix we will either have to find a way to stop systemd erasing the
/run/squid directory, or patch the Squid code to create the PID file
path as-needed not just the file itself.
 For the latter, PRs are welcome upstream. I do not currently have time
to work on this myself - thus the bug report.


Amos

Bug#960819: squid command failure without systemd

[Amos Jeffries]

Package: squid
Version: 4.11-5
Severity: grave


Since the /run/squid directory now depends on systemd squid.service file
for existence the 'squid' binary cannot be run.

This breaks all non-systemd init systems, multi-tenant installations,
and scripts running the squid binary for control commands.


When started without the "service squid" systemd-specific command Squid
produces:

2020/05/17 17:07:48| FATAL: failed to open /run/squid/squid.pid: (2) No
such file or directory
exception location: File.cc(190) open

Bug#925836: Your mail

[Amos Jeffries]

On 10/02/20 10:45 am, Andreas Beckmann wrote:
> Control: tags -1 - buster +  sid bullseye .
> 
> On Sun, 9 Feb 2020 17:54:03 +1300 Amos Jeffries wrote:
>> tags 925836 - sid bullseye + buster
> 
> What's the point of tagging this bug (squid: ftbfs with GCC-9) as
> affecting buster? There is no (and never will be) gcc-9 in buster, so no
> need for a useless RC bug there.
> 
> Andreas
> 

Only the buster package has any relevance to GCC-9. I expect this to
impact anyone doing a partial upgrade of base system and/or compiler but
not 'on hold' services.

I'm not sure why this did not get closed already with the GCC-9
migration. We were asked to leave to that team.

Amos

Bug#950237: squid CVE-2019-18676 and CVE-2019-12523 status

[Amos Jeffries]

Control: 950237 fixed 4.9

On Thu, 30 Jan 2020 11:53:30 + Christian Ruppert wrote:
> Package: squid
> Version: 3.5.23-5+deb9u1
> 
> Hi,
> 
> I just wanted to ask if there's any ETA for 
> https://security-tracker.debian.org/tracker/CVE-2019-18676 and 
> https://security-tracker.debian.org/tracker/CVE-2019-12523 for jessie
> and buster. The other ones had been fixed already. Patches are
> available according to the security tracker.


There is not. Whether it happens at all will depend on the LTS backporters.

The patch available assumes some features of Squid-4 and C++11 compiler
capabilities not supported in Squid-3.x. So the port has some work required.

Amos

Bug#940785: please drop transitional package squid3 from src:squid

[Amos Jeffries]

Unfortunately popcon is showing that there are still at least 1500
installations that have not upgraded from squid3 non-transitional packages.

Since this package exists to ease the difficult file re-naming those
installations may face we need to keep it around for a while longer.

Amos

Bug#934208: Open file limits not set in systemd unit

[Amos Jeffries]

On Thu, 8 Aug 2019 10:36:13 +0200 (CEST) Sammy Atmadja wrote:
>   
>   
>   
>   
>   
>  
> /etc/init.d/squid increases the open file limit (ulimit -n 65535) 
>   
>   
>   
>   
>  
> from the default value of 1024. This does not happen when squid   
>   
>   
>   
>   
>  
> is started from systemd, resulting on busy systems in the 
>   
>   
>   
>   
>  
> following errors in /var/log/squid/cache.log :
>   
>   
>   
>   
>  
>   
>   
>   
>   
>   
>  
> 2019/08/08 09:59:19 kid1| WARNING! Your cache is running out of 
> filedescriptors   
>   
>   
>   
>
>


These are not exactly equivalents.

The sysvinit default is to have a rather low FD limitation which
prevents squid.conf being able to set max_filedescriptors to useful
higher values. ulimit is used in that script as a workaround to raise
that limit higher - but it is still an explicit upper limit.

Under systemd the default is not to have any limitation at all. So
squid.conf can raise as high as the admin wants, _except_ when that
limit is set.

When there is a fixed upper limit Squid auto-detects and uses that.
Unfortunately there are still some bugs that needs to be straightened
out upstream for Squid to use the --with-filedescriptors value when
there is *no* specific upper limit provided by the OS.

The first of those fixes is in the pending 4.8 packages. Two more to
follow at a later date (no ETA sorry).

Amos

Bug#933086: squid: squid requests authentication again and again

[Amos Jeffries]

Control: tags 933086 + moreinfo


On Fri, 26 Jul 2019 15:50:25 +0200 Georg Herrmann wrote:
> 
> Hey, what? The browser sends the same request as some moments before,
> with the same authentication data - but suddenly squid challenges an
> authentication again instead to send the correct message 403 forbidden
> 

HTTP is a stateless protocol. Each request is independent of any others.

Please provide a cache.log trace made with these settings:
 debug_options ALL,1 11,2 28,6 29,6


Amos

Bug#932593: squid: started by systemd before local file systems are up and therefore fails

[Amos Jeffries]

On Sun, 21 Jul 2019 12:57:16 +0200 =?UTF-8?B?VGlsbWFubiBCw7bDnw==?= wrote:
> Hi,
> 
> please close the bug report #932593. The problem disappeared after I 
> manually reinstalled the packages systemd and squid („apt --reinstall 
> install systemd squid“). It seems to me that release updates can confuse 
> systemd's startup logic - maybe a hint in the release notes to reinstall 
> systemd after the upgrade might be helpful?
> 


IMO it would be better if we can resolve this without asking people to
(re)install systemd manually.

Were you running a different Squid-4 or a Squid-3 version before this
issue came up?

Do you recall what version of systemd were you running before/after the
issue?


PS. Your local-fs.target suggestion was a good one even though it did
not help here. I intend to take that upstream in the next few days.  I
assume the name and email used for this public report are appropriate
for me to credit the change to you?

AYJ

Bug#923213: squid: Please disable the "Test apparmor" autopkgtest

[Amos Jeffries]

On 8/03/19 6:58 am, Paul Gevers wrote:
> Luigi,
> 
> On 07-03-2019 17:51, Luigi Gangitano wrote:
>> 4.6-2 has just been uploaded with a fix for 923213. I really appreciate
>> the opportunity to let it in Buster.
> 
> Please file an unblock bug. I have one question about the proposed
> solution: you preinst doesn't honor local changes if the package is
> uninstalled (but not purged) and installed again AFAICT.


How so? the preinst script only installs the disable symlink and skips
doing so if there is any existing profile. Everything else is done by
the debhelper script.

This particular chunk of the change is taken verbatim from what Ubuntu
have been using for years without an issue coming up.

Amos



signature.asc
Description: OpenPGP digital signature

Bug#920007: squid: basic_ncsa_auth username case sensitivity

[Amos Jeffries]

On Mon, 21 Jan 2019 18:12:37 +0300 "Matsievskiy S.V." wrote:
>
> After output examination, I learned that squid converts all characters to 
> lowercase.
> In my case, login had uppercase characters in it. So call to basic_ncsa_auth 
> never succeeded.
> 
> In my opinion either squid should not convert characters to lowercase, or it 
> should be clearly stated somewhere that uppercase characters are not allowed.
> 


Due to the security vulnerabilities and issues inherent in allowing
case-sensitive usernames most auth systems operate case-insensitively.
The Squid default is tuned to match those most commonly encountered
environment(s) behaviour.
 (You may find it useful to look up what those security problems are and
consider carefully why so many others prohibit mixed-case accounts.)


The "casesensitive" parameter for auth_param is provided for this
use-case and is already documented under "Basic authentication parameters".
See .



FYI: For ease of testing there are "fake" helper(s) provided for most
Squid helper directives - which only return OK (or equivalent) to Squid.
All official helpers should also provide a "-d" command line option
which delivers their debugging information to cache.log.

I mention this because that bash script does not perform any of the
Squid helper protocol. Which must have been a pain to test against.
For example; I replicated the reported behaviour using just this:
  auth_param basic program /usr/lib/squid/basic_fake_auth -d


HTH
Amos

Bug#916536: squid FTCBFS: multiple reasons

[Amos Jeffries]

On 17/12/18 10:39 pm, Helmut Grohne wrote:
> Hi,
> 
> On Mon, Dec 17, 2018 at 09:05:56PM +1300, Amos Jeffries wrote:
>> These GCC|Clang versioned depends are to fix backport and custom build
>> FTBFS.
>>
>> We still have quite a number of people using self-compiled Squid in
>> order to gain the TLS interception features from OpenSSL. Those tend to
>> be squid-4 packages on older Debian and Ubuntu machinery where GCC
>> version still matters.
> 
> Thank you for the explanation.
> 
>>  So while I would love to have fully working cross-build support the
>> trade-off with lost users is not really worth it until Debian and
>> derivative LTS versions move on from the outdated GCC-4.x compilers.
> 
> This is a trade-off for sure and your reasoning makes very much sense to
> me. In that case, could we annotate the dependencies with  and
> add a little comment to debian/control explaining them? The 
> will mean "this dependency is only relevant whenever you are not cross
> compiling".


Ah, I was not aware of that being a possibility and am not seeing
anything like this (or how to add comments) in the policy manual section
7 syntax.

Could you supply a patch with those changes for me to test?

Amos

Bug#916536: squid FTCBFS: multiple reasons

[Amos Jeffries]

On Sat, 15 Dec 2018 17:22:56 +0100 Helmut Grohne wrote:
> 
> squid fails to cross build from source for a number of reasons. The
> immediate failure is with the g++ build dependency as that conflicts
> with the build architecture g++. For properly expressing the dependency,
> we'd need "toolchain dependency translation", which isn't a thing yet.
> However, the relevant dependencies are always satisfied since stretch.
> Therefore, we can simply drop them.

These GCC|Clang versioned depends are to fix backport and custom build
FTBFS.

We still have quite a number of people using self-compiled Squid in
order to gain the TLS interception features from OpenSSL. Those tend to
be squid-4 packages on older Debian and Ubuntu machinery where GCC
version still matters.
 So while I would love to have fully working cross-build support the
trade-off with lost users is not really worth it until Debian and
derivative LTS versions move on from the outdated GCC-4.x compilers.


I am not sure I understand what you mean by a conflict with the build
architecture g++.

 - the build arch g++/gcc are used during Squid build and needs to meet
that version criteria for correct operation.

 - the cross-compiler also needs to meet it, but we don't have a way to
indicate that dependency. If the cross-compiler is old enough to
conflict or break with a required BUILDCXX version it would seem the
cross-compiler is not going to work properly anyway.

 What am I missing here?


The other changes I have merged into our git branch for the next package
upload.

AYJ

Bug#913950: squid: should improve handling of Debian packages

[Amos Jeffries]

> 
> Dear Maintainer(s),
> 
> the handling of Debian packages could be improved with some configuration 
> options
> taken from the squid-deb-proxy package, see:
> https://sources.debian.org/src/squid-deb-proxy/0.8.14+nmu1/squid-deb-proxy.conf
> 
> This has been found out by Mike Gabriel; for details see
> the discussion here:
> https://bugs.debian.org/913886
> 
> If squid would improve the handling of Debian packages all users already using
> squid could avoid installing squid-deb-proxy in addition.
> 

Hi,

Thank you for your interest in improving Squid in Debian.

This is a topic I look into every so often to figure out how far Squid
alone can go, and to do so without breaking people using
squid-deb-proxy. The last time those checks were done was about July
2018 during the squid-4 packaging preparations.

A brief aside on the topic of removing/replacing squid-deb-proxy:

squid-deb-proxy provides relatively large amount of extra integration
setup to add Avahi daemon(s) reporting where to find the Squid proxy. As
well as apt configuration to enable auto-proxy detection and use the
Avahi service. There may be more subtle things as well. A key factor is
that much of this integration occurs on the client machines without any
proxy installed there.

Merging those integration actions would add a conflict between squid and
squid-deb-proxy. As well as require additional binary packages to be
produced by the pkg-squid team for the client machines integration
parts. That role IMHO is already played well by squid-deb-proxy despite
its maintainer not being in the pkg-squid team. So I see little gain and
much pain attempting to replace squid-deb-proxy.


Anyhow, back to the proposed config settings:

> So please consider to adjust d/debian.conf like proposed by Mike.
> 
> diff --git a/debian/debian.conf b/debian/debian.conf
> index 7ac16c97..7fa82301 100644
> --- a/debian/debian.conf
> +++ b/debian/debian.conf
> @@ -9,3 +9,29 @@ logfile_rotate 0
>  # localhost to use the proxy on new installs
>  #
>  #http_access allow localnet
> +
> +# Begin: Improve handling of Debian packages (taken from squid-deb-proxy)
> +# we need a big cache, some debs are huge
> +maximum_object_size 512 MB
> +
> +# tweaks to speed things up
> +cache_mem 200 MB

First surprise is this line above.

Squid packages as far back as Lenny have had a default cache_mem setting
of 256 MB. So this is actually a decrease in capacity of the fastest
accessible cache type (RAM).

> +maximum_object_size_in_memory 10240 KB
> +

Which is a 512Kb -> 10 MB conflicts a little with the earlier setting to
decrease the size of objects stored in there to 10MB.

Also, Squid understand units up to TB. So: s/10240 KB/10 MB/ would be
clearer and still work.


> +# refresh pattern for debs and udebs
> +refresh_pattern deb$   129600 100% 129600
> +refresh_pattern udeb$   129600 100% 129600
> +refresh_pattern tar.gz$  129600 100% 129600
> +refresh_pattern tar.xz$  129600 100% 129600
> +refresh_pattern tar.bz2$  129600 100% 129600
> +

Squid is much more often a gateway to the generic web or internal LAN
environments - or at least dual-purpose with the apt package caching.
These tarball settings specifically would affect content well beyond
Debian repositories.

Which is more a problem than benefit when one considers what (2) below
means about Debian repos not using these pattern settings.

So IMHO, the above are not appropriate for widespread default inclusion.
It is better to have admin explicitly opt-in to using such rules. for
example; by installing the squid-deb-proxy or similar package which
drops in a squid config snippet.


> +# always refresh Packages and Release files
> +refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
> +refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims
> +refresh_pattern \/InRelease$ 0 0% 0 refresh-ims
> +refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
> +


The parameters refresh_pattern supplies are used as defaults for the
caching heuristic algorithm(s). The values on all these lines are *only*
obeyed when the origin server omits a parameter needed by the caching
freshness algorithm from its HTTP response message.

In particular that means that when evaluating the utility of these rules
it is necessary to first analyze the origin service responses for each
of the relevant APT request messages to determine what caching
parameters it is supplying and which it is omitting.

When I have done that analysis for Debian official repositories those
servers *did* consistently provide the necessary cache parameters to
Squid. So for at least those repo servers these refresh_pattern rules
would do nothing beyond that 'refresh-ims' change in behaviour.


On the other hand my local reprepro installation does not always provide
those details. Particularly for the Packages requests. But does so in a
way which these config lines are insufficient to prevent immediate
re-fetch of the full content.

Thus I am 

Bug#913877: iptables 1.8.2: ERROR when adding REJECT target to custom chains

[Amos Jeffries]

My kernel version is 3.16.0-4-amd64.

That is due to unrelated driver errors the newer kernels have
consistently had on this hardware. I am surely not the only one in this
situation.

I see there was NEWS mention of unspecified impact with the 1.8.1+
versions but did not pay much attention to since I am not upgrading
"between Debian versions" here. The machine in question has always run
Sid and gets weekly updates of everything short of full reboot.

The main problem as I see it is that the packaging switched straight to
the -nft versions without sufficient checking that it was not breaking
the system by doing so. Surely there are tests that can be done on
install to select the auto/default flavour better?

AYJ

Bug#913877: iptables 1.8.2: ERROR when adding REJECT target to custom chains

[Amos Jeffries]

Followup experiments isolating the custom sub-chain are showing even
worse behaviour from the new iptables (-nft flavour).

These commands

 iptables -N test-foo
 iptables -I test-foo 1 -s 127.0.0.1 -j REJECT

Produces this output:

  iptables v1.8.2 (nf_tables):  RULE_INSERT failed (Invalid argument):
rule in chain test-foo


And this absurd syslog message:

  x_tables: ip_tables: REJECT target: used from hooks FORWARD, but only
usable from INPUT/FORWARD/OUTPUT



For anyone else encountering issues from the new packages these commands:

  update-alternatives --config iptables
  update-alternatives --config ip6tables

to manually override the automatic package default with the '-legacy'
flavour is required to restore proper behaviour.

AYJ

Bug#913877: iptables 1.8.2: ERROR when adding REJECT target to custom chains

[Amos Jeffries]

Package: iptables
Version: 1.8.2-2
Severity: grave

The fail2ban attack prevention software scans log files and adds
firewall rules dynamically to iptables/ip6tables to prevent DoS and
login scanning attacks in realtime.

Since upgrading iptables to the 1.8.2 version it has been completely
unable to do that vital task due to problems within nftables / iptables.

The example that I am facing right now is with active and large DoS
attacks email spam attacks. When fail2ban attempts to add the firewall
blocks, such as;

 iptables -w -I f2b-postfix-sasl 1 -s 80.82.70.189 \
  -j REJECT --reject-with icmp-port-unreachable


iptables produces an error:

 iptables v1.8.2 (nf_tables):  RULE_INSERT failed (Invalid argument):
rule in chain f2b-postfix-sasl

the system log matching that iptables update attempt states:

 x_tables: ip_tables: REJECT target: used from hooks
FORWARD/OUTPUT/POSTROUTING, but only usable from INPUT/FORWARD/OUTPUT

Which appears to be a lie. The f2b-postfix-sasl is a sub-chain of the
INPUT table and is not in any way connected to the FORWARD, OUTPUT nor
POSTROUTING tables.


iptables -L -nv
Chain INPUT (policy ACCEPT 1727M packets, 3523G bytes)
 pkts bytes target prot opt in out source
destination
 9531 7001K f2b-postfix-sasl  tcp  --  *  *   0.0.0.0/0
  0.0.0.0/0multiport dports 25,465,587,143,993,110,995
 9531 7001K f2b-courier-auth  tcp  --  *  *   0.0.0.0/0
  0.0.0.0/0multiport dports 25,465,587,143,993,110,995
 8629 6907K f2b-postfix  tcp  --  *  *   0.0.0.0/0
0.0.0.0/0multiport dports 25,465,587
 2994  278K f2b-sshd   tcp  --  *  *   0.0.0.0/0
0.0.0.0/0multiport dports 22
6412K 2086M f2b-postfix-sasl  tcp  --  *  *   0.0.0.0/0
  0.0.0.0/0multiport dports 25,465,587,143,993,110,995
6412K 2086M f2b-courier-auth  tcp  --  *  *   0.0.0.0/0
  0.0.0.0/0multiport dports 25,465,587,143,993,110,995
3053K  829M f2b-postfix  tcp  --  *  *   0.0.0.0/0
0.0.0.0/0multiport dports 25,465,587
  11M  663M f2b-sshd   tcp  --  *  *   0.0.0.0/0
0.0.0.0/0multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 1230M packets, 132G bytes)
 pkts bytes target prot opt in out source
destination

Chain f2b-sshd (2 references)
 pkts bytes target prot opt in out source
destination
 5988  556K RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0

Chain f2b-postfix (2 references)
 pkts bytes target prot opt in out source
destination
17258   14M RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0

Chain f2b-courier-auth (2 references)
 pkts bytes target prot opt in out source
destination
19062   14M RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0

Chain f2b-postfix-sasl (2 references)
 pkts bytes target prot opt in out source
destination
19062   14M RETURN all  --  *  *   0.0.0.0/0
0.0.0.0/0





AYJ

Bug#798935: Starting dnsmasq deadlock with /etc/resolvconf/update-libc.d/squid3

[Amos Jeffries]

On Thu, 01 Dec 2016 20:41:57 -0500 Stefan Monnier wrote:
> > On a system with systemd, dnsmasq and resolvconf installed, the
> > /etc/resolvconf/update-libc.d/squid3 hook prevents dnsmasq from
> > starting. As far as I can see, the problem is caused by a deadlock of
> > "systemctl start dnsmasq.service" in conjunction with "systemctl
> > reload squid3.service". The latter one is finally called by the
> > /etc/resolvconf/update-libc.d/squid3 hook which is invoked by dnsmasq
> > on startup.
> 

With squid now at version 4 the situation leading to this issue has
changed quite significantly.

Can someone encountering this issue please check and confirm if it is
resolved or present with squid 4.2-2 or later. Older versions are
already known broken in ways that may affect the test result.


Cheers
Amos

Bug#907106: (no subject)

[Amos Jeffries]

For the record the specific autoconf macro:

 AC_SEARCH_LIBS([__atomic_load_8],[atomic], ...)

Produces this test code:

"
| #ifdef __cplusplus
| extern "C"
| #endif
| char __atomic_load_8 ();
| int
| main ()
| {
| return __atomic_load_8 ();
|   ;
|   return 0;
| }
"

Which produces this (on all buildd's including the working ones):

"
conftest.cpp:56:6: error: new declaration 'char __atomic_load_8()'
ambiguates built-in declaration 'long long unsigned int
__atomic_load_8(const volatile void*, int)' [-fpermissive]
 char __atomic_load_8 ();
  ^~~
conftest.cpp: In function 'int main()':
conftest.cpp:60:25: error: too few arguments to function 'long long
unsigned int __atomic_load_8(const volatile void*, int)'
 return __atomic_load_8 ();
 ^
"

"checking for library containing __atomic_load_8... no"



Amos

Bug#907106: squid FTBFS on armel/mips/mipsel: undefined reference to `__atomic_store_8'

[Amos Jeffries]

Accepting this for next upload. BUT,

... is there any info known about why these platforms suddenly need the
-latomic flag to be hard-coded by the packaging?

Squid configure script auto-detects this symbols existence. It has for
some time on both working and non-working buildd's had the same results
and linker lines which are now suddenly FTBFS. See the working 4.1
upload for reference.

Amos

Bug#905841: libltdl-dev: dependency on specific automake version

[Amos Jeffries]

Package: libltdl-dev
Version: 2.4.6-2.1
Severity: grave

The update of automake to version 1.16 causes FTBFS in software using
libltdl-dev.

The libltdl-dev package installs a libtool/aclocal.m4 file which
contains a macro hard-coding the automake version used to build the
libtool sources.

Any software using libtoolize inherits the installed libtool/aclocal.m4
file as libltdl/aclocal.m4 which in turn then gets built into
libltdl/configure when the user software bootstrap's from configure.ac
files.

The end result is the following error whenever automake version differs
from the one libltdl-dev was built with:

cfgaux/missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
 You should only need it if you modified 'acinclude.m4' or
 'configure.ac' or m4 files included by 'configure.ac'.
 The 'aclocal' program is part of the GNU Automake package:
 
 It also requires GNU Autoconf, GNU m4 and Perl in order to run:
 
 
 
make[1]: *** [Makefile:540: ../../libltdl/aclocal.m4] Error 127


As I write this Debian currently has "automake" from automake-1.16
sources, and "libltdl-dev" built when automake-1.15 was the current.

Repeating the bootstrap / autoreconf process in the software seeing this
error "resolves" the problem *if* (and only if) the automake and
libltdl-dev versions match. When the packages differ as Debian Sid
machines do right now the autoreconf will still pull in the outdated
libltdl-dev files and the FTBFS problem remains.


Please add a versioned Depends on the specific automake-1.X package used
to build libltdl-dev to prevent development machines installing newer
versions of automake before libltdl-dev is rebuilt to be compatible.


Thanks
AYJ

Bug#905776: duck: errors resolving salsa Vcs-Git URLs

[Amos Jeffries]

Package: duck
Severity: high


The duck tool is adding annoying maintainer notices about packages
containing issues when they migrate to what is apparently the correct
URL for salsa.debian.org hosted repositories.

> fatal: unable to connect to salsa.debian.org:
> salsa.debian.org[0: 209.87.16.44]: errno=Connection refused
> salsa.debian.org[1: 2607:f8f0:614:1::1274:44]: errno=Network is
unreachable


Results in:

> DUCK reports some issues concerning upstream URLs defined for this
package.


Between these salsa reports and the alioth domain having been removed
over 6000 packages right now are 'failing'.

AYJ

Bug#903165: On boot squid.service starts but doesn't work

[Amos Jeffries]

Ah, thank you. I have looked into that network-online.target and it
seems we do need to make it a requirement for Squid to be started. This
should be fixed in the next release.

Amos

Bug#533663: "slowloris" denial-of-service vulnerability

[Amos Jeffries]

This was closed upstream long ago. See upstream bug report for details.

thanks
Amos

Bug#728144: squid3: Pinger Segmentation fault in Debug::finishDebug on delete CurrentDebug;

[Amos Jeffries]

Source: squid3
thanks

Trying to reassign to 3.x source packages. So BTS does not block v4
squid package uploads on this old RC issue.

Amos

Bug#903165: squid: When squid.service starts no /etc/resolv.conf is present yet

[Amos Jeffries]

On Sat, 07 Jul 2018 13:31:00 +0200 Cesare Leonardi wrote:
> Package: squid
> Version: 4.1-1
> Severity: normal
> 
> For testing purposes I use squid proxy on my laptop.
> Since upgrading to 4.1, when the system boots, squid service is not
> operating properly: it always fails to resolve DNS names. And I have to
> restart the service in order to make it work.


What init system are you using; sysV? systemd? something else?

If it is systemd, please check that your NetworkManager is part of the
nss-lookup.target groups. Squid depends on that target providing
resolv.conf.

If it is sysV, please check that your NetworkManager init script is
running well before Squid's.


Amos

Bug#824259: squid does not stop in a docker container wihout systemd

[Amos Jeffries]

I do not think systemd is relevant here.

Any script running the /usr/sbin/squid binary will fail if that binary
does not exist inside the container.

Amos

Bug#888868: squid3 FTCBFS for 32bit archs on amd64: adds -m64 to CFLAGS via getconf for LFS

[Amos Jeffries]

Can you provide the command used to cross-build for replicating this bug?


Amos

Bug#898469: Squid waits on shutdown even though there are no active clients

[Amos Jeffries]

On Sat, 12 May 2018 06:31:23 +0200 Alain Knaff wrote:
> Package: squid
> Version: 3.5.23-5+deb9u1
> 
> Hi,
> 
> The comment about on shutdown_lifetime in the sample squid.conf file
> says the following:
> 
> #  TAG: shutdown_lifetime   time-units
> #   When SIGTERM or SIGHUP is received, the cache is put into
> #   "shutdown pending" mode until all active sockets are closed.
> #   This value is the lifetime to set for all open descriptors
> #   during shutdown mode.  Any active clients after this many
> #   seconds will receive a 'timeout' message.
> 
> 
> However, in reality, squid waits the shutdown_lifetime regardless of
> whether there are any active clients currently connected to or not.
> 
> Even if no clients are connected (squid freshly started, in the middle
> of the night, verified using lsof and netstat), it still takes 30
> seconds to shutdown.
> 
> So either the code (preferably...) or that comment needs to be fixed.
> 
> ... or did I just misunderstand the documentation? ;^)
> 

Yes and no.

This is a common misunderstanding of the documentation. "active sockets"
is not the same as "client connections". Sockets are used for many
things other than clients and some of those may continue for a while
after clients are gone.

That said Squid currently does not abort those other socket connections
until shutdown_lifetime completes. So effectively shutdown_lifetime
always happens.

FWIW; current Squid (3.4+) solve a lot of the issues older Squid had
with very short shutdown_lifetime so you can set it to whatever short
duration you are happy with now.

Amos

Bug#898307: Please provide the --enable-ssl-crtd feature

[Amos Jeffries]

On Thu, 10 May 2018 00:17:51 +0100 Ian Jackson wrote:>
> AIUI there is a licence problem with enabling those in Debian, but can
> --enable-ssl-crtd be done with GNUTLS ?
> 

The GnuTLS support only covers explict/forward proxy and reverse-proxy
features. The SSL-Bump MITM related features including ssl-crtd still
require OpenSSL builds.

Amos

Bug#896125: squid: Squid 4: /etc/default/squid KRB5_KTNAME not permanently set

[Amos Jeffries]

Sounds to me like the machine you are testing on uses systemd as its
init system. Correct?

The /etc/default/ folder is a feature of SystemV init scripts and as
such is not used by systemd init. It is also one of the parts that is
not worked around by the Debian systemd integration. You can find
discussions on that specific oddity in debian-devel [1].

The systemd alternative is to create a local .service file with custom
changes like that.

OR, as you found - the best solution is to put the relevant helper
parameter in squid.conf so only the software using it knows the keytab
location, and it can be changed per-instance if desired.

I am adding a NEWS.debian section to mention this and another systemd
surprise awaiting people who disabled Squid in that config file. Not
sure what else we can do than warn people. Any ideas welcome.


Amos

[1] 

Bug#892401: squid3: build-depends on GCC 6

[Amos Jeffries]

For the record, the intention is not to include the squid3 package in
Buster. Squid-4 packages intended for buster are currently in
experimental awaiting upstream stable release.

Amos

Bug#896120: squid: Squid 4: Please enable acl proxy_auth -i again

[Amos Jeffries]

forwarded +1 https://bugs.squid-cache.org/show_bug.cgi?id=4847
thanks

Bug#895993: squid3 packages need SSL support

[Amos Jeffries]

reassign 641944 squid
merge 641944 895993
thanks

Due to license issues while using OpenSSL in squid code-base an
SSL-enabled version of Squid cannot be uploaded to the main repository.
I'm merging this bug with the other one asking for SSL support.

FWIW; the Squid-4 packages are coming with GnuTLS support for basic TLS
operations. OpenSSL is also working on a license change. Both are
ongoing works.


Cheers,
Amos

Bug#889961: courier-authdaemon: Upgrade failures in 0.68.0-4 package

[Amos Jeffries]

It seems that the systemd/systemctl is removing the
/run/courier/authdaemon/pid file underneath courier.

Removing the line "PIDFile=/run/courier/authdaemon/pid" from the
installed .service file resolves this problem and upgrade works fine.

Amos

Bug#889961: courier-authdaemon: Upgrade failures in 0.68.0-4 package

[Amos Jeffries]

Package: courier-authdaemon
Version: 0.68.0-4+b1
Severity: critical
stop

The Courier authdaemon package is failing to configure during install.
Similar issue happened on the -3 package but I managed to get that to
install with manually stopping all courier processes before upgrading.
That workaround no longer has any effect.


aptitude upgrade
The following partially installed packages will be configured:
  courier-authdaemon courier-imap courier-pop
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up courier-pop (0.78.0-2+b1) ...
A dependency job for courier-pop.service failed. See 'journalctl -xe'
for details.
...


Setting up courier-imap (4.18.1+0.78.0-2+b1) ...
A dependency job for courier-imap.service failed. See 'journalctl -xe'
for details.
invoke-rc.d: initscript courier-imap, action "start" failed.
* courier-imap.service - Courier IMAP Daemon
   Loaded: loaded (/lib/systemd/system/courier-imap.service; enabled;
vendor preset: enabled)
   Active: inactive (dead) since Fri 2018-02-02 20:12:20 NZDT; 1 weeks 0
days ago
 Main PID: 705 (code=exited, status=0/SUCCESS)

Feb 09 21:44:44 rio systemd[1]: Dependency failed for Courier IMAP Daemon.
Feb 09 21:44:44 rio systemd[1]: courier-imap.service: Job
courier-imap.service/start failed with result 'dependency'.
Feb 09 21:45:03 rio systemd[1]: Dependency failed for Courier IMAP Daemon.
Feb 09 21:45:03 rio systemd[1]: courier-imap.service: Job
courier-imap.service/start failed with result 'dependency'.
Feb 09 21:45:09 rio systemd[1]: Dependency failed for Courier IMAP Daemon.
Feb 09 21:45:09 rio systemd[1]: courier-imap.service: Job
courier-imap.service/start failed with result 'dependency'.
Feb 09 21:45:39 rio systemd[1]: Dependency failed for Courier IMAP Daemon.
Feb 09 21:45:39 rio systemd[1]: courier-imap.service: Job
courier-imap.service/start failed with result 'dependency'.
Warning: Journal has been rotated since unit was started. Log output is
incomplete or unavailable.
dpkg: error processing package courier-imap (--configure):
 installed courier-imap package post-installation script subprocess
returned error exit status 1
Setting up courier-authdaemon (0.68.0-4+b1) ...
Job for courier-authdaemon.service failed because the service did not
take the steps required by its unit configuration.
See "systemctl status courier-authdaemon.service" and "journalctl -xe"
for details.
invoke-rc.d: initscript courier-authdaemon, action "start" failed.
* courier-authdaemon.service - Courier Authentification Daemon
   Loaded: loaded (/lib/systemd/system/courier-authdaemon.service;
disabled; vendor preset: enabled)
   Active: failed (Result: protocol) since Fri 2018-02-09 21:45:39 NZDT;
8ms ago
  Process: 4623 ExecStart=/usr/sbin/authdaemond start (code=exited,
status=0/SUCCESS)
 Main PID: 667 (code=exited, status=0/SUCCESS)

Feb 09 21:45:39 rio systemd[1]: Starting Courier Authentification Daemon...
Feb 09 21:45:39 rio systemd[1]: courier-authdaemon.service: Can't open
PID file /run/courier/authdaemon/pid (yet?) after start: No such file or
directory
Feb 09 21:45:39 rio systemd[1]: courier-authdaemon.service: Failed with
result 'protocol'.
Feb 09 21:45:39 rio systemd[1]: Failed to start Courier Authentification
Daemon.
dpkg: error processing package courier-authdaemon (--configure):
 installed courier-authdaemon package post-installation script
subprocess returned error exit status 1
Errors were encountered while processing:
 courier-pop
 courier-imap
 courier-authdaemon
E: Sub-process /usr/bin/dpkg returned an error code (1)

Setting up courier-pop (0.78.0-2+b1) ...
A dependency job for courier-pop.service failed. See 'journalctl -xe'
for details.
...

Setting up courier-authdaemon (0.68.0-4+b1) ...
Job for courier-authdaemon.service failed because the service did not
take the steps required by its unit configuration.
See "systemctl status courier-authdaemon.service" and "journalctl -xe"
for details.
invoke-rc.d: initscript courier-authdaemon, action "start" failed.
* courier-authdaemon.service - Courier Authentification Daemon
   Loaded: loaded (/lib/systemd/system/courier-authdaemon.service;
disabled; vendor preset: enabled)
   Active: failed (Result: protocol) since Fri 2018-02-09 21:45:41 NZDT;
7ms ago
  Process: 4821 ExecStart=/usr/sbin/authdaemond start (code=exited,
status=0/SUCCESS)
 Main PID: 667 (code=exited, status=0/SUCCESS)

Feb 09 21:45:41 rio systemd[1]: Starting Courier Authentification Daemon...
Feb 09 21:45:41 rio systemd[1]: courier-authdaemon.service: Can't open
PID file /run/courier/authdaemon/pid (yet?) after start: No such file or
directory
Feb 09 21:45:41 rio systemd[1]: courier-authdaemon.service: Failed with
result 'protocol'.
Feb 09 21:45:41 rio systemd[1]: Failed to start Courier Authentification
Daemon.
dpkg: error processing package courier-authdaemon (--configure):
 installed 

Bug#879639: squid takes 30 seconds to restart, should be < 1 second

[Amos Jeffries]

Package: squid
Version: 4.0.21-1~exp5

This should be fixed in the upcoming Squid-4 packages.

Amos Jeffries

Bug#879639: squid takes 30 seconds to restart, should be < 1 second

[Amos Jeffries]

This is a systemd problem. It does not track the correct processes for 
its actions.


For more detail see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871602#10 and 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855268#26


In short: do not use systemctl or its "service" alias with Squid-3. 
Either use the init Script provided by the package, or 'squid -k' 
commands directly.



Amos

Bug#871602: squid: packaged with initscripts and not debian

[Amos Jeffries]

(with my upstream hat on)

Squid-3 and systemd are incompatible. The .service file distributed with 
3.5 is minimally sufficient for systemd startup and shutdown, perhapse 
status (but only perhapse) command - but no other management commands 
work at all well.
 One of the resulting issues is covered in a bit more detail in 
.



As for the mentioned use-case:

I'm a little confused by what you mean by having to configure respawn. 
Squid performs its own automatic worker process restart after crashes. 
No need for systemd or anything to explicitly be configured. The 
worst-case event where the Squid daemon manager itself crashes, is when 
the systemd flaws appear most visibly - such as the above mentioned bug 
#855268.



(with my Debian pkg-squid hat on)

Squid-4 has been redesigned to give systemd less trouble tracking PID. 
The 4.x squid package being worked on for Buster (and possibly Stretch 
backport) ships the necessary init files for both sysVinit and systemd.



Cheers
Amos

Bug#853668: squid3: ftbfs with GCC-7

[Amos Jeffries]

Just an update for the record.

The upstream bug was fixed in code scheduled for 3.5.27. But I'm not 
sure if there will be any more uploads for 3.5 series. We have a Squid-4 
package underway in the pkg-squid3 repo which should resolve this bug 
when it gets uploaded.


Amos

Bug#864715: USB netinst fails to identify /media/cdrom as a path for base system packages or /cdrom mounting

[Amos Jeffries]

On 14/06/17 03:38, Steve McIntyre wrote:

On Wed, Jun 14, 2017 at 02:41:32AM +1200, Amos Jeffries wrote:

On 14/06/17 00:44, Steve McIntyre wrote:

On Tue, Jun 13, 2017 at 11:39:46PM +1200, Amos Jeffries wrote:

Package: installation-reports

On running the installer manually from inside the OEM Windows
installed, everything appeared to run smoothly up to the reboot
following partition and formatting of the machines drives. On that
boot the installer now running off the HDD began looping at the
"Install base system" step, no errors or other signs of trouble -
just display the progress bar for a few mins, then flick out to
the step-by-step listing as if that step was done - but
highlighting the same "Install base system" entry every time enter
was pressed to start the step.

Ummm... Question: you say "up to the reboot following partition and
formatting of the machines drives". debian-installer doesn't reboot
there. How did you prepare your USB stick, please?

It was a vanilla download of the 64-bit netinst ISO burned to the USB stick.

OK. How did you write it, please? dd? cp? Something like unetbootin?


I believe that one was done with the "rufus" tool for Windows.


Formatting was the latest step I'm sure worked fine. The default process was
followed from there until reboot needed, then more default process.
Everything up to the step "install base system" at least appeared to work -
until that one did not.

There isn't a reboot step in the normal path of debian-installer. Oh,
hang on, sorry - I've just seen what I missed earlier in your initial
message: "On running the installer manually from inside the OEM
Windows". Did you use the win32-installer option to start
installation?



I think so, yes.


AYJ

Bug#864715: USB netinst fails to identify /media/cdrom as a path for base system packages or /cdrom mounting

[Amos Jeffries]

On 14/06/17 00:44, Steve McIntyre wrote:

On Tue, Jun 13, 2017 at 11:39:46PM +1200, Amos Jeffries wrote:

Package: installation-reports

On running the installer manually from inside the OEM Windows installed,
everything appeared to run smoothly up to the reboot following partition and
formatting of the machines drives. On that boot the installer now running off
the HDD began looping at the "Install base system" step, no errors or other
signs of trouble - just display the progress bar for a few mins, then flick
out to the step-by-step listing as if that step was done - but highlighting
the same "Install base system" entry every time enter was pressed to start
the step.

Ummm... Question: you say "up to the reboot following partition and
formatting of the machines drives". debian-installer doesn't reboot
there. How did you prepare your USB stick, please?



It was a vanilla download of the 64-bit netinst ISO burned to the USB stick.

Formatting was the latest step I'm sure worked fine. The default process 
was followed from there until reboot needed, then more default process. 
Everything up to the step "install base system" at least appeared to 
work - until that one did not.


AYJ

Bug#864715: USB netinst fails to identify /media/cdrom as a path for base system packages or /cdrom mounting

[Amos Jeffries]

Package: installation-reports

On running the installer manually from inside the OEM Windows installed, 
everything appeared to run smoothly up to the reboot following partition 
and formatting of the machines drives. On that boot the installer now 
running off the HDD began looping at the "Install base system" step, no 
errors or other signs of trouble - just display the progress bar for a 
few mins, then flick out to the step-by-step listing as if that step was 
done - but highlighting the same "Install base system" entry every time 
enter was pressed to start the step.


Manually going to the next step on the list failed with a message about 
the base system not being fully present.


Skipping to the shell for manual inspection showed that the path /cdrom 
was being searched for the image packages but non-existent already 
(expected after install is complete, but not halfway through). Since 
this was a USB based install the netinst image had been loaded as 
/media/cdrom, and /dev/cdrom was not a mountable device since the CD/DVD 
drive did not have a disk.


Manually creating a symlink "ln -s /media/cdrom /cdrom" allowed the 
installer to continue and successfully install the system.


NP: if this is not already fixed in the latest 1-2 installer versions it 
really should be handled for Stretch. This has a high potential for 
newbies "bricking" their machines since they will not readily know the 
manual fix necessary.



 -- Package-specific info:

Boot method: netinst image on a USB drive, run from Windows 7
Image version: unknown sorry, downloaded from Debian mirrors 2017-05-12
Date: 2017-05-21

Machine: Dell
Processor: Intel Celeron (64-bit quad-core)
Memory: 4GB
Partitions:
ilesystem Type 1K-blocks Used Available Use% Mounted on
udev   devtmpfs 102400 10240   0% /dev
tmpfs  tmpfs   40093646044354892  12% /run
/dev/dm-0  ext4 149393716 12988176 128793740  10% /
tmpfs  tmpfs  10023400   1002340   0% /dev/shm
tmpfs  tmpfs 51200  5120   0% /run/lock
tmpfs  tmpfs  10023400   1002340   0% /sys/fs/cgroup


 Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM 
Controller [8086:2e10] (rev 03)
00:01.0 PCI bridge [0604]: Intel Corporation 4 Series Chipset PCI 
Express Root Port [8086:2e11] (rev 03)
00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series 
Chipset Integrated Graphics Controller [8086:2e12] (rev 03)
00:02.1 Display controller [0380]: Intel Corporation 4 Series Chipset 
Integrated Graphics Controller [8086:2e13] (rev 03)
00:03.0 Communication controller [0780]: Intel Corporation 4 Series 
Chipset HECI Controller [8086:2e14] (rev 03)
00:03.2 IDE interface [0101]: Intel Corporation 4 Series Chipset PT IDER 
Controller [8086:2e16] (rev 03)
00:03.3 Serial controller [0700]: Intel Corporation 4 Series Chipset 
Serial KT Controller [8086:2e17] (rev 03)
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM-3 Gigabit 
Network Connection [8086:10de] (rev 02)
00:1a.0 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 
Family) USB UHCI Controller #4 [8086:3a67] (rev 02)
00:1a.1 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 
Family) USB UHCI Controller #5 [8086:3a68] (rev 02)
00:1a.2 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 
Family) USB UHCI Controller #6 [8086:3a69] (rev 02)
00:1a.7 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 
Family) USB2 EHCI Controller #2 [8086:3a6c] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801JD/DO (ICH10 Family) 
HD Audio Controller [8086:3a6e] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801JD/DO (ICH10 Family) 
PCI Express Port 1 [8086:3a70] (rev 02)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801JD/DO (ICH10 Family) 
PCI Express Port 2 [8086:3a72] (rev 02)
00:1d.0 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 
Family) USB UHCI Controller #1 [8086:3a64] (rev 02)
00:1d.1 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 
Family) USB UHCI Controller #2 [8086:3a65] (rev 02)
00:1d.2 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 
Family) USB UHCI Controller #3 [8086:3a66] (rev 02)
00:1d.7 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 
Family) USB2 EHCI Controller #1 [8086:3a6a] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge 
[8086:244e] (rev a2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801JDO (ICH10DO) LPC 
Interface Controller [8086:3a14] (rev 02)
00:1f.2 RAID bus controller [0104]: Intel Corporation SATA Controller 
[RAID mode] [8086:2822] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801JD/DO (ICH10 Family) SMBus 
Controller [8086:3a60] (rev 02)





 Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]

Bug#864389: squid: Regression - after upgrade, squid takes over minute to display a web page

[Amos Jeffries]

FYI: the recent few updates have been for bugs in the install/upgrade 
process.


This type of behaviour is usually encountered when there is a large 
config file to load, the machine is under high CPU load starting 
helpers, DNS issues, or network latency to some service that is needed.


Anything like that identifiable on the local network?


Amos

Bug#862915: squid: please drop required dependency on logrotate

[Amos Jeffries]

FYI: The cache.log, store log, and HDD swap.state journals produced by 
Squid are system-specific and not able to be sent to any remote logging 
systems. Logrotate is still the best system in Debian (as far as I am 
aware anyhow) to manage those log files needs.



Where and how the access.log records are delivered is purely optional 
and syslog systems can be used there at administrator discretion.  
syslog use is more impacted by several other major issues:


Firstly; syslog timestamping does not represent sub-millisecond and 
ranged time durations as required by a proxy to display a transaction. 
This causes a requirement to duplicate the timestamp information in each 
log entry (syslog time and squid time).



Secondly; The latency delays in syslog delivery and recording over the 
network in turn often results in the "duplicate" timestamps to display 
conflicting information. While a second or two may seem small, when one 
second can contain upwards of a 20,000 transactions with order-dependent 
behaviours this discrepancy can be a major issue in detecting traffic 
problems.



Thirdly; syslog being a networked delivery mechanism over UDP is prone 
to loss of log information at the most critical high-load periods where 
it is most vital to retain.



On high performance systems, the traffic accounting and records are 
maintained through a local logging daemon or pipe, which may deliver to 
a billing system with neither local file nor syslog involvement.


Overall syslog may be favoured by some admin but for Squid it is among 
the worst of the available logging mechanims. So I do not think it is 
something we want to be encouraging for use with the Squid package.



Amos

Bug#859072: Contribute extended dep8 testing

[Amos Jeffries]

Thank you. I am adding these to the Squid-4 package.

Amos

Bug#857137: squid3: on Debian Jessie: /etc/init.d/squid3 returncode is wrong with conf file with errors

[Amos Jeffries]

Control: notfixed -1 3.5.12-1

Apologies, I misread the diff. It was correct and I have applied the
patch for next unstable upload.

For Jesse both the upstream and Eric's patches need to be applied to
close this bug properly.

Amos

Bug#859072: Contribute extended dep8 testing

[Amos Jeffries]

FYI: I am just one of a team in Debian, not 'the' maintainer, Luigi is
that. So I am just auditing the patch as presented for inclusion to Debian.


On Thu, 30 Mar 2017 14:26:59 +0200 Christian Ehrhardt wrote:
> On Thu, Mar 30, 2017 at 1:28 PM, Amos Jeffries wrote:
>
> > Thank you.
> >
> > Biggest issue I see is a bunch of License problems - which will affect
> > Ubuntu inclusion in similar ways IMHO:
> >
>
> I agree and thank you as nobody ever spotted (or cared about) that.
> But I know the Authors and can ask about a proper relicensing of those bits.
>
> TL;DR summary of the license todo:
>  * debian/tests/test-squid.py is GPLv2 should be proper GPLv2+
>  * debian/tests/testlib.py bad copy of GPLv2+ should be proper GPLv2+
>- edit hints that authors actually wanted it to be the incompatible?
> * debian/tests/testlib_httpd.py is GPLv3 should be GPLv2+
> * debian/tests/squid add an explicit GPLv2+ License
>
>
> > [...]
> > would make the .deb package and everything inside it a GPLv3-only
> > offering. Even assuming tat is okay, a v3-only .deb makes the above
> > v2-only script issues worse.
> >
>
> I'm not a lawyer, but I think in the python + test case this is even more
> special.
> As there is no classic linking involved, but more important the tests are
> only part of the source, but not part of the .deb being produced.
> Never the less I clearly want to sort that out - thanks for bringing it up!

I think the fact the Debian/Ubuntu ship source tarballs makes that an
issue. I wrote .deb but meant the source package (.debs?). IANAL myself,
just have enough experience to spot collisions. If the technical
packaging rearrangement and authors does not resolve that cleanly it may
be something to pass to the Debian legal team to suggest a solution.

> - this appears to be a large and generic python library. Do we really
> > need to embed it anyway? can it not be pulled from some other package or
> > provided by the QA infrastructure itself?
> >
>
> It is part of a much bigger testsuite, therefore the bigger libraries.
>
> A package would only make sense if it would be packaged but it is not, the
> right way would be to pull from their git or such.
> But then that gets us back into the connectivity issues from DebCI/Ubuntu
> Test infrastructure.
>
> The benefit of taking the libs as-is was to be able to later on update them
> by copying in the newer versions / cherry-picking changes.

IME the opposite is actually true. Synchronising N copies of some
generic code copy-n-pasted across an unknown number of packages is a
major PITA to work with variations - even using VCS tools to do it.
Having one library package with easily identified dependencies that can
be coordinated with API changes is far better. In the short term I find
it better to propose and wait a while to seeif the CI can be fixed.
Debian is in freeze now so no urgency on updating squid yet.

> Changes are needed over time as Distributions change every so slightly.
>
> Yet I agree that it might need only a small subset, would you be ok with me
> trimming that code down to the point that it will be only the test-squid.py
> with just the functions needed moved into it and a proper relicense from
> the original Authors?

Personally, yes. But as mentioned I'm fairly new to Debian processes.

> > I think a few basic changes to the test logic should be made to avoid
> > Internet access being required to send traffic to what are bogus URL
> > domains anyway.
> >
>
> It only goes to localhost/127.0.0.1 in what I sent, could you elaborate
> where you still see Internet access being required?

I was being fooled by the script documentation. By my reading it says
what the test is supposed to be checking. If the documentation not
matching what is actually being done that would still be an issue
needing a fix, just different.

Taking a closer look I dont actually see squidguard.conf being created
anywhere, and squidguard is not listed as a test dependency. So maybe
the SG test is not even happening ?

I dont see squid.conf being setup anywhere for the tests either. So
maybe I am missing a major piece of the DEP8 process?


> The only references I still see are in the the header which would be
> removed in a cleanup anyway.

FYI: From my perspective what I see with this bug repoort is that you
submitted a patch requesting it be applied, with statements asserting
that it was in successful active use as supporting evidence of it being
useful and trustworthy. I am just auditing a patch proposed for merge.
If that is not the final patch you want comitted, please clean it up
before even applying - or make it very clear that further work is needed
before applying. That is a good practice for submitting patches to any
project, any

Bug#859072: Contribute extended dep8 testing

[Amos Jeffries]

Thank you.

Biggest issue I see is a bunch of License problems - which will affect
Ubuntu inclusion in similar ways IMHO:

 * debian/tests/test-squid.py not being compatible with the .deb package
License. Squid and the .deb packaging are at least GPLv2+. This script
states v2-only. It will need to be relicenced compatible with GPLv2+
(preferrably to that license) to be added.

* debian/tests/testlib.py has same GPLv2-only issues as above. However
this one is invalid is it appears to be a copy-paste of GPLv2+ with
(incorrect) editing to make it explicitly drop the "or later"
permission. It is not the legal GPLv2-only disclaimer. The edit is also
a strong hint that the authors actually want it to be the incompatible
v2-only license version and may not agree to GPLv2+ etc.

 - this appears to be a large and generic python library. Do we really
need to embed it anyway? can it not be pulled from some other package or
provided by the QA infrastructure itself?

* debian/tests/testlib_httpd.py is GPLv3 (-only). which makes I believe
would make the .deb package and everything inside it a GPLv3-only
offering. Even assuming tat is okay, a v3-only .deb makes the above
v2-only script issues worse.

 - it is another fairly generic library. So maybe an external package
providing it could be the best way forward here.

 * debian/tests/squid script has no license at all. Given the above
sorts of things happening I would be quite uncomfortable assuming they
intended the .deb license to apply. It would be better for its
author(s?) to explicitly pick a compatible (or same) license and state
what they chose along with the author name(s?).



I think a few basic changes to the test logic should be made to avoid
Internet access being required to send traffic to what are bogus URL
domains anyway.

In debian/tests/test-squid.py there is no reason why the .com TLD needs
to be sent by squidguard. It could send some .local TLD domain or at
worst use sub-domains within the example.com/.net/.org domains which are
registered for such things. Also squid.conf can load a custom hosts file
to point any domains used at a server being run by the test
infrastructure, eg the Apache being run for other tests anyway.
Personaly I would use something even more basic with hard-coded
responses that can be tested explicitly against the squidclient output.

Amos

Bug#858556: In case the code is not anywhere...

[Amos Jeffries]

On 26/03/2017 1:34 p.m., Santiago Garcia Mantinan wrote:
>> Maybe it was just that the original code had to be at the 
>> upgrade|install-upgrade
>> block of the case?
>>
>> But why is the -d /etc/squid3 checked?
> 

IIRC this is for transitions where _both_ squid and squid3 packages are
already installed. Including the odd situation where a squid3 package is
partially installed, which apt seems to like doing.

The root cause of our troubles AFAICT is that the old 2.x "squid"
packages do not register their squid.conf as a conffile. So in the debci
testing dpkg has no way to know that there were no changes to the 2.7
default config file when upgrading wheezy->stretch. That was the initial
bug 801654 problem about constantly asking to preserve changes.

So... the current squid package unconditionally preserves any old
squid.conf, goes on to install and register the 3.5+ squid.conf.default
file as its baseline conffile. Then slips the old squid.conf into place
as if it had gone through a normal conffile upgrade with no questions,
always preserving the 'old' version squid.conf.

That much seems to be working as intended for upgrades. But I/we wrongly
assumed the --compare-versions would return false if there was no
previous version.

Amos

Bug#858556: squid 3.5.23-2: upgrade from jesse squid3 fails

[Amos Jeffries]

Package: squid
Version: 3.5.23-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
stop

From: Andreas Beckmann
Date: Thu, 23 Mar 2017 04:04:15 +0100

Hi,

the last upload introduced a regression:

  Selecting previously unselected package squid.
  (Reading database ...
(Reading database ... 12210 files and directories currently installed.)
  Preparing to unpack .../squid_3.5.23-2_amd64.deb ...
  mv: cannot stat '/etc/squid/squid.conf': No such file or directory
  dpkg: error processing archive
/var/cache/apt/archives/squid_3.5.23-2_amd64.deb (--unpack):
   subprocess new pre-installation script returned error exit status 1
  Errors were encountered while processing:
   /var/cache/apt/archives/squid_3.5.23-2_amd64.deb

This was observed on a jessie -> sid upgrade.

Bug#855268: squid: PID file at wrong place -> not installable

[Amos Jeffries]

> However, some init scripts can contain hacky or racy code and this could
> potentially lead to such issues in systemd. But again, I'm not able to 
> reproduce
> the problem which is why I am downgrading the severity of this bug report and
> tagging it accordingly.

systemd is racing the Squid internal startup process. As you can see
from your trace PID 3089 is not the one systemd "supervises" during the
startup period and whichever PID that supervision was done for (3047? or
3087?) is potentially finished before squid.pid is produced by PID 3089.
systemd is doing some hidden thing to isolate PID 3089 as the worker
process - how it manages to get that right is already a miracle.

AFAIK the replication of this problem just requires a config file that
loads a lot of data into some ACL. That can take long enough so systemd
wins the race to read squid.pid before it exists.

Ubuntu decided to drop the LSB init script line telling systemd where
the PID file would appear. As far as I am aware that leaves systemd
supervising the wrong process permanently - which is a gamble that
systemd does not need to send any signals to it, unexpected things might
happen if a signal gets sent to the wrong PID.

That might be used as a workaround for anyone having this issue. But be
aware that it was put there in the first place to resolve issues with
systemd controlling Squid-3. So pick your poison / YMMV.


> In the long term, the squid package should be updated to provide native 
> systemd
> support in the form of service files. Since we have agreed in Debian to 
> support
> systemd as the default and preferred init system. all packages are required to
> function properly with systemd which is why native systemd service files for
> squid are desirable.
> 

That is coming with Squid-4 in the Debian Buster cycle. Squid-3 (all
versions) are not very compatible with systemd for the reasons already
stated.

Squid-4 had to have a full redesign of its startup procedures and
process responsibilities. That is too intrusive to backport to 3.5
stable releases, so I am doubtful Jesse will ever see a better
Squid-systemd interaction.

Amos

Bug#857137: squid3: on Debian Jessie: /etc/init.d/squid3 returncode is wrong with conf file with errors

[Amos Jeffries]

Control: fixed -1 3.5.12-1

The regex is correct, but Squid itself is not following its own
documentation about some FATAL messages. The result is that some types
of errors are detected but some are not.

The upstream patch fixing this should be applied instead, and can be
found at
.

The squid 3.5 package in Squeeze is already fixed with that upstream change.

Amos

Bug#853668: squid3: ftbfs with GCC-7

[Amos Jeffries]

Forwarded: 853668 http://bugs.squid-cache.org/show_bug.cgi?id=4671
thanks

This is still being worked on upstream. The mentioned memory allocator
issues are now gone. However there are quite a few additional warnings
which are causing FTBS at later stages.

Amos

Bug#855268: squid: PID file at wrong place -> not installable

[Amos Jeffries]

On Thu, 16 Feb 2017 09:25:33 +0100 Andreas Rittershofer wrote:
> Package: squid
> Version: 3.5.23-1
>
> * What led up to the situation?
>
> I tried to install squid via apt-get install squid
>
> The problem is here:
>
>
>  Feb 16 08:32:08 dx151 systemd[1]: Starting LSB: Squid HTTP Proxy
>  version 3.x...
>  Feb 16 08:32:08 dx151 squid[5885]: Starting Squid HTTP Proxy: squid
>  failed!
>  Feb 16 08:32:08 dx151 systemd[1]: squid.service: PID file
>  /var/run/squid.pid not readable (yet?) after start: No such file or
>  directory
>  Obviously the installer script tries to put the PID file in /var/run.
>  This can not work, because squid has no write access to /var/run which
>  is owned by root.root. Instead squid should put its PID file in
>  /var/run/squid which is owned by proxy.proxy.

Things are not quite that obvious unfortunately. systemd does not have
all the facts, yet assumes that it does and thus produces incorrect info
about the problem. Or rather it is telling you about a problem *it* has
- which is merely a side effect of what is failing for Squid.

The Squid PID file has always existed at that location and works fine.
The real problem is elsewhere.

> The error seems to be in multiple places, also in some autogenerated
> systemd files for squid.service.

There are at least three errors happening in a cascade. One is whatever
stops Squid from starting correctly. The next is systemd cannot find
Squid's PID file - (because Squid did not start). The third is that the
way systemd is hacked into the LSB init system prevents it finding out
and reporting the initial probem Squid is having.


Please run "squid -k parse 2>&1" and provide the output.

Also please mention if you had any other version of squid installed in
the past, and which that was.

Amos

Bug#849682: postfix-pcre: postfix looks for (/usr/lib/postfix/dict_pcre.so instead of postfix-pcre.so.1.0.1

[Amos Jeffries]

Severity: grave

Bumping severity since the lack of maps ill often result in postfix 
being unable to perform its purpose of mail delivery.


Several of the other postfix-* packages seems to be encountering this 
same type of problem.


AYJ

Bug#850400: postfix-mysql 3.1.4-1 regression with postfix-mysql.so stops sending and receiving mail

[Amos Jeffries]

Package: postfix-mysql
Version: 3.1.4-1
Severity: grave

I am using postfix with postfix-mysql mappings for mailboxes, 
forwarding, and filters. On upgrade from 3.1.3-6 the mailserver appears 
to upgrade successfully, but stops sending or receiving mail.



/var/log/mail.err contains only these repeated errors:

Jan  6 18:02:34 rio postfix/proxymap[14297]: error: unsupported 
dictionary type: mysql

Jan  6 18:02:34 rio last message repeated 12 times
Jan  6 18:02:34 rio postfix/proxymap[14297]: fatal: too many errors - 
program terminated

...


/var/log/mail.log starts with a mix of errors about each map, until 
proxymap daemon gets restarted. Then it settles on the real problem:


Jan  6 18:02:34 rio postfix/proxymap[14297]: warning: unsupported 
dictionary type: mysql (/usr/lib/postfix/postfix-mysql.so.1.0.1: No such 
file or directory)


The new postfix-mysql package installs this library file as:

-rw-r--r--  1 root root  17984 Jan  5 13:55 postfix-mysql.so


Reverting to 3.1.3-6 or creating a symlink for postfix-mysql.so.1.0.1 
can be used as a workaround.



AYJ

Bug#848493: squid3: CVE-2016-10002 SQUID-2016:11: Information disclosure in HTTP Request processing

[Amos Jeffries]

CVE-2016-10002 has been assigned for this.

Bug#848491: squid3: CVE-2016-10003 SQUID-2016:10: Information disclosure in Collapsed Forwarding

[Amos Jeffries]

CVE-2016-10003 has been assigned for this.

Bug#180886: RE:OpenSSL layer of GNUTLS

[Amos Jeffries]

Sadly the GnuTLS support in Squid-3 is quite limited. It is not enough
to consider the current SSL bugs closed.

I am making some progress in Squid-4, but still not quite there and that
version will probably not make it into Stretch. Maybe backports later
next year.

Amos

Bug#834282: ITP: squid-prefetch -- Simple page-prefetch for Squid3 web proxy

[Amos Jeffries]

FYI: the concept of pre-fetching HTTP objects was designed to resolve
problems inherent in the HTTP/1.0 protocol. Where objects needed a
completely new fetch to be performed once they became stale.

Squid-2 packages being HTTP/1.0 software had this problem with caching
and the squid-prefetch package was relevant.


The world has since moved to using HTTP/1.1 where this problem has been
largely resolved by cache revalidation mechanisms. Additionally a
majority portion of the modern web content is dynamically generated and
the only thing prefetching does for this traffic is massively increase
bandwidth and server loadings. Effectively DoS'ing some services.

Squid-3 packages are HTTP/1.1 software and does not need the operations
performed by the squid-prefetch package. This is why the squid3 package
has never been linked to the squid-prefetch package and partly why the
removal request last year marked squid-prefetch as "obsolete".


Additionally there are some dangerous security implications from
automatically fetching URLs simply because they are mentioned in some
content that is wanted. User tracking and automated fetching of
advertising and malware to say the least.

Please do not prefetch or encourage its use in the modern Internet. The
problems outweigh the benefits.


Cheers
Amos Jeffries
The Squid Software Foundation

Bug#819563: squid3: Some requests never finish after CVE-2015-5400

[Amos Jeffries]

I think this bug is probably the same authentication issue that resulted
in this upstream patch:


It is technically not part of the CVE fix, but is needed to let certain
auth configuration to coninue working once the fix is in place.

Amos

Bug#710014: squid3: Update debian/tests

[Amos Jeffries]

On Mon, 18 Jul 2016 17:52:18 +0200
=?utf-8?q?Santiago_Ruano_Rinc=C3=B3n?=  wrote:
>
> Please, find attached an updated debian/tests dir. I have updated
> Ubuntu's current files and modified some Ubuntu specificities.
>
> Amos, these tests are independent from squid building process. Instead,
> they make it possible to automatically test squid on a running
> environment. The declared dependencies relate only to the testbed
> environment.

Thanks for the update. Yes, I know they are supposed to be testing an
emulation of production systems. Its just that they don't do it well/right.

The issues I have was/is that they used to be far less well documented
(that seems to be better now), and many of the tests are testing things
which are impossible for Debian builds to pass. The prominent TODO list
entries (still) are going on about how to test squidGuard package in
isolation - without using Squid or any of the other test environment
dependencies, that at least should be moved to squidguard package
auto-tests.

Specific examples for anyone with time and interest in fixing them;
 - HTTPS proxy service on a proxy built without (OpenSSL) HTTPS support,
 - Apparmour integration tests for a proxy not packaged with any
AppArmour integration,
 - Upstart configuration and testing for a package without Upstart
integration.

Fine for Ubuntu who build packages with those integrations, but if the
tests actually work they are guaranteed to fail on Debian packages which
don't.

I'm surprised that the HTTPS tests would even work on the Ubuntu
packages they were designed for, which do not have OpenSSL support
either. And when these tests were submitted squidclient did not have any
GnuTLS support. So those tests make some sense now (except not going
through the main proxy), but only since Aug 2015 - not way back in 2013.

Cheers
Amos

Bug#827256: squid3: helper program basic_smb_auth don't work

[Amos Jeffries]

On Tue, 14 Jun 2016 11:07:52 +0200 herrmann wrote:
>
> please have a look at Bug #793400. I couldn't reopen this bug, so I
had to file
> this new one, but it is - in each detail - the very same regression again.

That bug (and this behaviour) was fixed by upstream changes in 3.5.7.

There is no "again" about the situation to make  this a regression. None
of the older 'stable' Debian releases were patched for the problem.

Amos

Bug#826043: apt: gpg validation fails on hurd

[Amos Jeffries]

On 3/06/2016 10:38 p.m., David Kalnischkies wrote:
> 
> btw: I just checked: I introduced the first of the two finds (which is
> the more obvious problem as that codepath is used more) on 7 Jul 2015
> (25f27319) [the other is 6 Dec 2015], so that problem isn't recent but
> lingers there since 1.1 and I have to wonder if something changed in
> regards to this on hurd (or d-i) or if that really is some huge
> Baader-Meinhof bias… [2]
> 
> (and I am bit surprised we had nobody on non-hurd complain about
> 'strange' messages being emitted while using apt-key – but perhaps that
> just means nobody is using apt-key anymore… if only that were true…)


FWIW; I had these messages show up around the end of year after
upgrading a previous install. But that installation was screwed up in
may ways so I didn't report bugs. The usual apt-keys solution seemed to
fix it then but not recently.

This bug was already being discussed before I got satisfied that its a
bug in apt and not myself.

Amos

Bug#824571: FTBFS of mosquitto on Hurd-i386

[Amos Jeffries]

Package: mosquitto
Version: 1.4.8-1
Severity: important

Hi, the mosquitto package fails to build on Hurd citing the following error:

> In file included from /usr/include/errno.h:35:0,
>  from /usr/include/i386-gnu/bits/spin-lock-inline.h:35,
>  from /usr/include/pthread/pthread.h:516,
>  from /usr/include/pthread.h:2,
>  from ./mosquitto_internal.h:34,
>  from logging_mosq.c:21:
> ../config.h:28:18: error: expected identifier before '(' token
>  #  define EPROTO ECONNABORTED


It turns out this is caused by a simple missing include inside the
config.h header file:

  #include 

With that added the build completes.

Thanks
Amos

Bug#823968: squid3: CVE-2016-4553 CVE-2016-4554 CVE-2016-4555 CVE-2016-4556

[Amos Jeffries]

CVE-2016-4553:
 Patch for 3.4 and older is now available at
.

CVE-2016-4554:
 Additional changes are needed than those initially linked to. see the
advisory URL for updated patch links.

CVE-2016-4555:
 Squid-3.1 in wheezy is not affected.

CVE-2016-4556:
 Patch for 3.4 should also apply fairly easily to 3.1, but has not been
tested.
 Also, the severity of this issue is much reduced for Debian since SSL
is not enabled.
 Though it still remains an issue for CDN and reverse-proxy installations.


HTH
Amos

Bug#822952: squid3-3.4.8-6

[Amos Jeffries]

Control: severity -1 wishlist

Debian packages are not built with OpenSSL, which makes this not of much
relevance for Debian.

Upstream supported releases already contain this fix. So if one was
following upstream advice and building the latest Squid code for TLS/SSL
there would be no problem.

Amos

Bug#819523: squid3 in wheezy-backports has unmet dependencies

[Amos Jeffries]

Luigi,
  Since this is in the amd64 package and wheezy-backports does not even
contain the libraries mentioned I suspect this is due to the package
binary being the one generated in your build environment for upload.
Requesting a re-build on the normal amd64 buildd should resolve this.

Amos

Bug#819102: [squid-users] Negotiate wrappter returns AF = on Debian Jessie

[Amos Jeffries]

On 18/03/2016 7:29 a.m., James Zuelow wrote:
> Hello -
> 
> I have Squid 3.4.8 installed on Debian Jessie.
> 
> I'm using the negotiate wrapper configured like this:
> 
> auth_param negotiate program /usr/lib/squid3/negotiate_wrapper_auth -d \
>--kerberos /usr/lib/squid3/negotiate_kerberos_auth -s 
> HTTP/proxy.domain.local@DOMAIN.LOCAL \
>--ntlm /usr/bin/ntlm_auth --helper-protocol=gss-spnego 
> --domain=DOMAIN.LOCAL
> 

"--helper-protocol=gss-spnego" configures Negotiate/Kerberos, not
Negotiate/NTLM.

For Negotiate/NTLM what you need is "--helper=squid-2.5-ntlmssp"


Or, drop the wrapper helper entirely and just use:

 auth_param negotiate program /usr/bin/ntlm_auth \
--helper-protocol=gss-spnego --domain=DOMAIN.LOCAL

Amos

Bug#818747: closed

[Amos Jeffries]

Control: found 818747 0.66.4-6

Unfortunately the fix applied is still not working properly. Hard-coding
the action that the script performs as "start" only works for starting
the daemons, not any other init actions.

It can start the daemons now:

# ps aux | grep "courier-auth"

# /etc/init.d/courier-authdaemon start
[ ok ] Starting Courier authentication services: authdaemond.

# ps aux | grep courier | grep auth
root 17980  0.0  0.4   2220  1184 ?S00:39   0:00
/usr/sbin/courierlogger -pid=/run/courier/authdaemon/pid -start
/usr/lib/courier/courier-authlib/authdaemond
root 17981  0.0  1.1   8404  2884 ?S00:39   0:00
/usr/lib/courier/courier-authlib/authdaemond
...


But that is all:

# /etc/init.d/courier-authdaemon stop
[ ok ] Stopping Courier authentication services: authdaemond.

# ps aux | grep "courier-auth"
root 17980  0.0  0.4   2220  1184 ?S00:39   0:00
/usr/sbin/courierlogger -pid=/run/courier/authdaemon/pid -start
/usr/lib/courier/courier-authlib/authdaemond
root 17981  0.0  1.1   8404  2884 ?S00:39   0:00
/usr/lib/courier/courier-authlib/authdaemond
...


Amos

Bug#818747: courier-authdaemon: init script does not work

[Amos Jeffries]

Package: courier-authdaemon
Version: 0.66.4-5
Severity: grave


After a recent upgrade to courier-authdaemon the init scripts have
ceased controlling the daemon processes.

Producing the error :
 Unknown option '-'


NP: this is after the workaround to bug #818744 has been added to let
the init script actually run.


A full trace is included below. The lines producing this output are in
/lib/init/init-d-script:

+ start-stop-daemon --start --quiet --pidfile /run/courier/pid --startas
/usr/sbin/authdaemond --name authdaemond --exec /usr/sbin/authdaemond --test
+ start-stop-daemon --start --quiet --pidfile /run/courier/pid --startas
/usr/sbin/authdaemond --name authdaemond --exec /usr/sbin/authdaemond --
Unknown option '-'
+ return 2


The /usr/sbin/authdaemond script (aka $DAEMON) is expecting to receive
"start" or "stop", etc as its $1 parameter.

For some reason the /etc/init.d/courier-authdaemon script is ignoring
the error result from init-d-script and returning "exit 0" (success) anyway.


Running these commands manually with the extra daemon parameter works fine:

start-stop-daemon --start --quiet --pidfile /run/courier/pid --startas
/usr/sbin/authdaemond --name authdaemond --exec /usr/sbin/authdaemond --
start

start-stop-daemon --start --quiet --pidfile /run/courier/pid --startas
/usr/sbin/authdaemond --name authdaemond --exec /usr/sbin/authdaemond --
stop




The full output of "/etc/init.d/courier-authdaemon start" when -x is
added to its shell call is listed below:


# /etc/init.d/courier-authdaemon start
+ [ true !=  ]
+ set /etc/init.d/courier-authdaemon start
+ INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
+ . /lib/lsb/init-functions
+ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+ [ -r /lib/lsb/init-functions.d/01-upstart-lsb ]
+ . /lib/lsb/init-functions.d/01-upstart-lsb
+ unset UPSTART_SESSION
+ _RC_SCRIPT=/etc/init.d/courier-authdaemon
+ [ -r /etc/init//etc/init.d/courier-authdaemon.conf ]
+ _UPSTART_JOB=courier-authdaemon
+ [ -r /etc/init/courier-authdaemon.conf ]
+ [ -r /lib/lsb/init-functions.d/20-left-info-blocks ]
+ . /lib/lsb/init-functions.d/20-left-info-blocks
+ FANCYTTY=
+ [ -e /etc/lsb-base-logging.sh ]
+ true
+ PATH=/sbin:/usr/sbin:/bin:/usr/bin
+ export PATH
+ [  = true ]
+ SCRIPTNAME=/etc/init.d/courier-authdaemon
+ basename /etc/init.d/courier-authdaemon
+ scriptbasename=courier-authdaemon
+ [ courier-authdaemon != init-d-script ]
+ script=/etc/init.d/courier-authdaemon
+ shift
+ . /etc/init.d/courier-authdaemon
+ [ true != true ]
+ DAEMON=/usr/sbin/authdaemond
+ DESC=Courier authentication services
+ PIDFILE=/run/courier/pid
+ basename /usr/sbin/authdaemond
+ NAME=authdaemond
+ DESC=Courier authentication services
+ [ none = /run/courier/pid ]
+ [ -z /run/courier/pid ]
+ [ none != /usr/sbin/authdaemond ]
+ [ ! -x /usr/sbin/authdaemond ]
+ [ -r /etc/default/authdaemond ]
+ . /lib/init/vars.sh
+ TMPTIME=0
+ SULOGIN=no
+ DELAYLOGIN=no
+ UTC=yes
+ VERBOSE=no
+ FSCKFIX=no
+ [ -f /etc/default/rcS ]
+ . /etc/default/rcS
+ TMPTIME=0
+ SULOGIN=no
+ DELAYLOGIN=yes
+ VERBOSE=yes
+ FSCKFIX=no
+ unset EDITMOTD
+ unset RAMRUN
+ unset RAMLOCK
+ [ -r /proc/cmdline ]
+ cat /proc/cmdline
+ [  ]
+ [  ]
+ [ -t 0 ]
+ VERBOSE=yes
+ call do_start
+ cmd=do_start
+ shift
+ is_call_implemented do_start_override
+ command -V do_start_override
+ do_start
+ is_call_implemented do_start_prepare
+ command -V do_start_prepare
+ call do_start_prepare
+ cmd=do_start_prepare
+ shift
+ is_call_implemented do_start_prepare_override
+ command -V do_start_prepare_override
+ do_start_prepare
+ do_tmpfiles courier-authdaemon
+ local type path mode user group
+ TMPFILES=/usr/lib/tmpfiles.d/courier-authdaemon.conf
+ [ -r /usr/lib/tmpfiles.d/courier-authdaemon.conf ]
+ echo file: /usr/lib/tmpfiles.d/courier-authdaemon.conf
file: /usr/lib/tmpfiles.d/courier-authdaemon.conf
+ + readcat type path mode user group age arg
 /usr/lib/tmpfiles.d/courier-authdaemon.conf
+ [ #Type = d ]
+ read type path mode user group age arg
+ [ d = d ]
+ mkdir -p /run/courier
+ chmod 0775 /run/courier
+ chown root:courier /run/courier
+ [ -x /sbin/restorecon ]
+ read type path mode user group age arg
+ [ d = d ]
+ mkdir -p /run/courier/authdaemon
+ chmod 0755 /run/courier/authdaemon
+ chown courier:courier /run/courier/authdaemon
+ [ -x /sbin/restorecon ]
+ read type path mode user group age arg
+ [ yes != no ]
+ log_daemon_msg Starting Courier authentication services authdaemond
+ [ -z Starting Courier authentication services ]
+ log_daemon_msg_pre Starting Courier authentication services authdaemond
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xxterm != x ]
+ [ xxterm != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z ]
+ FANCYTTY=1
+ true
+ echo -n []
[] + [ -z authdaemond ]
+ echo -n Starting Courier authentication services: authdaemond
Starting Courier authentication services: authdaemond+
log_daemon_msg_post 

Bug#818744: courier-authdaemon: init.d/courier-authdaemon script hangs

[Amos Jeffries]

Package: courier-authdaemon
Version: 0.66.4-5
Severity: grave


The /etc/init.d/courier-authdaemon script hangs on any use.

It contains the suspicious I/O loop:

if [ -r "$TMPFILES" ]; then
while read type path mode user group; do
if [ "$type" = "d" ]; then
mkdir -p "$path"
chmod "$mode" "$path"
chown "$user:$group" "$path"
[ -x /sbin/restorecon ] && /sbin/restorecon $path
fi
done
fi

which is attempting to read from stdio. But does not prompt the user
about what is expected to be typed in.


Looking at the file represented by $TMPFILES it appears that file is
supposed to be piped to the "while read" instead of waiting for user
input. This alteration makes the script finish and the package install
runs to completion;

if [ -r "$TMPFILES" ]; then
cat $TMPFILES | while read type path mode user group; do
if [ "$type" = "d" ]; then
mkdir -p "$path"
chmod "$mode" "$path"
chown "$user:$group" "$path"
[ -x /sbin/restorecon ] && /sbin/restorecon $path
fi
done
fi


Though I am not sure if the resulting installation is correct yet as
there are other issues somewhere preventing the init.d scripts from
actually doing anything.

"start" command appears to start daemons running. But "stop" command
does nothing despite reporting "[ok] success".

Amos

Bug#817134: squidguard: please update links to Squid proxy

[Amos Jeffries]

Package: squidguard
Version: 1.5-5
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

Please update your package to "Recommends: squid (>= 3.4.0)".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

Thanks
Amos

Bug#817136: c-icap: please update links to Squid proxy

[Amos Jeffries]

Package: c-icap
Version: 1:0.4.2-2
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

Please update your package to be "Suggests: squid (>= 3)".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

Thanks
Amos

Bug#817138: education-main-server: please update links to Squid proxy

[Amos Jeffries]

Package: education-main-server
Version: 1.812
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

Please update your package to "Recommends: squid".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

Thanks
Amos

Bug#817137: calamaris: please update links to Squid proxy

[Amos Jeffries]

Package: calamaris
Version: 2.99.4.5-1
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

It appears that the version requirement is also long stale on the
existing Suggests:squid.

Please update your package to "Suggests: squid".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

Thanks
Amos

Bug#817135: jesred: please update links to Squid proxy

[Amos Jeffries]

Package: jesred
Version: 1.2pl1-21
Severity: minor


The Debian 'squid3' package has been renamed to 'squid' in
Testing/stretch. The 'squid3' package is now a transitional temporary
package that will be removed at some point.

Please update your package to "Depends: squid (>= 3.4)".

If there are any other references to "squid3" in your package they will
also need to be updated. That includes file paths and documentation.

In the package Description's. The formal name for squid is "Squid HTTP
caching proxy" and has been for many years, not the ancient "Internet
Object Cache" term. Please use the current official name or "Squid
proxy" if shortened version is appropriate.

Thanks
Amos

Bug#814333: squid3: SSL error "sec_error_inadequate_key_usage" in the browser

[Amos Jeffries]

Control: severity 814333 important
Control: tags 814333 - newcomer
Control: forwarded 814333 http://bugs.squid-cache.org/show_bug.cgi?id=4102
Control: notfound 814333 3.4.8-6+deb8u1
Control: fixed 814333 3.5.10-1


I am dowgrading this bug on grounds that the issue *does not occur in
any of the official Debian packages*.
Nor is fiddling with the security parameters and operation of TLS a bug
activity suitable for newcomers.


On Tue, 09 Feb 2016 22:51:43 -0200 Y wrote:
>
> I downloaded and compiled the squid through apt-build by adding the
following lines in "/var/cache/apt-build/build/squid3-3.4.8/debian/rules":
> --enable-ssl \
> --enable-ssl-CRTD \
> --with-openssl \
>
> Some https sites aprsentam as error the
"sec_error_inadequate_key_usage" message as error code.
> The errors appear when using Firefox and Iceweasel browsers.

As you noted this was a Mozilla issue (yes *was*). It was fixed in
current Firefox/Iceweasel releases, but several workarounds were also
added to recent Squid versions to not trigger it so easily. Those fixes
are not all suitable for backport IIRC, or they would definitely have
happened already.

Upstream policy is that TLS/SSL users should track the laest releases.
This is particularly important for TLS MITM users such as you (seen in
your choice of build options). There are known vulnerabilities in TLS
MITM for all Squid older than 3.5.10. The non-existence of TLS/SSL in
official Debian packages makes these irrelevant to the Debian security
team. Security issues in the custom additions are *your* problem to
track and fix. I highly recommend building from the Stretch package
instead of patching.


Amos Jeffries
(Squid upstream)

Bug#813854: squid: Please rebuild with '--enable-http-violations'

[Amos Jeffries]

On Sat, 06 Feb 2016 00:50:53 +0100 Kristijan Caprdja wrote:
>
> In order to remove specific headers from responses, squid must be
> built with '--enable-http-violations'.
> This feature seems to have been built-in in the version 2 (present in
wheezy). In the version 3 this is
> a compile time option.
> Please rebuild squid with this option enabled.

Squid already is:
 "configure:31445: HTTP violations support enabled: yes"

The compile-time option in Squid is to *disable* violations support if
wanted, and that is not used in the Debian builds.

If you are having trouble mangling HTTP headers the problem is
elsewhere. Some details about what you are actually trying to do and how
it is not working would be a help.

Amos

Bug#784876: squid3: not compiled with -fpic/-fPIC causes execmod issue

[Amos Jeffries]

On Wed, 22 Jul 2015 17:57:46 +0200 Luigi Gangitano wrote:
> Hi Russel,
>
> Thanks for taking your time and reporting this bug. I did not
understand completely what it’s going on and maybe you can help me
find out.
>
> From my understanding:
>
> - no library is compiled from squid3 sources, thus -fPIC should not be
needed. -fPIE should be used instead;

This is not quite true. Squid is constructed from a collection of
convenience libraries. Which are statically linked as needed to each
binary in the package.
In 3.4 and 3.5 some are still constructed as full static libraries
rather than convenience objects.

My understanding was that -fPIC is needed on the convenience objects,
and -fPIE on the final binaries.
But that libtool takes care of determining which one (of the ones
provided) is to be used on any particular object built.


> - squid3 is compiled with hardening=+all flags and this
includes ‘-fPIE’ which should handle text relocations;

Nod.

> - two symbols are reported from eu-findtextrel:
> * _IO_stdin_used is a private symbol from libc and is not defined in
squid3 sources (nor used directly);
> * _ZTS11ACLStrategyIPKcE does not map to a function, but this may be
my fault in understanding symbol names.
>

This is a virtual class template name.

Amos

Bug#811014: Squid 3.5 does not recognize an option "https_port" in squid.conf

[Amos Jeffries]

With my upstream hat on:

On Thu, 14 Jan 2016 23:05:57 +0300 Goltsov wrote:
> Package: squid
> Version: 3.5.12-1
>
> Binary package squid from Debian Stretch is built with gnutls library:
>
> % ldd /usr/sbin/squid | grep tls
> libgnutls-deb0.so.28 =>
> /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 (0x7fb17c336000)
>
> But if I add string
> https_port 3129
> to /etc/squid.conf file, I have a message in /var/log/squid/cache.log:
> ERROR: 'https_port' requires --with-openssl
>

There are many cryptographic features used in Squid. GnuTLS is used in
that version of Squid for others than the one you are trying.

> Can I use https_port without recompiling squid with openssl library?

No. Which is why the error message says what it does.

> Do you plan to build squid with libgnutls-openssl wrapper? Does this
> make sense?

No. The squid binary requires functionality from OpenSSL APIs which is
not provided through that wrapper. Upstream is aiming at full native
GnuTLS support instead.

Amos Jeffries
Squid Sofware Foundation

Bug#808095: squid3: Squid3 UNAVAILABLE

[Amos Jeffries]

On Tue, 15 Dec 2015 15:52:40 -0800 root wrote:
>
> Tried installing squid 3 on wheezy with aptitude with following error:
>
> squid3:i386 depends on logrotate:i386 (>= 3.5.4-1)
> squid3:i386 depends on netbase:i386 [UNAVAILABLE]
> squid3:i386 depends on squid3-common:i386 (= 3.1.20-2.2deb7ue)
[UNAVAILABLE]

This appears to be file corruption in your apt-get/aptitude state data.
There has never been a 3.1.20-2.2deb7ue version of either squid3 or
squid3-common.

The Debian repositories contain version "3.1.20-2.2+deb7u3" - note the
"+" and "3" characters.

Amos

Bug#761159: squid3: pam_auth does not work - needs setuid/setgid

[Amos Jeffries]

Control: notfound 761159 squid3/3.5.10-1

This issue seems to have disappeared again sometime before 3.5.10. I am
able to use the PAM helper just fine for any user account running as a
non-root user.

Amos

Bug#728144: Bug#771778: squid3: Pinger segfault with libc

[Amos Jeffries]

severity 728144 serious
notforwarded 728144
merge 771778 728144
thanks

I think we have enough hints now to say that the original reports
initiating #771778 and #728144 are the same segfault.

I was wrong about the link to upstream bug #2656 for these two crashes,
that was for the third one that was covered by the CVE issues (resolved
earlier) which got intermingled with bug #728144 discussions.

So, given that these bugs are the same issue - I am merging the reports.

Amos

Bug#728144: squid3: Pinger Segmentation fault in Debug::finishDebug on delete CurrentDebug;

[Amos Jeffries]

tags 728144 +jesse
fixed 728144 3.5.10-1
thanks

The patch confirmed by Geralt as fixing this was finalized as upstream
patch

which still needs to be applied to the 3.4 Jesse packages.

I am marking this as fixed in the current 3.5 packages since the
upstream patch for this particular crash was applied to 3.5, but not 3.4
like the TZ and CVE patches.

Amos

Bug#791247: pstoedit: library transition may be needed when GCC 5 is the default

[Amos Jeffries]

Even weak symbols have some potential to cause problems. Particularly
since templates are involved here.

It looks to me like the library uses string types internally, but would
prefer to link the libc implementations. It may publish other ABI
symbols based on the templates sized or padded to match what the
building GCC believes to be the string ABI.

It would be best to just do a rename and transition for this one IMO.

Amos

Bug#801564: squid: prompting due to modified conffiles which were not modified by the user: /etc/squid/squid.conf

[Amos Jeffries]

We have the problem that the Squid-2.7 configuration settings which are
always present in 2.7 configs, will not run in squid-3.5. In fact will
cause the 3.5 process to halt with a fatal error. So we have a mandatory
automated edit by during the upgrade.

How does one avoid or suppress the dpkg query in this situation?

We are already using the dpkg-maintenance-helper to do all other config
file shuffling. AFAIK that is correctly done.

Amos