Conference on 25 - 28 September, 2018.

[United Nations]

Dear Invitee, Nonprofit/NGO Colleague,

United Nations General Assembly is convening a four-day Global Summit of 
Economists, Educationists, Administrators, Manufacturers, International 
Finance, Corporate Finance, Researchers,, Religious Leaders, Organizations, 
lawyer and law firm,individuals,Ambassador , Permanent Representative from the 
public and Private Sector from 25 - 28 September, 2018 in London (UK) to assess 
the worst global economic down turn since the Great Depression. The aim is to 
identify emergency and long-term responses to mitigate the impact of the 
crisis, especially on vulnerable populations, and initiate a needed dialogue on 
the transformation of the international financial architecture, taking into 
account the needs and concerns of all countries of the world. You are invited 
to take part in the International Conference.

The United Nations summit coming up in September was mandated at the Follow-up 
International Conference on Financing for held in June 2009 in New-York. Member 
States requested the General Assembly to organize the meeting "at the highest 
level".

Registration to this Conference is absolutely "free" As an invitee, you have 
received a registration code UN/11416/2018-UNA-UK with the invitation letter, 
which grants you access to the registration form.

The United Nations General Assembly will sponsor free travel costs and 
all-round flight tickets for all participant. Invited participants will only be 
responsible for their hotel accommodation and feeding cost at the Queen Gate 
Hotel London. The International Convention & Exhibition Centre (ICC) London, 
United Kingdom is the venue of this summit, while the Queen Gate Hotel London 
has been officially designated to accommodate all participant for this unique 
and prestigious global financial and economic crisis summit. If you require an 
entry visa to London (UK) to attend this meeting, United Nations General 
Assembly will help you to obtain a visa so easily once you confirm your 
registration.

For further details about registration form,visa,flight ticket and other 
details, write an acceptance letter to be part of this event and send it 
directly email to United Nations Secretary-General - UK, Ms. Natalie 
Samarasinghe: u...@sdc-un.org

We look forward to meeting you at the forthcoming Global Financial and Economic 
Crisis conference. UK action. Stronger UN. Better world.

Regards,

Mrs. Karen Pierce,
United Nations Officer.

42 St John's Square, 
London EC1M 4EA, 
United Kingdom.
Tel: +44(0) 752 06 28673
Fax: +44(0) 872 75 10220

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Andrey Repin]

Greetings, R0b0t1!

>> Please feel free to provide, using your superior understanding, a detailed 
>> spec
>> for how POSIX ACLs and permissions should be implemented using Windows ACLs
>> while maintaining "canonical" ACL order.

> Or at the very least can another explanation of what is wrong be
> offered? I still don't get it.

As has been said, certain POSIX-specific behavior can't be translated to
canonical ACE order.
Though I'm using noacl mounts, so I yet to face such issue myself.

P.S.
Please tech your mail agent to not quote raw email addresses.
Don't feed spambots.


-- 
With best regards,
Andrey Repin
Tuesday, August 7, 2018 0:08:01

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[R0b0t1]

On Mon, Aug 6, 2018 at 10:49 AM, Brian Inglis
 wrote:
>
> Please feel free to provide, using your superior understanding, a detailed 
> spec
> for how POSIX ACLs and permissions should be implemented using Windows ACLs
> while maintaining "canonical" ACL order.

Or at the very least can another explanation of what is wrong be
offered? I still don't get it.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: segfault with iconv

[cyg Simple]

On 8/5/2018 11:55 PM, Steven Penny wrote:
> On Sun, 5 Aug 2018 23:04:54, cyg Simple wrote:
>> I'm getting a segfault with iconv with the attached script.  Do others
>> have this problem?  TIA for the information.
> 
> Not sure what is breaking for you - but works fine here:
> 
>    $ echo böse bübchen > infile.txt
> 
>    $ LC_ALL=C iconv --byte-subst '<%X>' -f ASCII -t ASCII infile.txt
>    bse bbchen
> 
>    $ LC_ALL=en_US.UTF-8 iconv --byte-subst '<%X>' -f ASCII -t ASCII
> infile.txt
>    bse bbchen
> 

Thanks for checking.  My problem has been resolved with a reinstall.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Brian Inglis]

On 2018-08-05 08:23, Stefan Kanthak wrote:
> Andrey Repin wrote:
>> Greetings, Stefan Kanthak!
>>> PS: 
>>> too states bloody lies:
>>> | The Windows subsystem only supports CWD paths of up to 258 chars.
>> 260 including drive letter.
> WRONG, AGAIN!
> 260 is the value of MAX_PATH, which accounts for the trailing \0, and
> commonly used as
> | char buffer[MAX_PATH];
> I recommend to read
> 
> VERY careful!
>>> The Win32 API supports pathnames with up to 32767 (Unicode) characters; 
>>> this includes of course the CWD!
>> CWD may be, but command processor does not.
> Neither Cygwin's WRONG documentation nor I referred to the command processor.

Please feel free to provide, using your superior understanding, a detailed spec
for how POSIX ACLs and permissions should be implemented using Windows ACLs
while maintaining "canonical" ACL order.
Windows "canonical" order is preferred because it allows Windows to make short
cut assumptions to meet Windows' security policy objectives.
But MS do not enforce that order in the kernel ACL mechanism because they
recognize that other customers may have different security policy objectives
which may be better achieved using different ACLs and orders.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: wget does not recognize PKI?

[Brian Inglis]

On 2018-08-05 14:03, Csaba Raduly wrote:
> On Sun, Aug 5, 2018 at 7:36 PM, Marco Atzeri  wrote:
>> Am 05.08.2018 um 19:12 schrieb Andrey Repin:
>>> $ wget https://ca.rootdir.org/ca.crl
>>> --2018-08-05 20:05:28--  https://ca.rootdir.org/ca.crl
>>> Resolving ca.rootdir.org (ca.rootdir.org)... 192.168.1.6
>>> Connecting to ca.rootdir.org (ca.rootdir.org)|192.168.1.6|:443...
>>> connected.
>>> ERROR: The certificate of ‘ca.rootdir.org’ is not trusted.
>>> ERROR: The certificate of ‘ca.rootdir.org’ hasn't got a known issuer.
>>> What's going on?
>> It seems not a cygwin issue:
>> "This connection is not secure
>> The owner of ca.rootdir.org did not properly configure the site. Firefox has
>> not affiliated with this site to protect your information from theft."
> And not just Firefox :
> $ curl -v https://ca.rootdir.org/ca.crl
> * STATE: INIT => CONNECT handle 0x600057990; line 1404 (connection #-5000)
> * Added connection 0. The cache now contains 1 members
> * STATE: CONNECT => WAITRESOLVE handle 0x600057990; line 1440 (connection #0)
> *   Trying 77.50.25.68...
> * TCP_NODELAY set
> * STATE: WAITRESOLVE => WAITCONNECT handle 0x600057990; line 1521
> (connection #0)
> * Connected to ca.rootdir.org (77.50.25.68) port 443 (#0)
> * STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057990; line 1573
> (connection #0)
> * Marked for [keep alive]: HTTP default
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
> * successfully set certificate verify locations:
>   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>   CApath: none
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
> * STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x600057990; line
> 1587 (connection #0)
> * TLSv1.2 (IN), TLS handshake, Server hello (2):
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> * TLSv1.2 (OUT), TLS alert, Server hello (2):
> * SSL certificate problem: self signed certificate in certificate chain
> * Marked for [closure]: Failed HTTPS connection
> * multi_done
> * stopped the pause stream!
> * Closing connection 0
> * The cache now contains 0 members
> * Expire cleared
> curl: (60) SSL certificate problem: self signed certificate in certificate 
> chain
> More details here: https://curl.haxx.se/docs/sslcerts.html
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.

Given that it's his own domain and root cert, not surprising it's not in
Mozilla's root CA list.
Lots of business gets done using counterparty certs with organization CA roots
not in any public or central repos, or just self-signed: avoids accessing or
giving CAs any info or money and dealing with fallout from vendor issues.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Self-compiled xorg-server 1.20.0 crashes at startup, buffer overflow

[tumtum00]

On 3 August 2018 8:14 PM, Jon Turney wrote:
> Anyhow, I think to fix this, you need a cygwin with the following
> changes (the latest snapshot should be ok)
>
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=4564b30f331a067e71b25308ac7c8a85ceb4b122;hp=4d1a356f7b36905f5e2b616513b111ef042f1a43
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=e494b560350cabef94126a4478096aae89ae35a0

That does indeed solve the problem. For reference, I used the snapshot from 
2018-07-25. Thank you very much for the assistance.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ssh cause mintty terminal not to close (tested on 4 cygwin installations)

[Ænkå]

On 2018-08-04 00:24, Andrey Repin wrote:

Greetings, Niels Kristian Jensen!


This may seem like a minor thing, but we have much trouble with
Jenkins
builds (started via Cygwin OpenSSH) which randomly hang forever - I
wonder
 if this could be a clue in this investigation.



(cut)


Try upgrading your mintty, also, if it's about automated building
environment,
I don't see how's mintty can be involved.


If the "non-closure" of mintty  is completely internal in mintty and 
not

a handshake-mistake with the cygwin dll or the OS, then I agree. It
seems to be the case, reading the link provided by Thomas Wolff.


What I wanted to say is that I don't understand, why do you use mintty 
in this

specific case.

Can you provide a bit more background? Do you use it exclusively to 
call SSH

to some remote host?


Hello Andrey,

let's forget about the hanging mintty window. I was chasing a ghost, it 
seems.

Mintty is not involved in the Jenkins automation chain.

I'll write another post where I try to list my trouble and experiments 
with hanging

Jenkins builds invoked via OpenSSH in cygwin on windows slaves/agents.

Best regards,
Niels Kristian Jensen

--
Spejd er sejt!

Det Danske Spejderkorps
--

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: wget does not recognize PKI?

[Andrey Repin]

Greetings, Lee!

> On 8/5/18, Andrey Repin wrote:
>> Greetings, All!

> Greetings, Andrey Repin!

>> $ wget https://ca.rootdir.org/ca.crl
>> --2018-08-05 20:05:28--  https://ca.rootdir.org/ca.crl
>> Resolving ca.rootdir.org (ca.rootdir.org)... 192.168.1.6
>> Connecting to ca.rootdir.org (ca.rootdir.org)|192.168.1.6|:443...
>> connected.
>> ERROR: The certificate of ‘ca.rootdir.org’ is not trusted.
>> ERROR: The certificate of ‘ca.rootdir.org’ hasn't got a known issuer.
>>
>> $ "$( which wget )" --version
>> GNU Wget 1.19.1 built on cygwin.
>>
>> -cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls +ntlm
>> +opie +psl +ssl/gnutls
>>
>> The root CA certificate is correctly installed and hashed.

> Apparently not.

curl and openssl sees it.
Both Cygwin and native openssl.

> Does it work if you tell wget to use your root CA cert?
> ‘--ca-certificate=FILE’

It does, of course, but why doesn't it see the PKI by itself?

$ wget --ca-certificate=/etc/ssl/certs/dd07c56a.0 https://ca.rootdir.org/ca.crl
--2018-08-06 12:46:14--  https://ca.rootdir.org/ca.crl
Loaded CA certificate '/etc/ssl/certs/dd07c56a.0'
Resolving ca.rootdir.org (ca.rootdir.org)... 192.168.1.6
Connecting to ca.rootdir.org (ca.rootdir.org)|192.168.1.6|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 872 [application/octet-stream]
Saving to: ‘ca.crl’

ca.crl   100%[>] 872  
--.-KB/sin 0s

2018-08-06 12:46:14 (18.0 MB/s) - ‘ca.crl’ saved [872/872]

>  Use FILE as the file with the bundle of certificate authorities
>  (“CA”) to verify the peers.  The certificates must be in PEM
>  format.

>  Without this option Wget looks for CA certificates at the
>  system-specified locations, chosen at OpenSSL installation time.

> & you probably have, but to be sure.. you looked at 'info
> update-ca-trust' - right?

No. Hashing /etc/ssl/certs has been enough for a long while.
I followed the directions, and it indeed fixed the issue, but I'm surprised by
the change in behavior.


-- 
With best regards,
Andrey Repin
Monday, August 6, 2018 12:44:13

Sorry for my terrible english...

Re: wget does not recognize PKI?

[Andrey Repin]

Greetings, Csaba Raduly!

> On Sun, Aug 5, 2018 at 7:36 PM, Marco Atzeri  wrote:
>> Am 05.08.2018 um 19:12 schrieb Andrey Repin:
>>>
>>> Greetings, All!
>>>
>>> $ wget https://ca.rootdir.org/ca.crl
>>> --2018-08-05 20:05:28--  https://ca.rootdir.org/ca.crl
>>> Resolving ca.rootdir.org (ca.rootdir.org)... 192.168.1.6
>>> Connecting to ca.rootdir.org (ca.rootdir.org)|192.168.1.6|:443...
>>> connected.
>>> ERROR: The certificate of ‘ca.rootdir.org’ is not trusted.
>>> ERROR: The certificate of ‘ca.rootdir.org’ hasn't got a known issuer.
>>>
>>
>>>
>>> What's going on?
>>>
>>
>> It seems not a cygwin issue:
>>
>> "This connection is not secure
>>
>> The owner of ca.rootdir.org did not properly configure the site. Firefox has
>> not affiliated with this site to protect your information from theft."
>>

As I said, the root CA certificate is properly installed.

> And not just Firefox :

> $ curl -v https://ca.rootdir.org/ca.crl

$ curl -v https://ca.rootdir.org/ca.crl
* STATE: INIT => CONNECT handle 0x600057ac0; line 1404 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x600057ac0; line 1440 (connection #0)
*   Trying 192.168.1.6...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x600057ac0; line 1521 (connection 
#0)
* Connected to ca.rootdir.org (192.168.1.6) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057ac0; line 1573 
(connection #0)
* Marked for [keep alive]: HTTP default
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
  CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x600057ac0; line 1587 
(connection #0)
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=RU; ST=RF; L=Moscow; CN=Rootdir CA webserver
*  start date: Nov 21 17:47:29 2017 GMT
*  expire date: Nov 22 17:47:29 2018 GMT
*  subjectAltName: host "ca.rootdir.org" matched cert's "ca.rootdir.org"
*  issuer: C=RU; L=Moscow; CN=Andrey Repin; emailAddress=anrdae...@rootdir.org
*  SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x600057ac0; line 1608 (connection #0)
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x600057ac0)
> GET /ca.crl HTTP/2
> Host: ca.rootdir.org
> User-Agent: curl/7.59.0
> Accept: */*
>
* STATE: DO => DO_DONE handle 0x600057ac0; line 1670 (connection #0)
* multi changed, check CONNECT_PEND queue!
* STATE: DO_DONE => WAITPERFORM handle 0x600057ac0; line 1795 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x600057ac0; line 1811 (connection #0)
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* multi changed, check CONNECT_PEND queue!
* HTTP/2 found, allow multiplexing
< HTTP/2 200
< server: nginx/1.14.0
< date: Mon, 06 Aug 2018 09:41:25 GMT
< content-type: application/octet-stream
< content-length: 872
< last-modified: Sun, 05 Aug 2018 16:51:59 GMT
< etag: "5b672b2f-368"
< accept-ranges: bytes
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: " to save to a file.
* Failed writing body (0 != 872)
* Kill stream: Transfer returned error
* multi_done
* Connection #0 to host ca.rootdir.org left intact
* Expire cleared

[23]anrdaemon@daemon2:xterm:~
$ "$( which curl )" --version
curl 7.59.0 (x86_64-unknown-cygwin) libcurl/7.59.0 OpenSSL/1.0.2o zlib/1.2.11 
libidn2/2.0.4 libpsl/0.18.0 (+libidn2/2.0.2) libssh2/1.7.0 nghttp2/1.31.0
Release-Date: 2018-03-14
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS Debug IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM 
NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL Metalink


-- 
With best regards,
Andrey Repin
Monday, August 6, 2018 12:41:08

Sorry for my terrible english...
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#un

[ANNOUNCEMENT] Updated: Onigurama 6.8.2-1

[Marco Atzeri]

Versions 6.8.2-1 of

  libonig5  (API Bump)
  liboning-devel

have been uploaded.

CHANGES
New upstream version
https://github.com/kkos/oniguruma/releases

DESCRIPTION
Oniguruma is a regular expressions library.
The characteristics of this library is that different character encoding
for every regular expression object can be specified.
(supported APIs: GNU regex, POSIX and Oniguruma native)

Supported character encodings:
ASCII, UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE,
EUC-JP, EUC-TW, EUC-KR, EUC-CN,
Shift_JIS, Big5, GB18030, KOI8-R, CP1251,
ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5,
ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10,
ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16

HOMEPAGE
https://github.com/kkos/oniguruma

Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: WARNING: Couldn't compute FAST_CWD pointer.

[Csaba Raduly]

Hi,

On Mon, Aug 6, 2018 at 2:01 AM, Anietie Essiet  wrote:
> Hello
>
> I tried to edit a code file on SIM to be able to run a new algorithm,
> however I am getting the above subject warning. How do I correct this
> please?
>

https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings

Csaba
-- 
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: wget does not recognize PKI?

[Lee]

On 8/5/18, Andrey Repin wrote:
> Greetings, All!

Greetings, Andrey Repin!

> $ wget https://ca.rootdir.org/ca.crl
> --2018-08-05 20:05:28--  https://ca.rootdir.org/ca.crl
> Resolving ca.rootdir.org (ca.rootdir.org)... 192.168.1.6
> Connecting to ca.rootdir.org (ca.rootdir.org)|192.168.1.6|:443...
> connected.
> ERROR: The certificate of ‘ca.rootdir.org’ is not trusted.
> ERROR: The certificate of ‘ca.rootdir.org’ hasn't got a known issuer.
>
> $ "$( which wget )" --version
> GNU Wget 1.19.1 built on cygwin.
>
> -cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls +ntlm
> +opie +psl +ssl/gnutls
>
> The root CA certificate is correctly installed and hashed.

Apparently not.  Does it work if you tell wget to use your root CA cert?
‘--ca-certificate=FILE’
 Use FILE as the file with the bundle of certificate authorities
 (“CA”) to verify the peers.  The certificates must be in PEM
 format.

 Without this option Wget looks for CA certificates at the
 system-specified locations, chosen at OpenSSL installation time.

& you probably have, but to be sure.. you looked at 'info
update-ca-trust' - right?

This might help verify your trust store:
$ cat listcerts.sh
#!/bin/sh
# ref: 
https://serverfault.com/questions/590870/how-to-view-all-ssl-certificates-in-a-bundle

if [ $# -eq 1 ]; then
   # bundle specified
   FILE="$1"
   if [ ! -r $FILE ]; then
  echo "p1 unreadable: $FILE"
  exit 1
   fi
else
   FILE="/usr/ssl/certs/ca-bundle.crt"
 # FILE="/etc/pki/tls/certs/ca-bundle.crt"
 # FILE="/etc/pki/tls/certs/ca-bundle.trust.crt"
fi


cat $FILE |\
awk -v cmd="openssl x509 -noout -subject " '
/^-BEGIN/ { c = $0; next }
{ c = c "\n" $0 }
/^-END/ { print c|cmd; close(cmd); c = "" }
'

# openssl x509 -noout -text
#  to see all the certificate info
# oopenssl x509 -noout -subject
#  to see just the subject

$

Regards,
Lee

>
> $ ls -l /etc/ssl/certs/
> total 3
> lrwxrwxrwx  1 anrdaemon None  13 мар 31 01:30 a94d09e5.0 -> ca-bundle.crt
> lrwxrwxrwx  1 anrdaemon None  49 мар 12 02:29 ca-bundle.crt ->
> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
> lrwxrwxrwx  1 anrdaemon None  55 мар 12 02:29 ca-bundle.trust.crt ->
> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
> lrwxrwxrwx  1 anrdaemon None  18 мар 31 01:30 dd07c56a.0 ->
> Rootdir.org_CA.crt
> drwxr-xr-x+ 1 anrdaemon None   0 апр 22 16:50 demo
> drwxr-xr-x+ 1 anrdaemon None   0 апр 22 16:50 expired
> -rw-r--r--  1 anrdaemon None 165 апр  3 14:04 README.RootCerts
> lrwxrwxrwx  1 anrdaemon None  29 фев 14 04:41 Rootdir.org_CA.crt ->
> /etc/ssl/ca-20120530-0121.crt
>
> What's going on?
>
>
> --
> With best regards,
> Andrey Repin
> Sunday, August 5, 2018 20:07:02
>
> Sorry for my terrible english...

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple