-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Digest::SHA1::Native requirement fails #105
Comments
Hmm, I think it's supposed to make the DLL from this source. It's unclear why it complains about the file it's meant to be building not being found.
I don't believe we have any choice in the matter, since it's used to implement the WebSocket protocol, and the protocol makes use of SHA1. The RFC explicitly notes that it does not rely on the SHA1 security properties, so while it is the case that SHA1 is today considered weak in contexts where that matters, this isn't one of them.
Depends what you actually need; if you only need the HTTP libraries and don't care about the |
I have the full gcc toolchain installed, so I'll give the SHA1 build a test run and report back. In the meantime, running "zef install Cro::HTTP" results in the following error: λ zef install Cro::HTTP ===> Testing [FAIL]: IO::Socket::Async::SSL:ver<0.7.4> Looks like a function signature is missing (?) |
Any update on this? Having the same issue about |
Thanks for making Cro - it looks really fantastic. I'm also trying to install Cro on Windows 10. I'm getting the same missing DLL issue as Dean. As for just trying zef install Cro::HTTP, I get the following: ===> Searching for: Cro::HTTP -- would be great to overcome these issues. I mainly want to try the HTTP client, so any suggestion how to fix? Thanks. |
|
Thanks @Altai-man - IO::Path::ChildSecure now appears in zef list, but I still have the sha1.dll issue. @PowellDean could you overcome the issue? What is the recommended OS for using Cro? |
ok I did some deep consideration... in short, the gmake issue can be solved by installing strawberry perl and thereafter it's possible to install cro, but I still have a problem. By way of background, I found I could build the DLL separately via cygwin (by downloading the SHA1 project separately, running 'raku Configuration.p6' and running 'make'). This encouraged me to perhaps see if installing rakudo under cygwin might be a good idea, until I dug around the rakudo.org site, and found out about strawberry perl as pre-req for building rakudo from scratch for Windows. The strawberry perl site indicated it comes with gcc build tools, so I guessed it would have gmake, and so that is a solution. So in raku I see this error when running the demo code: use Cro::HTTP::Client; Original exception:
If I use a HTTP address, there's no problem. I have openSSL install on my windows PC, so I'm not sure what the problem is. Any tips appreciated. |
@michaeldesu : Apologies for the slow reply. I wasn't able to successfully overcome the issue, so you got farther than I did. I can confirm that my version of the gcc suite came via Strawberry Perl. I've recently done a full refresh of both Raku and Strawberry so I'll see if I can find the time to try building as you suggest. I dual-boot the same hardware to Linux, and the demo code you post above works like a charm with no complaints on Ubuntu 20.04 (Rakudo version 2020.05.1 built on MoarVM version 2020.05). Given the current issue I'd suggest that Cro is built on Linux and that is the main target at this time. One thing I haven't tried is to see if Cro works if installed on WSL (Windows Subsystem for Linux). Has anyone tried on WSL? Dean |
Thanks alot Dean for your reply & suggestions. I've yet to try WSL - I don't have any experience with it, but probably will try it later. My successful attempt above was on a home PC. I just tried doing the same thing on my work PC (where I have no admin rights) so I had to install Strawberry Perl as zip, which seemed to be ok, but upon reinstalling cro via zef, to my surprise I had a similar failure of inability to find/build the dll. I will repeat the home effort in case I simply copied the built DLL I did separately or not, prior to trying an install via zef - can't recall (hence want to repeat). I really want to try to get this to work.. Michael. |
I could confirm successful build of SHA1 DLL and subsequent cro module (following uninstall of rakudo and deleting all associated folders manually) on regular Windows 10. But had some false starts.. it took me 3 successive launches of zef to get it to install, which is weird - you can see those below (with errors in bold). I wonder how it's possible to get variable outcomes like that. C:\Users\Asus>zef install --/test cro C:\Users\Asus>zef install --/test cro C:\Users\Asus>zef install --/test cro 1 bin/ script [cro] installed to: |
Died with the exception:
If anyone is interested, I could overcome the 'unable to get local issuer certificate' aka HTTPS certificate validation issue here. |
Linux. We'd like it to work well everywhere, but porting is most certainly incomplete. While there likely are some bits to take care of in Cro itself, it seems the bulk of the issues to deal with are in dependencies. On Windows there doesn't tend to be a C compiler readily available. Quite a few modules ship binaries as a resource. This could be done for |
I couldn't reproduce my successful build at work, so I looked more deeply again. I believe the issue is actually the inability of makefile to handle spaces in a folder name. If you notice carefully the original posters text, you'll see some clues I noticed a similar problem with my work PC - the user folder has my firstname and surname separated by a space, just like Dean's case above. I found if I went into the .zef/store/p6-digest-sha1-native.git temp/ folder, and updated makefile to use the relative folder, I could build the dll, so I knew now the issue was not a build failure but a path issue. I tried all sorts of ways to try to escape the space, but I was unsuccessful and from online research, it's a problematic area for makefile. So as a short-term workaround, I updated the Makefile.in to the following. When reran 'zef install --/test cro' I could get a successful build in this case. My home testing was unaffected, since the user folder did not contain a space!
I guess providing a sha1.dll would be a nice convenience for those not having Strawberry Perl or mingw64 installed, but the above issue would still be a problem, as many Windows machines have their C:\Users like the case above. It would be great if the build processes could support that, or find another approach (not use the Users folder for temp building). I believe it would be preferable to advise people in order to install Cro on Windows, the user should have a C compiler like mingw64 installed. BTW is it true that the .zef & .raku folders in the user folder are temp folders, and the contents of those can be cleared out after successful installs of third-party modules? It would be interesting to learn more about how module are stored, as I tried many times to install/uninstall modules/rakudo to research this issue, not really understanding how to get back to a clean slate to try reinstalling cro from absolute scratch. Thanks for everyone's time. If this matter is confirmed, or no other suggestions I guess this matter could be closed. |
WSL2/Ubuntu $ zef install --/test cro |
@NeilShadrach Mostly likely the WSL case can be resolved with |
Ran:
sudo apt-get install build-essential
and that helped things get a bit further
$ zef install --/test cro
===> Searching for: cro
===> Searching for missing dependencies: Cro::WebSocket, Docker::File,
File::Ignore
===> Searching for missing dependencies: Cro::HTTP, Digest::SHA1::Native,
Crypt::Random
===> Searching for missing dependencies: JSON::JWT, DateTime::Parse,
Log::Timeline, if, LibraryMake
===> Searching for missing dependencies: Digest::HMAC
===> Searching for missing dependencies: Digest
===> Building: Digest::SHA1::Native:ver<0.04>
===> Building [OK] for Digest::SHA1::Native:ver<0.04>
===> Installing: if:ver<0.1.1>:auth<github:FROGGS>
===> Installing: Crypt::Random:ver<0.4.1>:auth<github:skinkade>
===> Installing: Digest:ver<0.3.4>:auth<Lucien Grondin>
===> Installing: Digest::HMAC:ver<1.0.2>:auth<github:retupmoca>
===> Installing: JSON::JWT:ver<1.0>:auth<github:retupmoca>
===> Installing: DateTime::Parse:ver<0.9.1>
===> Installing: Log::Timeline:ver<0.3>
===> Installing: Cro::HTTP:ver<0.8.4>
===> Install [FAIL] for Cro::HTTP:ver<0.8.4>: ===SORRY!=== Error while
compiling /home/neil/home#sources/3523BF185071CC5AB875D8D00C04E400CF5777AB
(Cro::HTTP2::GeneralParser)
===SORRY!=== Error while compiling
/home/neil/home#sources/E7AE8EC1C062D747D477CD5DB45B3875EE1E66CD
(Cro::HTTP::Request)===SORRY!=== Error while compiling
/home/neil/home#sources/DDDD3607B617AC6B7DCA0D086AD3F4247AC394E9 (Cro::TLS)
Cannot locate native library 'libssl.so': libssl.so: cannot open shared
object file: No such file or directory
at /home/neil/home#sources/DDDD3607B617AC6B7DCA0D086AD3F4247AC394E9
(Cro::TLS):8
at /home/neil/home#sources/E7AE8EC1C062D747D477CD5DB45B3875EE1E66CD
(Cro::HTTP::Request):7
at /home/neil/home#sources/3523BF185071CC5AB875D8D00C04E400CF5777AB
(Cro::HTTP2::GeneralParser):3
===SORRY!=== Error while compiling
/home/neil/home#sources/3523BF185071CC5AB875D8D00C04E400CF5777AB
(Cro::HTTP2::GeneralParser)
===SORRY!=== Error while compiling
/home/neil/home#sources/E7AE8EC1C062D747D477CD5DB45B3875EE1E66CD
(Cro::HTTP::Request)===SORRY!=== Error while compiling
/home/neil/home#sources/DDDD3607B617AC6B7DCA0D086AD3F4247AC394E9 (Cro::TLS)
Cannot locate native library 'libssl.so': libssl.so: cannot open shared
object file: No such file or directory
at /home/neil/home#sources/DDDD3607B617AC6B7DCA0D086AD3F4247AC394E9
(Cro::TLS):8
at /home/neil/home#sources/E7AE8EC1C062D747D477CD5DB45B3875EE1E66CD
(Cro::HTTP::Request):7
at /home/neil/home#sources/3523BF185071CC5AB875D8D00C04E400CF5777AB
(Cro::HTTP2::GeneralParser):3
Thanks!
Ar Sul, 17 Ion 2021 am 18:16 Jonathan Worthington <[email protected]>
ysgrifennodd:
… @NeilShadrach <https://github.com/NeilShadrach> Mostly likely the WSL
case can be resolved with apt install build-essentials.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIDRXOKDZX3EG6MBSCZBI3S2MSRDANCNFSM4JBD3VGA>
.
|
Brand new install of Rakudo on Windows 10. I have just run "zef install --/test cro" and receive the following error:
===> Building: Digest::SHA1::Native:ver<0.04>
gcc: error: Powell.zef\store\p6-digest-sha1-native.git\e34d468341a572a7c089d672429cf88d21e07734/resources/libraries/sha1.dll: No such file or directory
gmake: *** [Makefile:9: C:\Users\Dean] Error 1
The spawned command 'gmake' exited unsuccessfully (exit code: 2)
in method build at C:\Users\Dean Powell.zef\store\p6-digest-sha1-native.git\e34d468341a572a7c089d672429cf88d21e07734\Build.pm line 14
in block at -e line 1
===> Building [FAIL]: Digest::SHA1::Native:ver<0.04>
Aborting due to build failure: Digest::SHA1::Native:ver<0.04> (use --force-build to override)
I assume I lack the appropriate dll on my current (late model) Windows build. However, I believe Microsoft has deprecated SHA1 as insecure, and thus that dll will no longer be available on my machine.
Are there plans to move to a different hashing algorithm? Or are there suggestions for getting around this error?
Dean Powell
Edmonton, Canada
The text was updated successfully, but these errors were encountered: