kernel cipher support detection lags behind kernel crypto module name changes
Bug #994813 reported by
Tyler Hicks
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eCryptfs |
Fix Released
|
Low
|
Tyler Hicks |
Bug Description
Should cipher_list.c be updated with newer module names? There was commit to add blowfish_generic.ko for kernels >= 3.2, but for example twofish.ko hasn't existed since 2.6.36 (was renamed to twofish_
Changed in ecryptfs: | |
status: | In Progress → Fix Committed |
summary: |
- kernel cipher support detection lags behindkernel crypto api changes + kernel cipher support detection lags behind kernel crypto api changes |
summary: |
- kernel cipher support detection lags behind kernel crypto api changes + kernel cipher support detection lags behind kernel crypto module name + changes |
Changed in ecryptfs: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Rather than try to keep up with the kernel crypto api changes, I'd like to remove the unnessarily complicated kerner cipher detection code. It is over-engineered, does things that it probably shouldn't do, makes assumptions that it shouldn't, etc.
The eCryptfs kernel code behind the mount() syscall already checks to make sure that the kernel supports the cipher and keysize specified in the mount options. Lets just let that do the checking. ecryptfs-utils will just have to maintain a list of ciphers that the eCryptfs kernel code may support, prompt the user for all of those, and then let the kernel handle the error checking.