That's fixed for me now with the new version of GnuTLS 3.7.1
Thanks!
Best regards,
Grigorii
On Tue, 9 Mar 2021 at 20:30, Bob Proulx wrote:
> Erik Auerswald wrote:
> > Grigoriy Sokolik wrote:
> > > I've rechecked:
> >
> > I cannot reproduce the problem, the certificate is trusted by my system:
Erik Auerswald wrote:
> Grigoriy Sokolik wrote:
> > I've rechecked:
>
> I cannot reproduce the problem, the certificate is trusted by my system:
>
> # via IPv4
> $ gnutls-cli --verbose translationproject.org 'Connecting|Status'
> Connecting to '80.69.83.146:443'...
> - Status:
Hi,
On Tue, Mar 09, 2021 at 11:28:18AM +0200, Grigoriy Sokolik wrote:
> I've rechecked:
I cannot reproduce the problem, the certificate is trusted by my system:
# via IPv4
$ gnutls-cli --verbose translationproject.org [...]issuer `CN=DST Root CA X3,O=Digital Signature Trust
I've rechecked:
```
$ gnutls-cli translationproject.org
Processed 139 CA certificate(s).
Resolving 'translationproject.org:443'...
Connecting to '80.69.83.146:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
-
Is this problem still a problem? Perhaps it has been fixed in the
time this has been under discussion? Because it looks okay to me.
Grigoriy Sokolik wrote:
>$ curl -v https://translationproject.org/latest/coreutils/ -o /dev/null
...
>* Connected to translationproject.org (80.69.83.146)
The thing is that translationproject returns the wrong certificate.
Thanks!
Best regards,
Grigorii
On Tue, 16 Feb 2021 at 19:28, Paul Eggert wrote:
> On 2/15/21 3:07 AM, Grigoriy Sokolik wrote:
>
> > But be careful, this is really bad advice: fetching anything without
> > consistency ad
On 2/15/21 3:07 AM, Grigoriy Sokolik wrote:
But be careful, this is really bad advice: fetching anything without
consistency ad authority validation is really insecure!
Yes, we should instead fix the underlying problem whatever it is (not
sure what it is since that wasn't reported).
The temporary workaround could be, at least to skip the certificate
validation:
```
$ git --no-pager diff
diff --git a/bootstrap b/bootstrap
index 7523f65b4..dcb8aa388 100755
--- a/bootstrap
+++ b/bootstrap
@@ -180,7 +180,7 @@ bootstrap_epilogue() { :; }
# specified directory. Fill in the first
I have the same issue.
Some investigations:
1. I decided to find out the particular command that fails and added
more debug print:
diff --git a/bootstrap b/bootstrap
index 7523f65b4..44c21db23 100755
--- a/bootstrap
+++ b/bootstrap
@@ -749,6 +749,7 @@ download_po_files() {
When running ./bootstrap in a freshly-cloned repository, it seems to either
not find some files it wants to or doesn't trust https://translationproject.org.
Connecting to https://translationproject.org in a (non-wget) web browser works
fine.
The following is the output of ./bootstrap.
```
10 matches
Mail list logo
