On Mon, Jun 27, 2016 at 10:09 AM, Landry Breuil <[email protected]> wrote: > On Mon, Jun 27, 2016 at 09:28:06AM +0200, David Coppa wrote: >> On Mon, Jun 27, 2016 at 7:17 AM, Landry Breuil <[email protected]> wrote: >> > On Thu, Jun 23, 2016 at 05:24:58PM -0500, attila wrote: >> >> Hi ports@, >> >> >> >> Here is another try at the Tor Browser Bundle, updated to 6.0.2 just >> >> today. I believe I have addressed all previous concerns: >> >> >> >> * Our extensions now live in /usr/local/lib/... and run directly from >> >> there, they are not unpacked under the user's profile (enabledScopes >> >> solved this); >> >> * addon PLIST files redone to just have the .xpi file; >> >> * No more hardcoded /usr/local paths >> >> * Only addons we actually have to patch are packaged by us; otherwise >> >> we just wrap around the distributed .xpi (noscript, https-everywhere) >> > >> > Great stuff, thanks for spending the time to do all this right ! >> > >> > Why are you overriding FETCH_CMD in noscript subdir ? That looks >> > wrong... >> >> That's because it fails without "-S dont": >> >> >> Fetch >> >> https://secure.informaction.com/download/releases/noscript-2.9.0.11.xpi >> ftp: SSL read error: handshake failed: error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> >> Probably it should be mirrored on a decent web server... > > How... ironic. I think it'd actually be better to fetch it from > addons.mozilla.org, to stress that's the unmodified/official version. > Or get upstream to fix their ssl cert... which seems to be Let's Encrypt > powered, and is valid - opens in firefox.. so i dont get why ftp fails. > > Landry
Reading from https://letsencrypt.org/certificates/, It seems something could be missing from /etc/ssl/cert.pem. Or is it the libressl cert chain problem again? Maybe Stuart can shed some light on this. Ciao! David
