Update README.md
authoradouble42 <adouble4242@gmail.com>
Wed, 9 Nov 2016 07:55:44 +0000 (02:55 -0500)
committerGitHub <noreply@github.com>
Wed, 9 Nov 2016 07:55:44 +0000 (02:55 -0500)
README.md

index f01f3b1..53df754 100644 (file)
--- a/README.md
+++ b/README.md
@@ -2,8 +2,9 @@
 nemesis is a freebsd and Mac OS X (tested through 10.11) port based on TrueCrypt, i'm slowly rebranding it to comply with the original license but that is probably my least favorite task. which is not to say i didn't have some fun with it...whereever it is my right to dictate, the 2 clause BSD license shall apply.<br>
 TAKE HEED: TAKE WARNING: TAKE HEED:<br>
 <b>AES is headed for the chopping block - it doesn't belong anywhere but a robust combiner. call me paranoid, then read about bSafe, and if you're fine with keeping your data under one algorithm developed by the NSA, we are not in agreement and i don't really care for your opinion. Move to the Camellia chain, with the BLAKE-512 hash, the performance cost is negligible on modern hardware. also, expect the 256 bit hashes to be removed - and replaced, with 256 bit memory hardened versions based on (but very much NOT yescrypt) - this hash change, is imminent, as in it's my current project. AES will be removed when i replace it with another cipher, selected for use in a new combiner to replace one of the combinations involving AES. that could be a while as i haven't given it all the thought yet. but do take note, if you use the 256 bit hashes, change that up. when i break everything, i'll put a link to the last commit with support up for stragglers. if you are using Whirlpool or the BLAKE-512 hash you are good, they are not leaving. this project isn't about beating a dead horse for eternity. i've made clear my feelings on AES from the start. you don't like it, fork it yourself. BSD 2 clause says, you can take my marbles and go home any time you want.<br></b>
-as of 11/8 the OS X build is significantly less headachey. i don't rely on stuff from ports, or homebrew -- the version of wxWidgets they use, is linked against libc++, it will not work. instead, make sure you have a MacOSX 10.7 SDK installed (which you can get at https://github.com/phracker/MacOSX-SDKs/tree/master/MacOSX10.7.sdk), go to https://www.wxwidgets.org/downloads/, download the development version - 3.1.0 - sources. NOT 3.0.2. don't waste your time trying to build it when 3.1.0 works out of the box. so extract, build, install 3.1.0. install OsxFuse 3.5.3, from the website, not ports, not brew, make sure to enable the compatibility layer during installation.<br>
-then, to make your final osx build: go to nemesis source directory; cp Makefiles/Makefile.osx over Makefile in nemesis-current/Makefile; execute make. you should now have a proper build of nemesis, linked against current Fuse and wxWidgets dylibs, without going through a bunch of package managers and headaches and annoyance.<br>
+as of 11/8 the OS X build is significantly less headachey. wxWidgets-3.1.0 is included in the source tree, similar to the original configuration. by default the project builds as a statically linked version again. undefine WX_STATIC in the Makefile to use a dynamic system wide install, 3.0.2 should work fine if you already have it. install OsxFuse 3.5.3, from the website, not ports, not brew, make sure to enable the compatibility layer during installation.<br>
+then, to make your final osx build: go to nemesis source directory; "make wxbuild; make" and you will have an application  sitting in Main/, linked against current Fuse and wxWidgets libs, without going through a bunch of package managers and headaches and annoyance.<br>
+it goes without saying i take back what i said about binary releases and i'll be providing one for OSX 10.7+ shortly.<br>
 because hot coffee, obligatory warning not to use this with windows secure boot. as it is right now it may allow some impossible permutations of hash and encryption algorithm if it builds at all and i have no means of testing so don't trash your disk and blame me. my goal isn't a windows boot application.<br>
 on all platforms, there are some wx display format errors that i haven't got in to tediously fixing yet, but can be suppressed beyond the initial warning at startup. they're nothing to worry about, it's just a windows size parameter in most cases that's not adding up and wx falls back to a reasonable default drawing the windows. when i get the time, i'll make it right, but for now, it's not breaking anything functional or IDLH so that's the workaround i'm going with.<br><br>
 as of now support for SHA-3 finalist BLAKE 512 is included, at 800,000 iterations.<br>
@@ -15,15 +16,10 @@ UFS has been deprecated from this build, and replaced with ext3. you'd think tha
 once i got things working with ext3 and fat, i was able to get hidden volumes to work again. the problem was related to both the broken UFS support and some not smart behavior on behalf of mount. now, we look for an ext3 volume first, and failing that, we then look for a FAT volume, which could be the outer volume. end result, you get large file support, and hidden volumes back. not bad.<br>
 ![normal-innervol2](https://cloud.githubusercontent.com/assets/22229007/18756831/5e0f18f2-80bf-11e6-86ae-99b8597a2b77.png)<br>
 ![outer-mounted2](https://cloud.githubusercontent.com/assets/22229007/18756885/9328a940-80bf-11e6-9fb0-b482d9e11c62.png)<br>
-this version has also been updated to use a shared library version of wxWidgets 3.0.2+ as opposed to the 2.8 packaged with the original TC. the wxgtk-3.0.2 in the ports tree doesn't seem to fully install itself, you will need to  make sure this can find wx-config 
-or wx-config-3.0 to build. i'm probably not going to make that change back to static any time soon because it would drive me insane to rebuild wxWidgets every time i change something here, and i just don't love you all that much.<br>
-as of 11/8 it should build against wxWidgets 3.1.0, which is, at least, so far, on OS X which is where i've yet tested, a much easier build, as in, untar it, run configure, make, make install, and it works, no errors. in the interest of usability, this has tempted me to go back to distributing a static version here, but on the other hand, since it's such an easy build, exactly how lazy are you?!?!!<br>
 ultimately i'm planning to rewrite as much of this as possible and address as much of the audit as possible.<br>
 i have a lot of time on my hands.<br>
-i'd like to add Skein and ditch most of the hashes, try to protect the key in memory, perhaps. instead of taking a CRC of the keyfile/password in cases where there is a key, i'd prefer to use a hash instead of that CRC. that sort of change would break backwards compatibility with the original, but i guess adding read support that allowed for the old way of mounting old volumes would be doable, with perhaps a migration wizard. <br>
-last thing - the main goal here was to get this to work on freebsd so i'm not going out of my way to maintain anything that gets in the way of that end.<br>
 i'd be quite ecstatic to eventually come up with a solid near complete rewrite to give back to the community as a port.<br>
-i get to learn a lot of things and my freebsd friends get an updated homage to one of my most favorite crypto applications ever
+i get to learn a lot of things and my freebsd friends get an updated homage to one of my most favorite crypto applications ever<br>
 this is already fun for me.<br>
 don't ruin it.
 <br>
This page took 0.025824 seconds and 4 git commands to generate. Download a nemesis OSX (sierra+high sierra, tested/working) binary, with fuse-ext3 via e2fsprogs, at this link. application and installer are signed by screwjack, llc. must install fuse with macFUSE layer first.