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

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

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

Bug#984351: squid: ftbfs with GCC-11

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

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

Bug#966395: Double building?

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

Bug#966395: Double building?

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

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

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

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

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

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

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

Bug#968473: Newer alpha available

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

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

Bug#958708: squid: Squid is still unusable

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

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

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

Bug#960819: squid command failure without systemd

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

Bug#960819: squid command failure without systemd

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

Bug#925836: Your mail

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)

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

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 >

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

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

On Thu, 8 Aug 2019 10:36:13 +0200 (CEST) Sammy Atmadja wrote: > > >

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

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

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

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

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

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:

Bug#920007: squid: basic_ncsa_auth username case sensitivity

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

Bug#916536: squid FTCBFS: multiple reasons

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-c

Bug#916536: squid FTCBFS: multiple reasons

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

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

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

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

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

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

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

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

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

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

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

Bug#907106: (no subject)

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

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

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

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

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

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

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:

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

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

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;

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

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.

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

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

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

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,

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

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

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

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

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

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

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

Bug#895993: squid3 packages need SSL support

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

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

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

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

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

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

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

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

(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

Bug#853668: squid3: ftbfs with GCC-7

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

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

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

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

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

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

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

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.

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

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

Bug#859072: Contribute extended dep8 testing

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

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

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. >

Bug#859072: Contribute extended dep8 testing

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

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

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

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

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 ...

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

> 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

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

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

Bug#853668: squid3: ftbfs with GCC-7

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

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

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

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

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

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

CVE-2016-10002 has been assigned for this.

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

CVE-2016-10003 has been assigned for this.

Bug#180886: RE:OpenSSL layer of GNUTLS

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

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

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

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, >

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

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

Bug#826043: apt: gpg validation fails on hurd

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

Bug#824571: FTBFS of mosquitto on Hurd-i386

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

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

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

Bug#822952: squid3-3.4.8-6

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.

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

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

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

Bug#818747: closed

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" #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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'

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

  1   2   3   >