-
Notifications
You must be signed in to change notification settings - Fork 278
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
segmentation fault on Blowfish since ubuntu jammy #651
Comments
Just want to add that I'm seeing the same behavior under Pop_OS! 22.04LTS (which is derived from Ubuntu). As with the other user, I'm also getting it with an old encfs filesystem, which I confirmed was using blowfish. Slight difference of behavior with the old filesystem compared to the example in the report, it does let you enter the password before crashing. Running verbose shows: VERBOSE Root directory: /home/xxx/files/ [main.cpp:686] (with some paths obfuscated above). Version is 1.9.5, again as above. |
After spending time in a debugger and digging through the OpenSSL docs, I figured out what was going on. The short form is that the Blowfish algorith is no longer a default OpenSSL algorithm, and has been moved to a 'legacy' provider; you can get things working again by enabling the legacy provider in your OpenSSL configuration, an example of this can be seen in section 6.2 of https://wiki.openssl.org/index.php/OpenSSL_3.0. On my machine, this involved editing /etc/ssl/openssl.cnf to include (modifies the existing [provider_sect] and [default_sect] sections):
Doing this enabled me to access my encrypted files again. Hurrah! Some additional details: the SIGSEGV also occurs in the encfs unit test suite and 'checkops' test program, which helped a lot when debugging. It became clear that the crash happened on the call to openssl's EVP_CIPHER_CTX_set_key_length; building a debug version of openssl confirmed that it still happened in the current version, at the point where the provider is checked for the cipher. Digging in the docs to understand providers eventually showed me that Blowfish was not supplied by the default provider, but by the legacy provider, which needs explicit loading; and thankfully for a workaround, that can be done via config file. Presumably as a user I need to look at moving my encfs directory to AES, assuming Blowfish is deprecated for a good reason. From a coding perspective, presumably encfs should deprecate Blowfish; the openssl 'legacy' provider can be loaded through code as well as config, so I would assume that should be explicitly done in encfs, along with a warning to give some time for people to migrate away from it; and eventually removed completely from encfs. For whatever that's worth, of course! |
I can confirm that the workaround from @jade-lynx works and I have used it to migrate to gocryptfs because this project is dead. |
This downstream Debian bug seems about the same issue. And this crash seems also similar to one observed in freerdp. |
If I run jammy in docker and create an encfs filesystem with blowfish I get a segmentation fault (on my real machine the same segmentation fault prevents me from mounting a filesystem created in an earlier version). I run
run --rm -it ubuntu:jammy bash
and in the docker shell I runapt update && apt install -y encfs && encfs ~/.crypt ~/crypt
. Then I answery
to directory creation,x
for expert mode,2
for blowfish and all default except for filename encoding which is1
. The system fails before asking for a password. Doing the same thing on impish works like a charm. Both say they use encfs 1.9.5.The full output is:
The text was updated successfully, but these errors were encountered: