Put some notes down

1 files changed, 46 insertions, 0 deletions

diff --git a/notes.txt b/notes.txt
new file mode 100644
index 0000000..fb6f283
--- /dev/null
+++ b/notes.txt
@@ -0,0 +1,46 @@
+This is a file of ramblings and notes for what I'm doing
+
+vxgg originally only encrypted the /home directory and its subdirectories. As of now, I believe it should
+also encrypt the /root dir as well. Running as a daemon and setting things up in the background may be
+a good idea as well
+
+vxgg was not atomic in its encryption, in that if the encryption was in progress and interrupted for whatever reason, the original 
+file would be "irrecoverably" (as in vxgg had no error checking and couldn't tell the difference between an encrypted and 
+unencrypted file other than through filename. You could manually unfuck the file yourself if you had the key, but it would be a
+long and tedious process) fucked. I can't possibly make the entire operation of reading and writing to a file atomic, but I can 
+make the action of "encrpytion" atomic; or, at least, I can make the encryption seem atomic through a cheat: hard linking. Turns out
+that you can make a file in /tmp, fill it with a whole bunch of shit, then hardlink it to somewhere else on the drive, and the 
+file's contents will persist after a reboot. The idea here is to open a file in /tmp, write the encrypted contents to it, and then
+hardlink the encrypted file to the same location as the original, and then delete the original. This way, if the process is 
+interrupted, there is no chance of file loss. The hardlink isn't atomic in terms of being uninterruptable and instant, but the
+specific order of "encrypt in tmp, hardlink, delete real file" will, at very least, minimize the chances of irrecoverable data loss.
+I'm trying to encrypt people's drives for fun, not for malicious purposes. The least I can do is make sure I don't lose their data
+
+The only issue I see with hardlinking is that it's possible that, for some reason (linux pedants), the /home and /tmp folders are
+not in the same partition/drive. The simple solution I see for now is creating a hidden, root owned, chmod u=rwx,go= folder in
+/home to store files as they are being encrypted
+
+Nevermind, another problem I see is that permisions and filetypes may be different. Not that I ever tried vxgg on a symlink, but I
+wouldn't be surprised if it worked fine (given that all vxgg does is rewrite the contents of a file), but this solution would break
+those links. If this is a problem, it'll be interesting to see how I should make exact copies of files before encrypting them
+
+I really need to figure out how to determine if a filesystem is a Large File System (LFS) so I can know whether to use the standard
+or 64 bit versions of functions
+
+Ok so supposedly stat and its variants will work with 64 bit systems using LFS fine because of some macro "_FILE_OFFSET_BITS", but
+I'm not certain if I need to figure this out or what. Also, it's a compile-time thing, and preferably I don't need to compile this
+on each system I infect, so I still need something else
+
+mkstemp might be quite a useful function for doing the encrypting thing, but having a template name might be problematic. I may just
+have to rename everything before linking. Maybe linkat() would work
+
+============== LIST OF POTENTIALLY USEFUL GNU C FUNCTIONS ==============
+    scandir()                   - Gets a list of files in a directory: https://www.gnu.org/software/libc/manual/html_node/Scanning-Directory-Content.html
+    link()                      - Hardlinks one file to another location: https://www.gnu.org/software/libc/manual/html_node/Hard-Links.html
+    canonicalize_file_name()    - Get the canonical filename of some path (removes symlinks, /'s, .'s, and ..'s): https://www.gnu.org/software/libc/manual/html_node/Symbolic-Links.html
+    realpath()                  - canonicalize_file_name(), but you can put the result directly into a user-allocated string: ^
+    remove()                    - Deletes a file or directory according to unlink() and rmdir() respectively: https://www.gnu.org/software/libc/manual/html_node/Deleting-Files.html
+    rename()                    - Renames a file or directory, atomically: https://www.gnu.org/software/libc/manual/html_node/Renaming-Files.html
+    All of the file attribute related functions: https://www.gnu.org/software/libc/manual/html_node/File-Attributes.html
+    tmpfile()                   - Creates a temp binary file as if you used fopen: https://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html
+    mkstemp()                   - Creates a temp file using a name template and opens it for you: ^