Running paket.boostrapper.exe no longer works in Ubuntu 14.04. This seems to be the same or similar to the issue raised in #1072 but the suggested solution added by #1091 also no longer works.
$ mkdir .paket
$ cd .paket
$ wget "https://github.com/fsprojects/Paket/releases/download/3.6.1/paket.bootstrapper.exe"
$ mono paket.bootstrapper.exe
Checking Paket version (downloading latest stable)...
'Github - cached' download failed. If using Mono, you may need to import trusted certificates using the 'mozroots' tool as none are contained by default. Trying fallback download from 'Nuget - cached'.
Checking Paket version (downloading latest stable)...
Unable to look up the latest version online, the cache contains version 0.
Object reference not set to an instance of an object (Nuget - cached)
Error getting response stream (Write: The authentication or decryption has failed.): SendFailure (Github - cached)
The issue thread and error message suggest using mozroots to import missing certificates. That fails thusly:
$ mozroots --import --sync
Mozilla Roots Importer - version 3.2.8.0
Download and import trusted root certificates from Mozilla's MXR.
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.
Downloading from 'http://mxr.mozilla.org/seamonkey/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1'...
Couldn't retrieve the file using the supplied information.
Bootstrapper downloads paket.exe and/or the suggested mozroots solution solves the certificate problem allowing bootstrapper to download paket.exe.
Bootstrapper does not download paket.exe. Mozroots does not import any certificates.
I'd like to hear of any.
It seems like the only issue in paket itself is that the moztools suggestion in the error message isn't terribly helpful. The old version of mono probably adds many problems in its own right but I haven't been able to find a statement in paket's documentation about a minimum supported version.
/cc @nosami any ideas?!
I bumped into this again today w/ paket 3.21.2 and stumbled across my own issue in searching for solutions.
I fiddled around with adding a --no-ssl command line option to the bootstrapper and that does work around the problem of downloading paket.exe (commit). It's not an optimal solution by any means, but since the internet is littered with out-of-date and inaccurate information about fixing certificate stores in mono it does seem like the path of least resistance.
Is the project open to adding this kind of command line option? The actual paket.exe would need a similar option but I don't want to sink more time into writing it if the PR's just going to be rejected for [admittedly reasonable] concerns about security.
This may be related to the lack of TLS support greater than 1.0 on the mono runtime prior to version 4.6. You are on quite an old mono version, would it be possible to upgrade to 4.6 and try again?
The telltale sign to me that this is the issue is that your wget to grab the bootstrapper works, but the bootstrapper's internal call using WebClient to grab Paket fails.
I have had similar issues when making APIs on Mono, and the new release of 4.6 fixed all of them for me.
I can upgrade myself, but I don't think that's a particularly great solution either. Ubuntu 14.04 is supported through 2019 and will most likely be mono 3.2.x that whole time. If I create a project that claims to support linux but doesn't actually work with the versions of mono that ship with mainstream distros that's just going to create headaches for other contributors and/or end users.
I know, and I agree. The most common workaround I've seen (and this is for web api projects) is to proxy all your https traffic through an nginx container, or something roughly equivalent, that can terminate TLS1.1+.
Terrible answer, I know. If you were doing mobile work, there's actually a drop-in nuget package that delegates to better http clients on the mobile platforms, but nothing for desktop :(
But! on the flip side, if you're working on mono then folks can just deploy the app in a docker container pinned to mono 4.6 without impacting the rest of the environment.
Terrible answer, I know. If you were doing mobile work, there's actually a drop-in nuget package that delegates to better http clients on the mobile platforms, but nothing for desktop :(
That might be a good answer - adding an IDownloadStrategy implementation that delegates the download to wget or curl.
full test run:
docker run --rm -it mono:4.4 /usr/bin/fsharpi
F# Interactive for F# 4.0 (Open Source Edition)
Freely distributed under the Apache 2.0 Open Source License
For help type #help;;
> (new System.Net.WebClient()).DownloadString("https://api.deckbrew.com");;
System.Net.WebException: Error: SecureChannelFailure (The authentication or decryption has failed.) ---> System.IO.IOException: The authentication or decryption has failed. ---> System.IO.IOException: The authentication or decryption has failed. ---> Mono.Security.Protocol.Tls.TlsException: The authentication or decryption has failed.
at Mono.Security.Protocol.Tls.RecordProtocol.EndReceiveRecord (IAsyncResult asyncResult) <0x417ecd10 + 0x000ff> in <filename unknown>:0
at Mono.Security.Protocol.Tls.SslClientStream.SafeEndReceiveRecord (IAsyncResult ar, Boolean ignoreEmpty) <0x417ecc60 + 0x0002b> in <filename unknown>:0
at Mono.Security.Protocol.Tls.SslClientStream.NegotiateAsyncWorker (IAsyncResult result) <0x417e91d0 + 0x00217> in <filename unknown>:0
--- End of inner exception stack trace ---
at Mono.Security.Protocol.Tls.SslClientStream.EndNegotiateHandshake (IAsyncResult result) <0x417ed940 + 0x000bf> in <filename unknown>:0
at Mono.Security.Protocol.Tls.SslStreamBase.AsyncHandshakeCallback (IAsyncResult asyncResult) <0x417ed6e0 + 0x00083> in <filename unknown>:0
--- End of inner exception stack trace ---
at Mono.Security.Protocol.Tls.SslStreamBase.EndRead (IAsyncResult asyncResult) <0x417e7000 + 0x0015b> in <filename unknown>:0
at Mono.Net.Security.Private.LegacySslStream.EndAuthenticateAsClient (IAsyncResult asyncResult) <0x417a6f90 + 0x0003e> in <filename unknown>:0
at Mono.Net.Security.Private.LegacySslStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation) <0x417e14d0 + 0x00055> in <filename unknown>:0
at Mono.Net.Security.MonoTlsStream.CreateStream (System.Byte[] buffer) <0x417e0bd0 + 0x0012e> in <filename unknown>:0
--- End of inner exception stack trace ---
at System.Net.WebClient.DownloadDataInternal (System.Uri address, System.Net.WebRequest& request) <0x417a2270 + 0x00323> in <filename unknown>:0
at System.Net.WebClient.DownloadString (System.Uri address) <0x417a2060 + 0x0004f> in <filename unknown>:0
at System.Net.WebClient.DownloadString (System.String address) <0x4179ba50 + 0x00033> in <filename unknown>:0
at (wrapper remoting-invoke-with-check) System.Net.WebClient:DownloadString (string)
at <StartupCode$FSI_0002>.$FSI_0002.main@ () <0x4179b750 + 0x0003b> in <filename unknown>:0
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) <0x7f35e57592f0 + 0x000a1> in <filename unknown>:0
Stopped due to error
>
@forki would you take this as an acceptable solution? A wrapped version of the WebProxy that detected this particular failure mode (failing when run on mono and the failure is a WebException where secureChannel failed) and then shelled out to system curl to try to download the file/string?
yes definetly. Every hack that makes this thing reliable is considered a good hack!
Alright, I'll try to get one in for you today then
I have run into this today. Using the ubuntu subsystem in windows, I managed to get mono kicking and screaming updated to version 4.6.2, running the latest paket.bootstrap.exe pulled from github still fails and it still seems to be offering bad advice about upgrading the mono certs using mozroots. Frustratingly the mono security faq still mentions mozroots as well which as far as I can tell only points at a dead mozilla cert service and was downloading certs plaintext.
daz@DPLATT-SURFACE:~/seq/Gslc$ wget https://github.com/fsprojects/Paket/releases/download/3.31.0/paket.bootstrapper.exe
--2016-12-04 18:27:59-- https://github.com/fsprojects/Paket/releases/download/3.31.0/paket.bootstrapper.exe
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-cloud.s3.amazonaws.com/releases/22755810/4af31e8c-ba15-11e6-9c30-12052b0cca83.exe?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20161205%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20161205T022802Z&X-Amz-Expires=300&X-Amz-Signature=734426238163b4d79980b2fdf4eab6b0c626436eab229962f1e1fc1fe3d84bda&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dpaket.bootstrapper.exe&response-content-type=application%2Foctet-stream [following]
--2016-12-04 18:28:00-- https://github-cloud.s3.amazonaws.com/releases/22755810/4af31e8c-ba15-11e6-9c30-12052b0cca83.exe?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20161205%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20161205T022802Z&X-Amz-Expires=300&X-Amz-Signature=734426238163b4d79980b2fdf4eab6b0c626436eab229962f1e1fc1fe3d84bda&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dpaket.bootstrapper.exe&response-content-type=application%2Foctet-stream
Resolving github-cloud.s3.amazonaws.com (github-cloud.s3.amazonaws.com)... 54.231.112.168
Connecting to github-cloud.s3.amazonaws.com (github-cloud.s3.amazonaws.com)|54.231.112.168|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 49664 (48K) [application/octet-stream]
Saving to: ‘paket.bootstrapper.exe’
100%[===============================================================================================>] 49,664 163KB/s in 0.3s
2016-12-04 18:28:01 (163 KB/s) - ‘paket.bootstrapper.exe’ saved [49664/49664]
daz@DPLATT-SURFACE:~/seq/Gslc$ mono --version
Mono JIT compiler version 4.6.2 (Stable 4.6.2.7/08fd525 Mon Nov 14 12:30:00 UTC 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen
daz@DPLATT-SURFACE:~/seq/Gslc$ mono paket.bootstrapper.exe
Checking Paket version (downloading latest stable)...
'Github - cached' download failed. If using Mono, you may need to import trusted certificates using the 'mozroots' tool as none are contained by default. Trying fallback download from 'Nuget - cached'.
Checking Paket version (downloading latest stable)...
Unable to look up the latest version online, the cache contains version 0.
Object reference not set to an instance of an object (Nuget - cached)
Error: NameResolutionFailure (Github - cached)
daz@DPLATT-SURFACE:~/seq/Gslc$
Hmm, that error might be a red herring. It looks like my F# installation can't reach any site due to DNS failure. WGET works and the surrounding windows machine is fine, but mono can't do DNS inside F#. Other than the paket error being a bit misleading, this seems like a much more fundamental mono problem.
(new System.Net.WebClient()).DownloadString("http://nytimes.com")
Gives
System.Net.WebException: Error: NameResolutionFailure
at System.Net.WebClient.DownloadDataInternal (System.Uri address, System.Net.WebRequest& request) [0x0008a] in <bd46d4d4f7964dfa9beea098499ab597>:0
at System.Net.WebClient.DownloadString (System.Uri address) [0x00027] in <bd46d4d4f7964dfa9beea098499ab597>:0
at System.Net.WebClient.DownloadString (System.String address) [0x00019] in <bd46d4d4f7964dfa9beea098499ab597>:0
at (wrapper remoting-invoke-with-check) System.Net.WebClient:DownloadString (string)
at <StartupCode$FSI_0001>.$FSI_0001.main@ () [0x00005] in <ad4f9fb0849c468096894657eca257d9>:0
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00038] in <8f2c484307284b51944a1a13a14c0266>:0
Stopped due to error
FWIW, this seems to be a low level mono bug. I've filed a bug report and not a paket problem, although paket could probably use the nameresolutionfailure as a cue that it's not a certificate issue. That's was a little misleading.
I'm having the same problem as @daz10000 (also on BashOnWindows), this has been a right mess to figure out, wondering if there is a fix.
I encountered this same problem on Solus running mono 5.4.1.6 when running paket.bootstrapper.exe or paket.exe. The latter one I can download manually, but how to fix e.g mono paket.exe update?
Strange thing is that it works on CentOS 7.
Most helpful comment
FWIW, this seems to be a low level mono bug. I've filed a bug report and not a paket problem, although paket could probably use the nameresolutionfailure as a cue that it's not a certificate issue. That's was a little misleading.