Re: Undefined reference to gnutls_protocol_set_priority() when compiling latest wget version

[Tim Rühsen]

On 19.05.20 21:15, Stephen Kirby wrote:
> Hi,
> 
> One additional piece that may/may not be relevant:
> 
> When I use secure protocol, i.e., https instead of http, it says:
> 
> "Reading HSTS entries from .wget-hsts file in com.example.myapplication dir"
> 
> Should I create a .wget-hsts file?  I don't see one yet.  If so, can
> someone please help me with the format of this file in order to allow me
> to access the URL I need?  Thanks.

Short answer: Just ignore it.

Long answer: Some servers tell you to use HTTPS instead of HTTP and that
you should remember that. Wget remembers those requests and the next
time you try such a page using HTTP, wget switches automatically to
HTTPS (without contacting the server first). That saves time, resources
and is more secure.

Don't manually change that file if you don't know exactly what you do.
All is done automatically for you.

> 
> Best,
> Steve
> 
> On Tue, May 19, 2020 at 12:55 PM Stephen Kirby <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Tim,
> 
>     Thanks for that.  I like the idea of rebuilding GnuTLS so I don't
>     have to add the --ca-directory flag, but will hold on that until I
>     can resolve the connecting problem.
> 
>     I added the --ca-directory=/system/etc/security/cacerts flag to the
>     wget call and now see this (still not connecting and pulling the
>     file, but slightly different message):
> 
>     Certificates loaded: 138
>     Resolving (URL) ... failed: Name or service not known
>     wget: unable to resolve host address '(URL)'
> 
>     OK - so this begs these questions:
>     (1) How can I find out if the (hash #).0 files in the --ca-directory
>     I point to are PEM format and thus readable?
>     (2) Assuming they are readable, and are PEM format, how can I update
>     one of them, or create a new PEM format file, that will allow access
>     to the URL I need?
> 
>     thanks,
>     Steve
> 
>     On Tue, May 19, 2020 at 1:43 AM Tim Rühsen <address@hidden
>     <mailto:address@hidden>> wrote:
> 
>         Stephen,
> 
>         you should use the --ca-directory=directory options for this.
> 
>         That one loads all PEM files in that directory into the internal
>         GnuTLS
>         cert store. The file naming doesn't matter, only the content
>         must be PEM.
> 
>         You wouldn't have that hassle if GnuTLS would have been built
>         with the
>         correct system cert store set. As far as I know, that would be
>         "./configure
>         --with-default-trust-store-dir=/system/etc/security/cacerts".
> 
>         Regards, Tim
> 
>         On 19.05.20 00:10, Stephen Kirby wrote:
>         > Tim,
>         >
>         > Thanks for that clarification.   You are correct --
>         >
>         > I checked the x86-based Google Pixel emulator and there is no
>         > /etc/ssl/certs directory.  Rather it appears this OS puts
>         certificates
>         > in: /system/etc/security/cacerts.  There the files are named
>         (hash #'s).0. 
>         >
>         > Do I need to tell wget to look in this directory instead?  The
>         relevant
>         > flag available with wget looks to be "--ca-certificate=FILE". 
>         However,
>         > I do not know, out of the 30 or so files in the aforementioned
>         directory
>         > I should point to.  Furthermore does wget require these
>         certificate
>         > files strictly be either PEM or DER format?  Not sure what the
>         format of
>         > the files in /system/etc/security/cacerts on this emulator
>         are?  Sorry
>         > for this short list of questions.  Just trying to get a feel
>         for what to
>         > do next...
>         >
>         > Best,
>         > Steve
>         >
>         > On Sun, May 17, 2020 at 12:24 PM Tim Rühsen
>         <address@hidden <mailto:address@hidden>
>         > <mailto:address@hidden <mailto:address@hidden>>> wrote:
>         >
>         >     -1250 is a GnuTLS failure "GNUTLS_E_UNIMPLEMENTED_FEATURE"
>         returned by
>         >     gnutls_certificate_set_x509_system_trust().
>         >
>         >     Due to a bug, this is output instead of the real number of
>         certs loaded.
>         >
>         >     The fallback code tries to open /etc/ssl/certs to search for
>         >     certificates. But it seems, this doesn't exist on your system.
>         >
>         >     Regards, Tim
>         >
>         >     On 16.05.20 19:15, Stephen Kirby wrote:
>         >     > Hi all,
>         >     >
>         >     > Tim let me know I only responded to him instead of the
>         list.  My
>         >     bad and
>         >     > thanks for noticing!  So here is what I sent Tim the
>         other day --
>         >     >
>         >     > Thanks all for you inputs!
>         >     >
>         >     > I just tried adding the --debug flag and get one more
>         piece of info:
>         >     > certificates loaded: -1250
>         >     >
>         >     > I am not seeing this error code on a quick search. 
>         Maybe someone
>         >     on the
>         >     > list knows what it means?.
>         >     >
>         >     > Thanks for the strace suggestion.  I do see it on the phone
>         >     emulator and am
>         >     > thinking next I would run an strace on my Debian Linux
>         system
>         >     where my wget
>         >     > is working and compare it to the strace on the mobile
>         emulator
>         >     where wget
>         >     > is failing.
>         >     >
>         >     > thanks,
>         >     > Steve
>         >     >
>         >     > On Sat, May 16, 2020 at 5:24 AM Tim Rühsen
>         <address@hidden <mailto:address@hidden>
>         >     <mailto:address@hidden <mailto:address@hidden>>>
>         wrote:
>         >     >
>         >     >> Hi Stephen,
>         >     >>
>         >     >> please answer to the mailing list, so everybody can
>         participate :)
>         >     >>
>         >     >> Regards, Tim
>         >     >>
>         >     >> On 15.05.20 20:22, Stephen Kirby wrote:
>         >     >>> Thanks all for you inputs!
>         >     >>>
>         >     >>> I just tried adding the --debug flag and get one more
>         piece of info:
>         >     >>> certificates loaded: -1250
>         >     >>>
>         >     >>> Any idea what this code means?
>         >     >>>
>         >     >>> It does look like the emulator has strace.  I will
>         check this as
>         >     well...
>         >     >>>
>         >     >>> thanks,
>         >     >>> Steve
>         >     >>>
>         >     >>> On Fri, May 15, 2020 at 12:07 PM Tim Rühsen
>         <address@hidden <mailto:address@hidden>
>         >     <mailto:address@hidden <mailto:address@hidden>>
>         >     >>> <mailto:address@hidden <mailto:address@hidden>
>         <mailto:address@hidden <mailto:address@hidden>>>> wrote:
>         >     >>>
>         >     >>>     On 15.05.20 19:08, Stephen Kirby wrote:
>         >     >>>     > Petr/Everyone,
>         >     >>>     >
>         >     >>>     > Thanks so much for your detailed recommendations
>         on how to
>         >     >>>     proceed.  You
>         >     >>>     > were spot on regarding
>         gnutls_priority_set_direct.  I
>         >     looked at
>         >     >>>     config.log
>         >     >>>     > and noticed configure was failing due to a
>         missing pthread
>         >     lib.  I
>         >     >>>     inserted
>         >     >>>     > that, then had to fix some other missing
>         symbols.  Anyway,
>         >     I have a
>         >     >>>     > statically linked wget that I have now pushed
>         onto the
>         >     Google Pixel
>         >     >>>     > Emulated phone I have running via Android Studio.
>         >     >>>     >
>         >     >>>     > I can definitely move this question to another
>         forum if
>         >     you all
>         >     >>>     believe it
>         >     >>>     > better since it involves an emulated Google
>         Pixel phone now
>         >     >>>     (x86_64 arch.),
>         >     >>>     > but it has to do with wget still, so if I may
>         please:
>         >     >>>     >
>         >     >>>     > on the emulated phone, I am trying:
>         >     >>>     >
>         >     >>>     > wget -O filename http://###.##.###.## (i.e.,
>         here I use the IP
>         >     >> address
>         >     >>>     > found via nslookup on the named URL)
>         >     >>>     >
>         >     >>>     > Then, I get:
>         >     >>>     > HTTP request sent, awaiting response... 302
>         object moved
>         >     >>>     > Location: https://(here it lists the correctly
>         named URL)
>         >     >>>     > Resolving (named URL)... Failed: Name or Server
>         not known
>         >     >>>     > wget: unable to resolve host address "named URL"
>         >     >>>     >
>         >     >>>     > I'll note that this wget call works perfectly on
>         my Debian
>         >     Linux
>         >     >>>     > system, downloading the file I need.
>         >     >>>     > Also interesting to me is the fact that I can ping
>         >     _successfully_
>         >     >>>     both the
>         >     >>>     > URL by name or its associated IP address, on the
>         emulated
>         >     phone
>         >     >>>     So, not
>         >     >>>     > sure why wget would throw this error.
>         >     >>>
>         >     >>>     wget uses getaddrinfo(), except you built it with
>         c-ares.
>         >     >>>
>         >     >>>     Perhaps you have 'strace' installed !?
>         >     >>>     Then you could start wget with strace and see what
>         fails (or why
>         >     >>>     getaddrinfo fails).
>         >     >>>
>         >     >>>     Regards, Tim
>         >     >>>
>         >     >>
>         >     >>
>         >
>

signature.asc
Description: OpenPGP digital signature