possible Windows Update "1903" Iceberg problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

possible Windows Update "1903" Iceberg problem

George Ganea
Hi all,

I just tested the dlls and it looks like it’s working. I say "looks like” only because my internet connection is a bit dodgy as I’m on a train. 
But it did start downloading and loading the github repos, so the fix works from my point of view.

Cheers,
George

Thank you both! We will test and come back with feedback. Cheers, Doru > On Sep 5, 2019, at 2:47 PM, Guillermo Polito <guillermopolito at gmail.com> wrote: > > Hi all, > > First, please, we would love if you can test what Pablo proposed and give us some feedback. > It will be super helpful to evaluate if it is worth to generate a new vm release!!! > > Also, besides what Pablo said in the previous email, I wanted to share some more precisions. > > === Precisions on the problem === > > First, just to clarify, we isolated the issue happening only on Windows10 #1903 on Pharo64 bits. > Pharo32 bits does work well on that update number does work well. > > The origin of the problem seems to be a bad integration between libssh2 1.7.0 and the windows CNG crypto layer, which seemingly changed in this update. > > === The path to the solution === > > The solution was theoretically super straight forward (upgrade to openssh 1.9.0 + openssl for crypto instead of windows CNG). > > It was however super time consuming. > - installing the windows update #1903 to test, reproduce and understand the issue took for us a couple of hours, reconfiguring the virtual machines to enlarge disks to download it, then install it... > - compiling openssl took literally the entire afternoon yesterday in Pablo’s machine. > - then we found several bugs in cmake openssl integration when compiling libssh2 on Cigwin + mingw, because life cannot be easy ^^ > > And fortunately, we found no incompatibilities between the different versions of these libraries (and libgit2 too!) so it could have been more time consuming :P. > > === Alternative solutions and workarounds === > > Alternatively for testing the libraries that Pablo sent in the previous email, there are some other workarounds that people could try in the meantime: > > 1) Use Pharo32 bits, which as I said above, does not have the problem. > > 2) Use Iceberg in HTTPS (and specifically set the Iceberg-Metacello integration to HTTP by default). > > <PastedGraphic-3.png> > > We are also evaluating setting HTTPS by default in Iceberg as it is simpler to setup. > Github, Gitkraken do use HTTPS as a sensible default too. > > Cheers

Reply | Threaded
Open this post in threaded view
|

Re: possible Windows Update "1903" Iceberg problem

Tudor Girba-2
Hi,

I also confirm that it works both on a Windows 10 with the 1903 and without that update.

Thanks!

Cheers,
Doru

--

"Every thing has its own flow"

On 5 Sep 2019, at 19:03, George Ganea <[hidden email]> wrote:

Hi all,

I just tested the dlls and it looks like it’s working. I say "looks like” only because my internet connection is a bit dodgy as I’m on a train. 
But it did start downloading and loading the github repos, so the fix works from my point of view.

Cheers,
George

Thank you both! We will test and come back with feedback. Cheers, Doru > On Sep 5, 2019, at 2:47 PM, Guillermo Polito <guillermopolito at gmail.com> wrote: > > Hi all, > > First, please, we would love if you can test what Pablo proposed and give us some feedback. > It will be super helpful to evaluate if it is worth to generate a new vm release!!! > > Also, besides what Pablo said in the previous email, I wanted to share some more precisions. > > === Precisions on the problem === > > First, just to clarify, we isolated the issue happening only on Windows10 #1903 on Pharo64 bits. > Pharo32 bits does work well on that update number does work well. > > The origin of the problem seems to be a bad integration between libssh2 1.7.0 and the windows CNG crypto layer, which seemingly changed in this update. > > === The path to the solution === > > The solution was theoretically super straight forward (upgrade to openssh 1.9.0 + openssl for crypto instead of windows CNG). > > It was however super time consuming. > - installing the windows update #1903 to test, reproduce and understand the issue took for us a couple of hours, reconfiguring the virtual machines to enlarge disks to download it, then install it... > - compiling openssl took literally the entire afternoon yesterday in Pablo’s machine. > - then we found several bugs in cmake openssl integration when compiling libssh2 on Cigwin + mingw, because life cannot be easy ^^ > > And fortunately, we found no incompatibilities between the different versions of these libraries (and libgit2 too!) so it could have been more time consuming :P. > > === Alternative solutions and workarounds === > > Alternatively for testing the libraries that Pablo sent in the previous email, there are some other workarounds that people could try in the meantime: > > 1) Use Pharo32 bits, which as I said above, does not have the problem. > > 2) Use Iceberg in HTTPS (and specifically set the Iceberg-Metacello integration to HTTP by default). > > <PastedGraphic-3.png> > > We are also evaluating setting HTTPS by default in Iceberg as it is simpler to setup. > Github, Gitkraken do use HTTPS as a sensible default too. > > Cheers