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

[Stephen Kirby]

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.

Best,
Steve

On Tue, May 19, 2020 at 12:55 PM Stephen Kirby <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> 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>> 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>> 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>>> 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
>> >     >>>
>> >     >>
>> >     >>
>> >
>>
>>