After managing to get security/truecrypt to compile I want to use my external HDD (encrypted with truecrypt on Linux) with it, so I'm issuing: truecrypt --mount --filesystem=none --protect-hidden=no --keyfiles='' --slot=1 /dev/da0 After entering the passphrase, the system partly hangs. I see a process: 1327 1 D+ 0:00.00 umount -- /tmp/.truecrypt_aux_mnt1 and an entry in dmesg: FUSE: strategy: filehandles are closed So this feels like a bug in fusefs.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Got the same problem on FreeBSD 10.1. While trying to mount truecrypt file container (/root/cc) truecrypt just hangs: # ps -xa | grep truecrypt 1159 - I 0:00.00 truecrypt --filesystem=none -k --protect-hidden=no /root/cc 1161 - Is 0:00.00 truecrypt --filesystem=none -k --protect-hidden=no /root/cc 1165 1 D 0:00.00 umount -- /tmp/.truecrypt_aux_mnt1 Can't kill any pf truecrypt processes. Message in /var/log/messages: Dec 21 13:54:19 desktop kernel: FUSE: strategy: filehandles are closed
Created attachment 174802 [details] allow truecrypt to build from ports without error well, that was more of a trick than i expected. configure being confused by native iconv was a bigger problem than i had thought, so i modified the top level makefile, which i've included, to pass the proper reference via the environment. also, i added a conditional to link x11 in WORKSRC/Main/Main.make when building for gui, which is where that iconv reference lands as well. that's handled by a properly formatted patch as specified in the porters handbook. tried building text and gui, both work fine. i'm on 11.0alpha6, fairly stock, i reinstalled my workstation from PXE yesterday. wxWidget tolerates being built with make -j10 quite nicely, this being a bugfix, i kept that to myself. i changed sudo to a build requirement instead of a run requirement in the top level makefile as well, when i initially built TC it failed at the end for not having it. these patches here enable the port to build without error. i'm currently taking a crack at fixing the issues i found with UFS and properly initially detecting free space without an existing file for a hint, but i figured i'd send this now. -jnd with regard to the specific bug reported here, i would expect that is a fuse problem, as i've been able to mount, create, access, dismount and remount containers from the gui built from the port. the gui doesn't recognize free space on the drive if you attempt to create a new volume from a nonexistent file, so i just found a core dump and selected it, all of a sudden tc saw my free space and worked fine. i'm actually working on fixing that problem presently. i'd like to remove AES as the audit revealed that and the windows PRNG as the only major concerns. i propose to replace it with camellia. vera used an implementation from cppcrypto, i could do that as well, the code is all well documented if removing aes, it makes sense to remove sha. replace with skein? reading schneier, it's also a drop in.
Created attachment 174803 [details] allow truecrypt to build from ports without error well, that was more of a trick than i expected. configure being confused by native iconv was a bigger problem than i had thought, so i modified the top level makefile, which i've included, to pass the proper reference via the environment. also, i added a conditional to link x11 in WORKSRC/Main/Main.make when building for gui, which is where that iconv reference lands as well. that's handled by a properly formatted patch as specified in the porters handbook. tried building text and gui, both work fine. i'm on 11.0alpha6, fairly stock, i reinstalled my workstation from PXE yesterday. wxWidget tolerates being built with make -j10 quite nicely, this being a bugfix, i kept that to myself. i changed sudo to a build requirement instead of a run requirement in the top level makefile as well, when i initially built TC it failed at the end for not having it. these patches here enable the port to build without error. i'm currently taking a crack at fixing the issues i found with UFS and properly initially detecting free space without an existing file for a hint, but i figured i'd send this now. -jnd with regard to the specific bug reported here, i would expect that is a fuse problem, as i've been able to mount, create, access, dismount and remount containers from the gui built from the port. the gui doesn't recognize free space on the drive if you attempt to create a new volume from a nonexistent file, so i just found a core dump and selected it, all of a sudden tc saw my free space and worked fine. i'm actually working on fixing that problem presently. i'd like to remove AES as the audit revealed that and the windows PRNG as the only major concerns. i propose to replace it with camellia. vera used an implementation from cppcrypto, i could do that as well, the code is all well documented if removing aes, it makes sense to remove sha. replace with skein? reading schneier, it's also a drop in.
i know it has been a while since i posted anything here, but give up was the last thing i did.. since then i've actually forked the code, and also moved, i have a working portfile for 11 i will put back here when i get my workstation power connected later this week. the problem was with UFS; i forget what the exact thing was, as i looked at that long ago, but it wasn't going to be resolved easily and so i chose to focus on finding a common format that would work reasonably across macos, linux and FreeBSD. although my effort primarily targets working on FreeBSD, i also have maintained support for the other two. In the process, I completely rewrote the file system detection/arbitration code used for FreeBSD to use a little magic now. th it's not simply the dumb version they had included; we try a little harder now...in fact the freebsd code for this task was little more than a stub to be finished later...anyhow my solution was to change the default filesystem to the ext3fs provided by the kernel which works wonderfully, and i've also patched OSXfuse to work with it, and made it the default there, and in the linux version. alper akcan was kind enough to accept my changes to osxfuse and pull them back in to his distribution. i've looked in to adding support for ZFS and i think it is very possible although it will take me some time and i'm rather swamped right now, i have a plan of attack, and i plan on attacking it. for now i have a version up on github, at http://github.com/adouble42/nemesis-current and a more current working copy on my internal gitweb accessible via tor at http://qpbt3kpraplo7ias.onion/?p=nemesis.git;a=summary the onion link is probably more current by far than github, it also might require some monkeying around as it's what my current effort is. i've had to change the name of the project and strengthened some things such as the KDF, although i can easily change it to read existing containers with the old KDF iterations for the fellow from several years back, should he still have this issue. linux would have been using ext3 anyway so that would work just fine. the portfile pulls a known stable revision from my git and i plan on submitting it for review shortly. it is my intention to continue to maintain the fork, at the time i answered this, had no idea i'd be going that far...should anyone see this that is or knows the right person to talk to regarding contributing a port please do reach out thanks tl;dr UFS is hopelessly broken or pointlessly at least as it is here; it's an easier effort to rewrite core_freebsd to use zfs and ext3. my forks changes in that respect should backport to the original as drop in; will attempt although i do suggest giving the fork a chance. it was a lot of work to get this back on track and honestly moving forward seems the best idea given the amount of effort involved it seems slightly crazy not to improve the rest in order to at least mitigate the effects of Moore's law. that's not to say compatibility with existing data be damned , of course... http://github.com/adouble42/nemesis-current or http://qpbt3kpraplo7ias.onion/?p=nemesis.git;a=summary onion more current portfile to follow
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
The truecrypt webpage says "WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues. This page exists only to help migrate existing data encrypted by TrueCrypt." At this point we shouldn't even have a port IMO.