[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Contributing to GNUnet
From: |
Christian Grothoff |
Subject: |
Re: Contributing to GNUnet |
Date: |
Mon, 9 Mar 2020 23:35:08 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 |
On 3/9/20 4:08 PM, Tanguy Le Carrour wrote:
> So, first I've sorted out the mess with my proxy configuration by using an
> add-on
> to properly switch between proxy configs.
> Then, I figured out why Icecat was behaving differently! It's simply because
> `gnunet-gns-proxy-setup-ca` doesn't install the certificate in the Icecat
> profiles!
> It only works for Firefox and Chromium. So I patch the script, ran it again
> and now…
>
> … when I enter the url "gnunet.myself" I'm properly redirected to
> "gnunet.org" and the shield icon says "verified by GNU"… but
> still, nothing shows up!
That is strange.
> In the `gnunet-gns-proxy` logs I only have 2
> lines:
>
> ```
> Mar 09 15:41:41-485690 gnunet-gns-proxy-18131 ERROR Download curl gnunet.org/
> failed: SSL peer certificate or SSH remote key was not OK
> Mar 09 15:41:58-358297 gnunet-gns-proxy-18131 ERROR Download curl
> gnunet.org/favicon.ico failed: SSL peer certificate or SSH remote key was not
> OK
> ```
>
> Any idea?! Have I done something wrong (again)?!
Hard to say. I can't tell if curl fails to accept the Letsencrypt CA, or
if we lack the LEHO somehow. AFAIK Martin was fixing some LEHO-related
bugs in GNS, so MAYBE that is hitting you here.
To find out:
1) check if curl is happy downloading https://gnunet.org/ directly
(thus checking curl is installed properly and finds its root CAs)
2) try adding a TLSA record for gnunet.org to GNS, thereby avoiding
the use of Letsencrypt and really directly verifying via GNS.
3) Maybe enable more logging (-L DEBUG) ;-).
4) Also, given that I have not tried this for a while, there is a
possibility that we have a regression -> Martin or I should also
try (but I can't this week).
> The patch to `gnunet-gns-proxy-setup-ca` is trivial. Should I submit it
> somewhere? Or, as it's a "Guix problem", I can just patch it in the Guix
> package!?
I am pretty sure this is an 'upstream' issue and that we should patch
gnunet-gns-proxy-setup-ca. So please do send the patch (to me personally
will suffice, I'm happy to review and apply).
> And one last question: why is `gnunet-gns-proxy` in
> `/usr/lib/gnunet/libexec/` and
> not in `bin`?
The idea is that the gnunet-gns-proxy is launched via gnunet-arm like
other GNUnet services, instead of being started manually.
> Thanks again for your help!
>
- Contributing to GNUnet, Tanguy Le Carrour, 2020/03/04
- Re: Contributing to GNUnet, Christian Grothoff, 2020/03/04
- Re: Contributing to GNUnet, Schanzenbach, Martin, 2020/03/04
- Re: Contributing to GNUnet, Tanguy Le Carrour, 2020/03/05
- Re: Contributing to GNUnet, Tanguy Le Carrour, 2020/03/09
- Re: Contributing to GNUnet,
Christian Grothoff <=
- Re: Contributing to GNUnet, Tanguy Le Carrour, 2020/03/10
- Re: Contributing to GNUnet, Christian Grothoff, 2020/03/10
- Re: Contributing to GNUnet, Tanguy Le Carrour, 2020/03/13
- Re: Contributing to GNUnet, Schanzenbach, Martin, 2020/03/13
- Re: Contributing to GNUnet, Tanguy Le Carrour, 2020/03/14
- Re: Contributing to GNUnet, Schanzenbach, Martin, 2020/03/14
- Re: Contributing to GNUnet, Tanguy Le Carrour, 2020/03/14
- Re: Contributing to GNUnet, Schanzenbach, Martin, 2020/03/14
- Re: Contributing to GNUnet, Tanguy Le Carrour, 2020/03/14
- Re: Contributing to GNUnet, Martin Schanzenbach, 2020/03/14