Re: [squid-users] Can't verify the signature of squid-6.7.tar.gz

[Amos Jeffries]

On 8/02/24 02:19, Miha Miha wrote:

Hi Francesco,

I still get an issue, although a slightly different one:

#gpg --verify squid-6.7.tar.gz.asc squid-6.7.tar.gz
gpg: Signature made Tue 06 Feb 2024 10:51:28 PM EET using ? key ID FEF6E865
gpg: Can't check signature: Invalid public key algorithm




The error mentions algorithm, so also check the ciphers/algorithms 
supported by your GPG agent. The new key uses the EDDSA cipher instead 
of typical RSA.





When I try to import the public keys (pgp.asc file) I see:

#gpg --import pgp.asc

...
gpg: key FEF6E865: no valid user IDs
gpg: this may be caused by a missing self-signature
...

All the rest keys have an user and e-mail.

When I list the imported pub keys with   gpg --list-keys I see
multiple keys, but not the FEF6E865

May be the pub key hasn't been properly imported?



Please check the contents of squid-6.7.tar.gz.asc. The full key ID 
should be provided there (FEF6E865 is one of its short-forms).


If you have any doubts about the keyring (pgp.asc file), you can try to 
fetch a fresh copy of it from 




FTR; this is what I get working from a clean /tmp/squid pseudo-chroot 
directory to avoid my actual trusted+known keys:


## mkdir /tmp/squid

## wget http://master.squid-cache.org/pgp.asc

## gpg --homedir /tmp/squid --import pgp.asc
gpg: WARNING: unsafe permissions on homedir '/tmp/squid'
gpg: keybox '/tmp/squid/pubring.kbx' created
gpg: key B268E706FF5CF463: 1 duplicate signature removed
gpg: key B268E706FF5CF463: 4 signatures not checked due to missing keys
gpg: /tmp/squid/trustdb.gpg: trustdb created
gpg: key B268E706FF5CF463: public key "Amos Jeffries 
" imported

gpg: key 4250AB432402F2F8: 1 signature not checked due to a missing key
gpg: key 4250AB432402F2F8: public key "Duane Wessels 
" imported

gpg: key E75E90C039CC33DB: 202 signatures not checked due to missing keys
gpg: key E75E90C039CC33DB: public key "Henrik Nordstrom 
" imported

gpg: key 867BF9A9FBD3EB8E: 605 signatures not checked due to missing keys
gpg: key 867BF9A9FBD3EB8E: public key "Robert Collins 
" imported

gpg: key CD6DBF8EF3B17D3E: 1 signature not checked due to a missing key
gpg: key CD6DBF8EF3B17D3E: public key "Amos Jeffries (Squid Signing Key) 
" imported
gpg: key 28F85029FEF6E865: public key "Francesco Chemolli (code signing 
key) " imported
gpg: key 3AEBEC6EC66648FD: public key "Francesco Chemolli (kinkie) 
" imported

gpg: Total number processed: 7
gpg:   imported: 7
gpg: no ultimately trusted keys found

## wget http://master.squid-cache.org/Versions/v6/squid-6.7.tar.gz
## wget http://master.squid-cache.org/Versions/v6/squid-6.7.tar.gz.asc

## gpg --homedir /tmp/squid --verify squid-6.7.tar.gz.asc squid-6.7.tar.gz
gpg: WARNING: unsafe permissions on homedir '/tmp/squid'
gpg: Signature made Wed 07 Feb 2024 09:51:28 NZDT
gpg:using EDDSA key 29B4B1F7CE03D1B1DED22F3028F85029FEF6E865
gpg: Good signature from "Francesco Chemolli (code signing key) 
" [unknown]

gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the 
owner.

Primary key fingerprint: 29B4 B1F7 CE03 D1B1 DED2  2F30 28F8 5029 FEF6 E865



HTH
Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] stale-if-error returning a 502

[Amos Jeffries]

On 8/02/24 07:45, Robin Carlisle wrote:

Hi,

I have just started my enhanced logging journey and have a small snippet 
below that might illuminate the issue ...


/2024/02/07 17:06:39.212 kid1| 88,3| client_side_reply.cc(507) 
handleIMSReply: origin replied with error 502, forwarding to client due 
to fail_on_validation_err/




Please check the log for the earlier 22,3 line saying "checking 
freshness of URI: ".


All the 22,3 lines between there and your found 88,3 line will tell the 
story of why refresh was done. That will give an hint about why the 
fail_on_validation_err flag was set.



Cheers
Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] stale-if-error returning a 502

[Alex Rousskov]

On 2024-02-07 13:45, Robin Carlisle wrote:
I have just started my enhanced logging journey and have a small snippet 
below that might illuminate the issue ...


/2024/02/07 17:06:39.212 kid1| 88,3| client_side_reply.cc(507) 
handleIMSReply: origin replied with error 502, forwarding to client due 
to fail_on_validation_err/


This confirms that Squid considers the cached response stale and, hence, 
applies the last bullet logic from my earlier summary ("object age 
exceeding X"). We still do not know why.




should I generate more detailed logs and send them privately?


Privately sharing a pointer to the current (or, better, ALL,9) 
compressed logs while reproducing the problem is (still) the best way 
forward IMO.



Cheers,

Alex.



On Fri, 2 Feb 2024 at 11:20, Robin Carlisle wrote:

Hi, thanks for your reply.

I have been looking at :
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control 


/The stale-if-error response directive indicates that the cache can
reuse a stale response when an upstream server generates an error,
or when the error is generated locally. Here, an error is considered
any response with a status code of 500, 502, 503, or 504.

Cache-Control: max-age=604800, stale-if-error=86400
In the example above, the response is fresh for 7 days (604800s).
Afterwards, it becomes stale, but can be used for an extra 1 day
(86400s) when an error is encountered.

After the stale-if-error period passes, the client will receive any
error generated/

Given what you have said and what the above docs say - I am still
confused as it looks like (in my test cases) the cached response can
be used for 3600 secs (this works), after which the cached response
can still be used for an additional 31536000 seconds on an error
(this doesnt work).

I am going to dig into the error logging you suggested to see if I
can make sense of that - and will send on if I can't.

Thanks v much for your help again,

Robin





On Thu, 1 Feb 2024 at 18:27, Alex Rousskov wrote:

On 2024-02-01 12:03, Robin Carlisle wrote:
 > Hi, I am having trouble with stale-if-error response.

If I am interpreting Squid code correctly, in primary use cases:

* without a Cache-Control:stale-if-error=X in the original
response,
Squid sends a stale object if revalidation results in a 5xx error;

* with a Cache-Control:stale-if-error=X and object age at most
X, Squid
sends a stale object if revalidation results in a 5xx error;

* with a Cache-Control:stale-if-error=X and object age exceeding X,
Squid forwards the 5xx error response if revalidation results in
a 5xx
error;

In other words, stale-if-error=X turns on a "fail on validation
errors"
behavior for stale objects older than X. It has no other effects.

In your test case, the stale objects are much younger than
stale-if-error value (e.g., Age~=3601 vs. stale-if-error=31536000).
Thus, stale-if-error should have no relevant effect.

Something else is probably preventing your Squid from serving
the stale
response when facing a 5xx error. I do not know what that
something is.

I recommend sharing (privately if you need to protect sensitive
info) a
pointer to a compressed ALL,9 cache.log collected while
reproducing the
problem (using two transactions similar to the ones you have shared
below -- a successful stale hit and a problematic one):

https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction 


Alternatively, you can try to study cache.log yourself after
setting
debug_options to ALL,3. Searching for "refresh" and
"handleIMSReply" may
yield enough clues.


HTH,

Alex.




 > # /etc/squid/squid.conf :
 >
 > acl to_aws dstdomain .amazonaws.com 
>
 >
 > acl from_local src localhost
 >
 > http_access allow to_aws
 >
 > http_access allow from_local
 >
 > cache allow all
 >
 > cache_dir ufs /var/cache/squid 1024 16 256
 >
 > http_port 3129 ssl-bump cert=/etc/squid/maul.pem
 > generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
 >
 > sslcrtd_program /usr/lib/squid/security_file_certgen -s
 > /var/lib/squid/ssl_db -M 4MB
 >
 > acl step1 at_step SslBump1
 >
 > ssl_bump bump step1
 >
 > ssl_bump bump all
 >
 > sslproxy_cert_error den

Re: [squid-users] stale-if-error returning a 502

[Robin Carlisle]

Hi,

I have just started my enhanced logging journey and have a small snippet
below that might illuminate the issue ...

*2024/02/07 17:06:39.212 kid1| 88,3| client_side_reply.cc(507)
handleIMSReply: origin replied with error 502, forwarding to client due to
fail_on_validation_err*

A few lines below in the log it looks like squid sent :-















*2024/02/07 17:06:39.212 kid1| 11,2| Stream.cc(280) sendStartOfMessage:
HTTP Client REPLY:-HTTP/1.1 502 Bad GatewayServer:
squid/5.7Mime-Version: 1.0Date: Wed, 07 Feb 2024 17:06:39 GMTContent-Type:
text/html;charset=utf-8Content-Length: 3853X-Squid-Error: ERR_READ_ERROR
0Vary: Accept-LanguageContent-Language: enX-Cache: MISS from
labs-maul-st-15X-Cache-Lookup: HIT from labs-maul-st-15:3129Via: 1.1
labs-maul-st-15 (squid/5.7)Connection: close*


The rest of the logs are quite large and contain URLs I cannot put here.
 The logs were generated with debug_options to ALL,3.

Any ideas?   Or should I generate more detailed logs and send them
privately?

Thanks again,

Robin




On Fri, 2 Feb 2024 at 11:20, Robin Carlisle 
wrote:

> Hi, thanks for your reply.
>
> I have been looking at :
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
>
>
>
>
>
>
> *The stale-if-error response directive indicates that the cache can reuse
> a stale response when an upstream server generates an error, or when the
> error is generated locally. Here, an error is considered any response with
> a status code of 500, 502, 503, or 504.Cache-Control: max-age=604800,
> stale-if-error=86400In the example above, the response is fresh for 7 days
> (604800s). Afterwards, it becomes stale, but can be used for an extra 1 day
> (86400s) when an error is encountered.After the stale-if-error period
> passes, the client will receive any error generated*
>
> Given what you have said and what the above docs say - I am still confused
> as it looks like (in my test cases) the cached response can be used for
> 3600 secs (this works), after which the cached response can still be used
> for an additional 31536000 seconds on an error (this doesnt work).
>
> I am going to dig into the error logging you suggested to see if I can
> make sense of that - and will send on if I can't.
>
> Thanks v much for your help again,
>
> Robin
>
>
>
>
>
> On Thu, 1 Feb 2024 at 18:27, Alex Rousskov <
> rouss...@measurement-factory.com> wrote:
>
>> On 2024-02-01 12:03, Robin Carlisle wrote:
>> > Hi, I am having trouble with stale-if-error response.
>>
>> If I am interpreting Squid code correctly, in primary use cases:
>>
>> * without a Cache-Control:stale-if-error=X in the original response,
>> Squid sends a stale object if revalidation results in a 5xx error;
>>
>> * with a Cache-Control:stale-if-error=X and object age at most X, Squid
>> sends a stale object if revalidation results in a 5xx error;
>>
>> * with a Cache-Control:stale-if-error=X and object age exceeding X,
>> Squid forwards the 5xx error response if revalidation results in a 5xx
>> error;
>>
>> In other words, stale-if-error=X turns on a "fail on validation errors"
>> behavior for stale objects older than X. It has no other effects.
>>
>> In your test case, the stale objects are much younger than
>> stale-if-error value (e.g., Age~=3601 vs. stale-if-error=31536000).
>> Thus, stale-if-error should have no relevant effect.
>>
>> Something else is probably preventing your Squid from serving the stale
>> response when facing a 5xx error. I do not know what that something is.
>>
>> I recommend sharing (privately if you need to protect sensitive info) a
>> pointer to a compressed ALL,9 cache.log collected while reproducing the
>> problem (using two transactions similar to the ones you have shared
>> below -- a successful stale hit and a problematic one):
>>
>> https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction
>>
>> Alternatively, you can try to study cache.log yourself after setting
>> debug_options to ALL,3. Searching for "refresh" and "handleIMSReply" may
>> yield enough clues.
>>
>>
>> HTH,
>>
>> Alex.
>>
>>
>>
>>
>> > # /etc/squid/squid.conf :
>> >
>> > acl to_aws dstdomain .amazonaws.com 
>> >
>> > acl from_local src localhost
>> >
>> > http_access allow to_aws
>> >
>> > http_access allow from_local
>> >
>> > cache allow all
>> >
>> > cache_dir ufs /var/cache/squid 1024 16 256
>> >
>> > http_port 3129 ssl-bump cert=/etc/squid/maul.pem
>> > generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>> >
>> > sslcrtd_program /usr/lib/squid/security_file_certgen -s
>> > /var/lib/squid/ssl_db -M 4MB
>> >
>> > acl step1 at_step SslBump1
>> >
>> > ssl_bump bump step1
>> >
>> > ssl_bump bump all
>> >
>> > sslproxy_cert_error deny all
>> >
>> > cache_store_log stdio:/var/log/squid/store.log
>> >
>> > logfile_rotate 0
>> >
>> > shutdown_lifetime 3 seconds
>> >
>> >
>> > # /usr/bin/proxy-test :
>> >
>> > #!/bin/bash
>> >
>> > curl --proxy http://localhost:3129 

Re: [squid-users] Can't verify the signature of squid-6.7.tar.gz

[Miha Miha]

Hi Francesco,

I still get an issue, although a slightly different one:

#gpg --verify squid-6.7.tar.gz.asc squid-6.7.tar.gz
gpg: Signature made Tue 06 Feb 2024 10:51:28 PM EET using ? key ID FEF6E865
gpg: Can't check signature: Invalid public key algorithm

When I try to import the public keys (pgp.asc file) I see:

#gpg --import pgp.asc

...
gpg: key FEF6E865: no valid user IDs
gpg: this may be caused by a missing self-signature
...

All the rest keys have an user and e-mail.

When I list the imported pub keys with   gpg --list-keys I see
multiple keys, but not the FEF6E865

May be the pub key hasn't been properly imported?

Regards,
Mihail

On Wed, Feb 7, 2024 at 12:55 AM Francesco Chemolli  wrote:
>
> Hi,
>   apologies, that's on me, I had uploaded the wrong version of a file. It 
> should be okay now, can you recheck?
>
>
> On Tue, 6 Feb 2024 at 21:18, Miha Miha  wrote:
>>
>> Hi there,
>>
>> When I try to verify the authenticity of squid-6.7.tar.gz file I get:
>>
>> gpg: Signature made Sun 04 Feb 2024 08:22:04 PM EET using RSA key ID F48F8EAB
>> gpg: Can't check signature: No public key
>>
>> I don't see a key with ID F48F8EAB in the public chain in pgp.asc file
>> Could you please double check?
>>
>> Regards,
>> Mihail
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> https://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users