insomnia: Crash on Fedora 36 after got "Error: SSL connect error" when working with https websites

Downgrading insomnia to 2022.4.2 didn’t work.

Downgrading cups to 2.4.1 did work.

sudo dnf install cups-1:2.4.1-7.fc36.x86_64 properly downgraded all 5 packages in 1 go.

EDIT: I’m just confirming that @davelima was right about cups. He did all the investigative work and is the real MVP.

Hi folks, quick update, we did a small workaround exploration to see how feasible it would be for us to provide builds for Fedora 36 in #5281.

We can’t guarantee this will get merged anytime soon. One thing that would help is for us to get an idea of the size of the community that uses Fedora, so we could prioritize a proper solution in our roadmap. Feel free to upvote/thumbs-up this issue/comment if this problem affects you directly.

UPDATE: see my comment bellow: https://github.com/Kong/insomnia/issues/5088#issuecomment-1326658425

@filfreire thanks!

I have made some tests with older versions and it all seems to have the same issue, so i’ve reviewed the last updates on my OS and looks like the problem starts happening after upgrade cups from 2.4.1 to 2.4.2 (why i cannot say).

Downgrading cups to 2.4.1 solves the problem. Hope that piece of info help you guys.

This is the list of downgraded packages:

• cups-1:2.4.1-7.fc36.x86_64
• cups-client-1:2.4.1-7.fc36.x86_64
• cups-filesystem-1:2.4.1-7.fc36.noarch
• cups-ipptool-1:2.4.1-7.fc36.x86_64
• cups-libs-1:2.4.1-7.fc36.x86_64

EDIT: There was actually some SSL related changes on cups 2.4.2, according to the changelog

Hi folks, while we don’t have a more definitive solution, in order to unblock you in the meantime, I’ve compiled an experimental build on my fork which you can download and use:

https://github.com/filfreire/insomnia/releases/tag/fedora-experiment%408ae4fe71

Contains changes up to 8ae4fe71 and was built using: https://github.com/Kong/insomnia/pull/5281

Please let me know if you have any issues with it.

Quick follow-up update: So it seems the only thing that consistently does the trick is the fix suggested by @padys in this comment. The experimental builds are not guaranteed to work.

Possible workaround

# remove existing insomnia installations
sudo dnf remove insomnia

# install latest insomnia
sudo dnf install https://github.com/Kong/insomnia/releases/download/core%402022.7.5/Insomnia.Core-2022.7.5.rpm

# download cups 2.4.1 libs and copy them to insomnia
curl -O https://kojipkgs.fedoraproject.org//packages/cups/2.4.1/7.fc36/x86_64/cups-libs-2.4.1-7.fc36.x86_64.rpm
rpm2cpio cups-libs-2.4.1-7.fc36.x86_64.rpm | cpio -idmv
sudo cp ./usr/lib64/libcups* /opt/Insomnia/.

# run insomnia
insomnia

Combinations tried:

• appimage + system-level cups 2.4.2 🔴
• rpm via built docker build + system-level cups 2.4.2 🔴
• rpm built via docker build + system-level cups 2.4.1 ✅
• rpm built via docker build + system-level cups 2.4.2 && copying cups 2.4.1 .so files into /opt/Insomnia ✅
• 2022.7.5 official .rpm && copying cups 2.4.1 .so files into /opt/Insomnia ✅
• flatpak 2022.7.3 that uses cups 2.3.3 (see comment) ✅

The hypothesis I mentioned above, of cups not being strictly defined on electron-builder/app-builder now seems less likely. It might really be something to do with Fedora updating cups to 2.4.2.

This could also explain why regardless of using rpm or AppImage - any old or recent insomnia version would stop working the moment the system-level version of cups became 2.4.2.

Other notes:

• https://bbs.archlinux.org/viewtopic.php?id=276719 - similar issue with 2.4.2 on Arch
• An OpenSSL related fix added for future cups 2.4.3 https://github.com/OpenPrinting/cups/commit/c0c403744b1bf4a9790a8fcaabcd60970cbefe06 / https://github.com/OpenPrinting/cups/issues/409

We’ll update you folks as soon as we know more, but in the meantime please let us know if the workaround on this comment based on @padys original one also worked for you.

So I compiled libcurl against my system’s installed libcurl. I wasn’t happy with cups downgrade workaround. I used the following steps

• make sure dependencies are installed

  sudo dnf install libcurl-devel make automake gcc gcc-c++
  

• git clone --depth 1 --branch core@2022.5.1 https://github.com/Kong/insomnia
  cd insomnia
  
  nvm exec npm run bootstrap
  
  ## these env are probably not needed
  export npm_config_runtime=electron
  export npm_config_target=v19.0.3
  export npm_config_build_from_source=true
  export npm_config_node_libcurl_cpp_std=c++17
  export npm_config_disturl=https://electronjs.org/headers
  ##
  
  

• Edit packages/insomnia/electron-builder.config.js and add buildDependenciesFromSource: true. This config actually makes packages app’s libcurl to be recompiled.

• nvm exec npm run app-package
  sudo dnf localinstall packages/insomnia/dist/Insomnia.Core-2022.5.1.rpm
  

Now its working fine with latest cups installed.

Latest version 2022.7.1 still not working on fedora 37

Fedora 37 has been released now. This leaves users with no (known) workaround.

Is this issue going to be important enough for you to fix? If not I will cancel my subscription.

Try this workaround (should work in Fedora 36 and 37):

1. download cups-libs for Fedora 36 from https://kojipkgs.fedoraproject.org//packages/cups/2.4.1/7.fc36/x86_64/cups-libs-2.4.1-7.fc36.x86_64.rpm (full cups-2.4.1-7.fc36 build info is here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1941256)
2. extract files from rpm: rpm2cpio cups-libs-2.4.1-7.fc36.x86_64.rpm | cpio -idmv (it makes folder usr in current location)
3. copy files libcups.so.2 and libcupsimage.so.2 from extracted rpm (from ./usr/lib64/ folder) into Insomnia instalation folder /opt/Insomnia
4. be happy with working https connections in Insomnia 😉

I hope it helps.

I use Fedora 37 and Insomnia 2022.6.0.

Still present on Fedora 36, Insomnia 2022.06.

First: Yes, I tried unchecking validate certificates. But since my OS is the recent Fedora version (36) with latest updated packages and google is a very popular website I don’t think that there is a problem with Certificate/CA. This is timeline with SSL validation disabled

* Preparing request to https://google.com/
* Current time is 2022-08-18T01:31:00.965Z
* Enable automatic URL encoding
* Using default HTTP version
* Disable SSL validation
*   Trying 142.250.66.78:443...
* Connected to google.com (142.250.66.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS alert, internal error (592):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to google.com:443 
* Closing connection 0

Second: Yes, I tried both cURL, Postman (installed after so many tries to use Insomnia without success, including downgrade to 2022.4.0) and of course browser - all work flawlessly. This is verbose log of cURL

➜  ~ curl -v --request GET \
  --url https://google.com/
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 142.250.204.142:443...
* Connected to google.com (142.250.204.142) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.google.com
*  start date: Jul 18 08:18:57 2022 GMT
*  expire date: Oct 10 08:18:56 2022 GMT
*  subjectAltName: host "google.com" matched cert's "google.com"
*  issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: google.com]
* h2h3 [user-agent: curl/7.82.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x562964dc13f0)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: google.com
> user-agent: curl/7.82.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 301 
< location: https://www.google.com/
< content-type: text/html; charset=UTF-8
< date: Thu, 18 Aug 2022 01:35:10 GMT
< expires: Sat, 17 Sep 2022 01:35:10 GMT
< cache-control: public, max-age=2592000
< server: gws
< content-length: 220
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
< 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection #0 to host google.com left intact

Hi folks, I pushed a new experimental build from latest develop branch.

To install you can do:

sudo dnf install https://github.com/filfreire/insomnia/releases/download/fedora-experiment%407417acb/Insomnia.Core-2022.7.5-fedora.rpm

And if it still doesn’t work, try the workaround mentioned here.

Also a small update. We’re still looking into a proper fix for .rpm builds. We’ve recently managed to fix snapcraft builds so you may want to switch over to those while .rpm ones are not properly working. Sharing bellow some of the more recent findings:

• Electron docs mentions that for fedora it needs the cups-devel dependency (example)

• BUT, the underlying app-builder binary that electron-builder uses - is not adding that dependency in when running rpmbuild under the hood. This is what we use to build the current Insomnia .rpm package.

The hypothesis is - the docker build alternative pr that is used to create the experimental builds seems to solve it - because we add that cups dependency in and rebuild it in fedora environment from sources.

The definitive fix might be just making sure the cups related dependency is defined app-builder/electron-builder when it’s running rpmbuild under the hood.

We’re still looking into how to fix this properly, but in the meantime I would suggest you to either hold with the experimental builds or to try and use the snapcraft version instead.

If anyone from the community has a bit more in-deep knowledge and experience with building Electron for Fedora and have other hypothesis and suggestions please reach out.

Thanks folks 🙇

Just to reinforce sudo dnf install cups-1:2.4.1-7.fc36.x86_64 did fixed the same error after F36 system upgrade. First SSL Error, then a crash.

Valeu @davelima

Just to add to your combinations list: The flatpak version (currently at 2022.7.3), which seems to be an rebuilt AppImage, is also working fine on my Fedora 37, without tinkering with cups package.

Btw, i use the experimental build from here: https://github.com/Kong/insomnia/pull/5281#issuecomment-1326658906

It’s working fine for me on fedora 37.

Hmmm, strange, I tried building cups 2.4.1 myself, which made Insomnia work again.

https://github.com/OpenPrinting/cups/archive/refs/tags/v2.4.1.zip

./configure && sudo make install

And now even reinstalling cups 2.4.2 with dnf still does not brake it again for me. I don’t know why, maybe the install script did something which is not exactly reverted by reinstalling using dnf. I also tried to build cups at different commits to figure out the offending commit, but I was not able to break it again 🤷

Also, does anybody know if the same issue happens with the AppImage?

Yes, issue also happens with the official provided AppImage. You can use the AppImage after compiling from my instructions. It’ll be in packages/insomnia/dist directory.

If your instructions worked for recompiling the app and making it work - couldn’t the Insomnia team replicate this and make an updated version?

I don’t know the metric of user distro’s, who are the audience of rpm packages? Fedora users? centos/almalinux? suse?. Instead of trying to make a single rpm work in all distro/all version, A simple fix could be just to publish separate packages for fc35/fc36. It could be easily done with modifying existing github actions a little bit. I can do a PR if that direction is acceptable to insomnia team.

Downgrading insomnia to 2022.4.2 didn’t work.

Downgrading cups to 2.4.1 did work.

sudo dnf install cups-1:2.4.1-7.fc36.x86_64 properly downgraded all 5 packages in 1 go.

EDIT: I’m just confirming that @davelima was right about cups. He did all the investigative work and is the real MVP.

Thank you so much !

But why does Insomnia uses cups ? Isn’t cups for printers ?

2022.7.2 is not working (showing the same SSL errors) even after compiling it myself, using https://github.com/Kong/insomnia/issues/5088#issuecomment-1235816006 workaround.

Edit: 2022.7.4 after re-compilation is not working either.

@CrystalSpore

Seems strange that a mostly-stock install of Fedora would run into this issue of not having a “compatible” TLS library installed

I’d guess development headers are missing, try installing openssl-devel

Thank you so much @filfreire, it is working fine with cups 2.4.2

Also facing this error… downgrading some dependency may work, but is not suitable to working process… I only can use insomnia in localhost or some environment that does not use http

Same issue here with F36 and Insomnia 2022.5.1 as well as 2021.7.1, both AppImages. I will try the workaround, but I’m not admin on this machine and our IT will not be happy about the downgrade 😅 So a permanent solution would be appreciated very much 😃

Hi folks, quick update, but after installing updates on Fedora 36, I can reproduce the exact same issue, with these error logs

[0829/144040.857270:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0829/144040.858037:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0829/144040.858396:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0829/144040.864807:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
[0829/144040.864852:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
Segmentation fault (core dumped)

and Insomnia crashing soon after the SSL error:

Solution

I tried solution mentioned above by @davelima and @bisby

And after running sudo dnf install cups-1:2.4.1-7.fc36.x86_64 it’s back working:

Thank you @davelima and @bisby winkmedal_military

looks like the problem starts happening after upgrade cups from 2.4.1 to 2.4.2 (why i cannot say).

This is the part where I also have no idea at the moment. Tagging @DMarby and @johnwchadwick, perhaps they might have a hint here.

Worked for me here. Thanks!

Just to reinforce sudo dnf install cups-1:2.4.1-7.fc36.x86_64 did fixed the same error after F36 system upgrade. First SSL Error, then a crash. Valeu @davelima

This worked for me too on Fedora 36. Thanks so much!

While this works, I wouldn’t encourage much to suggest this solution. I mean, why to install a print tool/driver/app/whatever for something related to REST APIs, and more importantly, SSL connections?

I get this when I try to run that. I’m definitely not going to install extra packages to fix something that isn’t exactly broken:

I’m really rooting for @sarim’s PR (if any) so we can get this solved soon. Basically the tool is unusable otherwise 😦

Based on your screenshot, you are downgrading cups-libs by doing this… which is clearly what the end goal is. dnf install cups-2.4.1 was assuming you had cups installed… It is kinda weird to have cups-libs installed, but not cups? It must be used as a dependency for things other than just cups. But for you, downgrading cups-libs would work:

sudo dnf install cups-libs-1:2.4.1-7.fc36.x86_64

Just to reinforce sudo dnf install cups-1:2.4.1-7.fc36.x86_64 did fixed the same error after F36 system upgrade. First SSL Error, then a crash. Valeu @davelima

This worked for me too on Fedora 36.

Thanks so much!

While this works, I wouldn’t encourage much to suggest this solution. I mean, why to install a print tool/driver/app/whatever for something related to REST APIs, and more importantly, SSL connections?

I get this when I try to run that. I’m definitely not going to install extra packages to fix something that isn’t exactly broken:

I’m really rooting for @sarim’s PR (if any) so we can get this solved soon. Basically the tool is unusable otherwise 😦

Hi folks, quick update, but after installing updates on Fedora 36, I can reproduce the exact same issue, with these error logs

[0829/144040.857270:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0829/144040.858037:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0829/144040.858396:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0829/144040.864807:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
[0829/144040.864852:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
Segmentation fault (core dumped)

and Insomnia crashing soon after the SSL error:

Solution

I tried solution mentioned above by @davelima and @bisby

And after running sudo dnf install cups-1:2.4.1-7.fc36.x86_64 it’s back working:

Thank you @davelima and @bisby 😉🎖️

looks like the problem starts happening after upgrade cups from 2.4.1 to 2.4.2 (why i cannot say).

This is the part where I also have no idea at the moment. Tagging @DMarby and @johnwchadwick, perhaps they might have a hint here.