Blah.

graphs/graphs.ms

@@ -883,7 +883,7 @@ This is not acceptable for databases with large partitions and tags: memory will
 Right now, security isn't managed in DODB, at all.
 Sure, DODB isn't vulnerable to SQL injections, but an internet-facing application may encounter a few other problems including, but not limited to, code injection, buffer overflows, etc.
 Of course, DODB isn't a mechanism to protect applications from any possible attack, so most of the vulnerabilities cannot be countered by the library.
-However, a few security mechanisms exist to prevent data leak or data modification from an outsider, and the DODB library should implement some of them in the future.
+However, a few security mechanisms exist to prevent data leak or data modification from an outsider and the DODB library may implement some of them in the future.
 
 .B "Preventing data leak" .
 Since DODB is a library, any attack on the application using it can lead to a data leak.
@@ -891,15 +891,31 @@ For the moment, any part of the application can access data stored in memory.
 Operating systems provide system calls to protect parts of the allocated memory.
 For instance,
 .FUNCTION_CALL mlock
-prevents a region of memory from being put in the swap, which may lead to a data leak.
+prevents a region of memory from being put in the swap because it could lead to a data leak.
-Also,
+The
+.FUNCTION_CALL madvise
+syscall can prevent parts of the application's memory to be put in a code-dump\*[*], which is a debug file created when an application crashes containing (part of) the process's memory when it crashed.
+.FOOTNOTE1
+.FUNCTION_CALL madvice
+has the interesting option
+.I MADV_DONTDUMP
+to prevent a data leak through a core-dump, but it is linux-specific.
+.FOOTNOTE2
+
+In a running process,
 .FUNCTION_CALL mprotect
 prevents the application itself to access part of its own memory;
-the idea is to read (or write) memory only once you ask for it via a syscall, so you cannot access it from anywhere by mistake (or after an attack).
+the idea is to read (or write) memory only once you ask for it via a syscall.
-.TBD
+Thus, you cannot access data from anywhere (by mistake or after an attack).
 
-.B "Discussion on security, not related to DODB" .
+These mechanisms could be used internally by DODB to prevent a data leak since memory is handled by the library.
+However, the Crystal language doesn't provide a way to manage memory manually and this may be a problem for mlock and mprotect.
+Depending on the plateform (the operating system), these syscalls may require the memory to be aligned with the memory pages.
+Thus, the implementation won't be easy.
+
+.B "Side-note. Discussion on security" .
 No authorization mechanism prevents the application to access un-authorized data, including, but not limited to, any file on the file-system.
+Since this implementation of DODB is related to the Crystal language (which isn't fully ported to the OpenBSD plateform at-the-moment), this is a problem.
 .
 .
 .SECTION Conclusion

src/dodb.cr

@@ -109,7 +109,6 @@ abstract class DODB::Storage(V)
 		hash
 	end
 
-	##
 	# name is the name that will be used on the file system.
 	def new_index(name : String, &block : Proc(V, String) | Proc(V, String | DODB::NoIndex))
 		CachedIndex(V).new(self, @directory_name, name, block).tap do |indexer|
@@ -135,7 +134,6 @@ abstract class DODB::Storage(V)
 		index.not_nil!.as(DODB::Index).get key
 	end
 
-	##
 	# name is the name that will be used on the file system.
 	def new_partition(name : String, &block : Proc(V, String) | Proc(V, String | DODB::NoIndex))
 		CachedPartition(V).new(self, @directory_name, name, block).tap do |table|