Looks like we got the wrong priority for the squid-openssl package in
Debian alternatives config.
To select the variant of Squid you want to use please run:
sudo update-alternatives --config squid
HTH
Amos
ts.
2) before and after copies of the "mgr:mem" report from Squid. With
matching 'top' command output. Maybe also matching "mgr:filedescriptors"
listings.
HTH
Amos
Merged this upstream as
<https://github.com/squid-cache/squid/commit/98062fb537d6371306c005140d38c07367566570>
which was released in Squid 6.11.
Cheers
Amos
found -1 6.12-1
thanks
Upstream have fixed the initial ICMP bugs in v6.
However, building 6.12 sources with "optimize=-lto" still results in a
different FTBFS. The issue has changed to:
store/Disks.cc: In function 'allocate_new_swapdir':
store/Disks.cc:796:63: error: argument 1 value '184467
Forwarded 1049926 https://bugs.squid-cache.org/show_bug.cgi?id=5290
thanks
Upstream patch will be included in upcoming 6.2 release.
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
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
forwarded -1 https://bugs.squid-cache.org/show_bug.cgi?id=5131
thanks
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
that.
Amos
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
Op
on a technicality. The upstream work still needs some help
testing changes against libssl 1.1.
Amos
ache.org/SquidFaq/BugReporting>.
Amos
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
r 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
pen
Which is a completely different problem from the one this bug is about.
Amos
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
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
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.
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
> affec
tures of Squid-4 and C++11 compiler
capabilities not supported in Squid-3.x. So the port has some work required.
Amos
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
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
rect 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
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 con
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
le; I replicated the reported behaviour using just this:
auth_param basic program /usr/lib/squid/basic_fake_auth -d
HTH
Amos
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-compi
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 d
config.
Full disclosure:
I am the up-upstream Squid maintainer. Issues such as this which are
specific to Debian and derivatives I leave to Luigi our DM to make the
call on.
That said, my call would be to leave these settings or any updated
version of them under control of squid-deb-proxy so admin can opt-in by
using that package on their proxy machines.
Cheers
Amos
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
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 argume
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 t
e 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
^~~
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
same results
and linker lines which are now suddenly FTBFS. See the working 4.1
upload for reference.
Amos
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 sof
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]:
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
This was closed upstream long ago. See upstream bug report for details.
thanks
Amos
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
.
If it is sysV, please check that your NetworkManager init script is
running well before Squid's.
Amos
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
Can you provide the command used to cross-build for replicating this bug?
Amos
e 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
ted features including ssl-crtd still
require OpenSSL builds.
Amos
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] <https://lists.debian.org/debian-devel/2
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
forwarded +1 https://bugs.squid-cache.org/show_bug.cgi?id=4847
thanks
with GnuTLS support for basic TLS
operations. OpenSSL is also working on a license change. Both are
ongoing works.
Cheers,
Amos
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
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 workarou
Package: squid
Version: 4.0.21-1~exp5
This should be fixed in the upcoming Squid-4 packages.
Amos Jeffries
alias with Squid-3.
Either use the init Script provided by the package, or 'squid -k'
commands directly.
Amos
racking 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
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
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
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
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 "Instal
.
Anything like that identifiable on the local network?
Amos
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
Thank you. I am adding these to the Squid-4 package.
Amos
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
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:
>
> > Than
ts 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
pgrades. But I/we wrongly
assumed the --compare-versions would return false if there was no
previous version.
Amos
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
rt to 3.5
stable releases, so I am doubtful Jesse will ever see a better
Squid-systemd interaction.
Amos
ttp://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13944.patch>.
The squid 3.5 package in Squeeze is already fixed with that upstream change.
Amos
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
uid'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
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
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 re
CVE-2016-10002 has been assigned for this.
CVE-2016-10003 has been assigned for this.
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
ast.
Please do not prefetch or encourage its use in the modern Internet. The
problems outweigh the benefits.
Cheers
Amos Jeffries
The Squid Software Foundation
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
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 build
.
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
ion 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
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
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
.
Amos
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
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
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
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 scr
;$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
mends: 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
;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
"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
ment 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
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
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)
e 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
to a function, but this may be
my fault in understanding symbol names.
>
This is a virtual class template name.
Amos
?
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
6 (= 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
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
1 - 100 of 335 matches
Mail list logo
