Spksrc: Jackett indexers fail to run after latest Mono and Jackett updates

Created on 10 Apr 2020 · 20Comments · Source: SynoCommunity/spksrc

Setup

_Package Name:_ Mono / Jackett
_Package Version:_ 5.20 / 0.14

_NAS Model:_ DS218
_NAS Architecture:_ rtd1296 (armv8)
_DSM version:_ DSM 6.2.2

Expected behavior

Indexers from Jackett should work.

Actual behavior

An error occured while testing this indexer
Exception (eztv): Ssl error:0f000078:elliptic curve routines:OPENSSL_internal:POINT_IS_NOT_ON_CURVE at /spksrc/spk/mono/work-aarch64-6.1/mono-5.20.1.34/external/boringssl/crypto/ec/ec.c:835: An error occurred while sending the request

Steps to reproduce

Update Mono and Jackett to latest version from Package Center.

More Details

Saw in Sonarr that there's a new version available for Mono and it was saying that my version (I'm gonna say 5.18, I think this one was the previous one) is no longer supported. Updated Mono to 5.20 then Jackett to 0.14, both from Package Center. After the update Jackett refuses to work with any of my 3 indexers (2 public, 1 private). Sonarr v3 is still working.

I removed Mono, Jackett and Sonar and reinstalled the previous packages I could find here https://synocommunity.com/packages for Mono and Jackett. Still not working. Tried a mix of Mono 5.20 and Jackett 0.11, still does not work. Tried latest Jacket with previous Mono, it makes me update to the latest Mono as well.
Right now I don't know what to try and I'm left with nothing working :)
Any ideas?

Package log

Same error reported in Jackett log as well.

bug

Source

mridude23

Most helpful comment

Can you try to delete the following files after the installation of mono on your NAS?

/var/packages/mono/target/bin/mono-boehm
/var/packages/mono/target/lib/libmonoboehm-2.0.so
/var/packages/mono/target/lib/libmonoboehm-2.0.so.1
/var/packages/mono/target/lib/libmonoboehm-2.0.so.1.0.0

This does not seem to change anything. I tried this both before and after installing the 6.8.0.105 special build.

Try adding MONO_TLS_PROVIDER=legacy to your environment variables, when you are having > trouble with BTLS.

I have no idea whether the legacy TLS provider is still supported, but give it a try.

This also made no difference for me. I guess the legacy provider is no longer supported.

To save having to restart services to test something out, I’m testing with the following:

wget https://github.com/mono/mono/raw/master/mcs/class/Mono.Security/Test/tools/mget/mget.cs
csc mget.cs
mono mget.exe https://example.com/

Until we have a solution for late versions of Mono, I downgraded to 5.8.0.108-11 [6.1 rtd1296] without having to uninstall a bunch of other packages with the following:

wget https://packages.synocommunity.com/mono/11/mono.v11.f15047[rtd1296].spk
rm -rf /volume1/\@appstore/mono /var/packages/mono
synopkg install mono.v11.f15047\[rtd1296\].spk

Note: It seems like editing version in /var/packages/mono/INFO (e.g. prefix with 0.) is also sufficient to trick synopkg into downgrading without having to blow away all the files.

jasoncodes on 12 Apr 2020

❤4 👍1

All 20 comments

@hgy59 Is there a specific OpenSSL issue with aarch64?

ymartin59 on 11 Apr 2020

@ymartin59 mono uses boringSSL (aka btls) as discussed in #3666. It's a known bug as of Elliptic Curve crypto in BTLS broken on ARM64 in Debian 8 .
This mono issue is closed without a solution as for Debian > 8 there is no such error.

The reason of the bug is given as of the buggy GCC 4 support for ARM64.

Suggestions:

try a build with the latest toolchain (DSM 6.2.2, still GCC 4.9.4)
try the latest version of Mono (currently 6.8.0.105)
try to create a newer version of gcc for aarch64 and use it for cross compilation
try to replace boringSSL by OpenSSL as proposed in mono issue 8888
as of using mono tls providers an application can change the TLS provider (where available) - but this needs modification of the application code.

The first two suggestions are relativly easy to test, but the others need huge effort.
I already created a build of Mono 6.8.0 but have not added the latest toolchain yet.

hgy59 on 11 Apr 2020

@mridude23 as of this older SO item can you please try this solution?

You can try to change the mono TLS provider.

The default TLS provider in newer mono versions is BTLS. But you can change it to the legacy TLS > provider:

Try adding MONO_TLS_PROVIDER=legacy to your environment variables, when you are having > trouble with BTLS.

I have no idea whether the legacy TLS provider is still supported, but give it a try.

hgy59 on 11 Apr 2020

@hgy59 I am building mono and jackett with 6.2 toolchain to give it a try.

ymartin59 on 11 Apr 2020

There is some kind of mistake at https://sourceforge.net/projects/dsgpl/files/DSM%206.2%20Tool%20Chains/Intel%20x86%20Linux%204.4.59%20%28Rtd1296%29/
Wonder why "Intel x86" in folder for an ARMv8 architecture...
I doubt that toolchain may fix this...

ymartin59 on 11 Apr 2020

@hgy59 Is it possible that an OpenSSL update contains fixes for ARM64?

ymartin59 on 11 Apr 2020

I wonder why Jackett would suffer this issue alone. Sonarr should also fail.

ymartin59 on 11 Apr 2020

I saw this _intel_ naming too, but it's the folder name only. TC 6.2.2 has corrected folder name.
My mono_rtd1296-6.2.2_6.8.0.105-14.spk is just ready for testing.
The only binary difference to mono_aarch64-6.1_6.8.0.105-14.spk are the files

bin/mono-sgen
bin/monodis
lib/libmono-btls-shared.so
lib/libmono-native.so.0.0.0

So there is a little chance that the behaviour is different.

hgy59 on 11 Apr 2020

@mridude23 just uploaded my special build here:
Update Mono to 6.8.0.105

As usual: _pre-release without any warranty._

hgy59 on 11 Apr 2020

I wonder why Jackett would suffer this issue alone. Sonarr should also fail.

The mono issue says:

Others have this issue.
Jackett/Jackett#2173
Radarr/Radarr#2350
MichaIng/DietPi#1711

hgy59 on 11 Apr 2020

@hgy59 Is it possible that an OpenSSL update contains fixes for ARM64?

Mono uses BoringSSL, not OpenSSL.
The current mono repo links to this BoringSSL

They have a fix for FreeBSD/aarch64 in this commit https://github.com/mono/boringssl/commit/c5b67767b1f9a0da50cfce60026577797c66f7d9 just 22 days ago.

And some older clang fixes in January 2019 (but tested with gcc 7.x and 8.x only)

hgy59 on 11 Apr 2020

@hgy59 I am interested to know why there is "openssl" word in error message then routines:OPENSSL_internal:POINT_IS_NOT_ON_CURVE?

ymartin59 on 11 Apr 2020

OK it was "boring" for Google to improve OpenSSL so they forked and do not recommend to depend on it but now others are bored too with issues spread in Chromium and Mono...
Is there a way to build Mono with OpenSSL? Is that this mentioned "legacy" switch?

ymartin59 on 11 Apr 2020

@mridude23 just uploaded my special build here:
Update Mono to 6.8.0.105

As usual: _pre-release without any warranty._

Installed the package along Jackett 0.14, error still persists.

An error occured while testing this indexer
Exception (eztv): Ssl error:0f000078:elliptic curve routines:OPENSSL_internal:POINT_IS_NOT_ON_CURVE at /spksrc/spk/mono/work-rtd1296-6.2.2/mono-6.8.0.105/external/boringssl/crypto/ec/ec.c:835: The SSL connection could not be established, see inner exception.

mridude23 on 11 Apr 2020

@mridude23 just found that libmonoboehm is in the spk package but it should not be there, as it is for x86_64 arch.
Can you try to delete the following files after the installation of mono on your NAS?

/var/packages/mono/target/bin/mono-boehm
/var/packages/mono/target/lib/libmonoboehm-2.0.so
/var/packages/mono/target/lib/libmonoboehm-2.0.so.1
/var/packages/mono/target/lib/libmonoboehm-2.0.so.1.0.0

hgy59 on 11 Apr 2020

So, now the packages available in Package Center are at least one version behind.

Installed

Mono 5.8 with Jackett 0.11: public indexer works, private fails.
Mono 5.8 with Jackett 0.14: public indexer works, private works. Added Sonarr v3 as well, restored a backup and everything runs as expected now. The Mono seems to be causing all the problems.

LE: Did not see your comment and I was already working on the things I've stated. I'll try tomorrow most likely. If I manage before that I'll let you know.

mridude23 on 11 Apr 2020

Can you try to delete the following files after the installation of mono on your NAS?

/var/packages/mono/target/bin/mono-boehm
/var/packages/mono/target/lib/libmonoboehm-2.0.so
/var/packages/mono/target/lib/libmonoboehm-2.0.so.1
/var/packages/mono/target/lib/libmonoboehm-2.0.so.1.0.0

This does not seem to change anything. I tried this both before and after installing the 6.8.0.105 special build.

Try adding MONO_TLS_PROVIDER=legacy to your environment variables, when you are having > trouble with BTLS.

I have no idea whether the legacy TLS provider is still supported, but give it a try.

This also made no difference for me. I guess the legacy provider is no longer supported.

To save having to restart services to test something out, I’m testing with the following:

wget https://github.com/mono/mono/raw/master/mcs/class/Mono.Security/Test/tools/mget/mget.cs
csc mget.cs
mono mget.exe https://example.com/

Until we have a solution for late versions of Mono, I downgraded to 5.8.0.108-11 [6.1 rtd1296] without having to uninstall a bunch of other packages with the following:

wget https://packages.synocommunity.com/mono/11/mono.v11.f15047[rtd1296].spk
rm -rf /volume1/\@appstore/mono /var/packages/mono
synopkg install mono.v11.f15047\[rtd1296\].spk

Note: It seems like editing version in /var/packages/mono/INFO (e.g. prefix with 0.) is also sufficient to trick synopkg into downgrading without having to blow away all the files.

jasoncodes on 12 Apr 2020

❤4 👍1

@jasoncodes Thanks for these valuable work-arounds to downgrade packages... we should document them as FAQ, because it happens we get troubles when publishing critical package like Mono or Python...

ymartin59 on 12 Apr 2020