bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 32 bit to 64 bit casting


From: KeithG
Subject: Re: 32 bit to 64 bit casting
Date: Mon, 27 Jun 2022 20:04:32 -0500

On Fri, Jun 24, 2022 at 4:35 AM Petr Pisar <petr.pisar@atlas.cz> wrote:
>
> V Wed, Jun 22, 2022 at 06:42:44PM -0500, KeithG napsal(a):
> > On Wed, Jun 22, 2022 at 12:16 PM Petr Pisar <petr.pisar@atlas.cz> wrote:
> > > That patch does not seem right. gnutls_x509_crt_get_expiration_time() 
> > > returns
> > > time_t and now is also time_t.
> > >
> > > Either there is a bug in gnutls, or glibc, or simply the expiration time 
> > > of
> > > the certificate is not representable with 32-bit time_t type. I would not 
> > > be
> > > surprised if it were the last case.
> > >
> > > Can you post here a complete certificate chain the server presents to 
> > > wget?
> > > You can use "openssl s_client -connect THE_HOST:https -showcerts to 
> > > obtain it.
> > > If it so, than the only fix is to recompile your system with 
> > > "-D_TIME_BITS=64
> > > -D_FILE_OFFSET_BITS=64" CFLAGS. (Provided your platform supports it.)
> > >
> > > -- Petr
> >
> > I am not sure what I need to reply when the command completes. I typed
> > '0'. This is on an armv7 running arch linux:
> >
> > # openssl s_client -connect google.com:https -showcerts
> > CONNECTED(00000003)
> > depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
> > verify return:1
> > depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
> > verify return:1
> > depth=0 CN = *.google.com
> > verify return:1
> > ---
> > Certificate chain
> >  0 s:CN = *.google.com
> >    i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
>
> The certificates look good. Their timestamps fit into 32-bit time_t
> resolution.
>
> Are you sure a machine where wget fails has correctly set clock? The server
> certificate expires on Aug 29 08:29:45 2022 GMT.
>
> I tried wget-1.21.3 built with GnuTLS on i686 machine, which is also 32-bit
> platform, with Fedora operating system and I don't observe any failure.
>
> Can you try using GnuTLS client directly on the affected system? Make sure
> an argument of --x509cafile option points to a file with all CA certificates:
>
> gnutls-cli --x509cafile /etc/ssl/certs/ca-bundle.crt --port https google.com
>
> If this is a bug in GnuTLS (or some of its libraries), it should fail,
> too.
>
> -- Petr

Petr,

Well, once again, I am not sure how to use this command. When it
waited for input, I typed 0. This is what it reported:

# gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt --port
https google.com
Processed 141 CA certificate(s).
Resolving 'google.com:https'...
Connecting to '142.251.32.14:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=*.google.com', issuer `CN=GTS CA 1C3,O=Google Trust
Services LLC,C=US', serial 0x58ace5940b417864129d531a39cb0067,
EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2022-06-06
08:29:46 UTC', expires `2022-08-29 08:29:45 UTC',
pin-sha256="TVChrtTOiGvjGdQIZ3RIvpmzut12LaJKHQdZOLnNUEk="
    Public Key ID:
        sha1:b4d72943613a2630de62c3e21029deba02492767
        sha256:4d50a1aed4ce886be319d408677448be99b3badd762da24a1d075938b9cd5049
    Public Key PIN:
        pin-sha256:TVChrtTOiGvjGdQIZ3RIvpmzut12LaJKHQdZOLnNUEk=

- Certificate[1] info:
 - subject `CN=GTS CA 1C3,O=Google Trust Services LLC,C=US', issuer
`CN=GTS Root R1,O=Google Trust Services LLC,C=US', serial
0x0203bc53596b34c718f5015066, RSA key 2048 bits, signed using
RSA-SHA256, activated `2020-08-13 00:00:42 UTC', expires `2027-09-30
00:00:42 UTC', pin-sha256="zCTnfLwLKbS9S2sbp+uFz4KZOocFvXxkV06Ce9O5M2w="
- Certificate[2] info:
 - subject `CN=GTS Root R1,O=Google Trust Services LLC,C=US', issuer
`CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE', serial
0x77bd0d6cdb36f91aea210fc4f058d30d, RSA key 4096 bits, signed using
RSA-SHA256, activated `2020-06-19 00:00:42 UTC', expires `2028-01-28
00:00:42 UTC', pin-sha256="hxqRlPTu1bMS/0DITB1SSu0vd4u/8l8TjPgfaAp63Gc="
- Status: The certificate is trusted.
- Description: 
(TLS1.3-X.509)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
- Session ID: 
7F:0D:EB:E2:55:CF:B7:38:EF:C4:73:7C:3B:8F:C0:E4:C8:47:60:BA:E6:C1:1F:D2:20:99:42:A4:3F:C3:68:69
- Options:
- Handshake was completed

- Simple Client Mode:

0
HTTP/1.0 400 Bad Request
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer
Content-Length: 1555
Date: Tue, 28 Jun 2022 00:59:23 GMT

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1,
width=device-width">
  <title>Error 400 (Bad Request)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px
arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7%
auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* >
body{background:url(//www.google.com/images/errors/robot.png) 100% 5px
no-repeat;padding-right:205px}p{margin:11px 0
22px;overflow:hidden}ins{color:#777;text-decoration:none}a
img{border:0}@media screen and
(max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png)
no-repeat;margin-left:-5px}@media only screen and
(min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png)
no-repeat 0% 0%/100%
100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png)
0}}@media only screen and
(-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png)
no-repeat;-webkit-background-size:100%
100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>400.</b> <ins>That’s an error.</ins>
  <p>Your client has issued a malformed or illegal request.
<ins>That’s all we know.</ins>
*** Fatal error: The TLS connection was non-properly terminated.
*** Server has terminated the connection abnormally.

My clock seems to be correct:

# timedatectl
               Local time: Mon 2022-06-27 20:03:44 CDT
           Universal time: Tue 2022-06-28 01:03:44 UTC
                 RTC time: n/a
                Time zone: America/Chicago (CDT, -0500)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no



reply via email to

[Prev in Thread] Current Thread [Next in Thread]