Orsiris de Jong

You should definitly give a bit more info. What version did you use (it's in the log parts you truncated) ? Can you post an anonymized version of your config...

Thanks for the additional info. Do I get it right that you say that basically opening a linux repo on a windows computer produces said error ?

Well, that will be a tough one. I cannot reproduce that error so far, since I can open all my linux repos with npbackup windows GUI, and browse files without...

Perhaps could you run a special debug build I could create for this issue in order to gain a bit more insight ?

@perfectra1n Any idea what I did wrong here ? Dosubot wants to make me use your prior implementation of trilium-chat which AFAIK has been replaced but current integration.

@mklapproth Thanks, but running OLLAMA_NEW_ENGINE=true and using mistral:7b-instruct produces the same errors for me @perfectra1n No problem, I'll be patient. Sorry I am not able to help coding in TS/node...

I guess I found the offending line, in https://github.com/nextcloud/desktop/blob/e83c2c86e699b39d8c93f721da1824f6117020c9/src/libsync/clientsideencryption.cpp#L1380 where specifically SHA-1 is used. I'm not a C++ guy, but I've seen that `evp_sha1()` and `evp_sha256()` functions both exist in...

@mgallien Thanks for your kind reply. I've actually had a look at the other E2EE branches of the desktop client, still using SHA-1, but then again there might be branches...

@mgallien I just saw your work for better e2ee init in 3.10-rc3. Any chance we get (at least) SHA-256 for the CSR ? That could be a one liner IMO.

Quite surprised that this bug has been up for more than a half year (orignal bug first reported in april https://github.com/nextcloud/end_to_end_encryption/issues/424). Do none of the nextcloud customers run RHEL 9...