|
|
|
@@ -19,3 +19,5 @@ Here is a list of the projects that I'm interested in working on. If you'd like |
|
|
|
The POSIX file interface has served us well, but one thing it lacks is integrity. Anyone that does file writing has to add their own logging/journaling logic, or do the poor man's new file/rename in order to do atomic updates. Modern file systems like ZFS and even UFS w/ softupdates, do this for themselves, but currently there is no exposed interface to allow user land programs to make use of these features. |
|
|
|
* New ZFS interface layer. |
|
|
|
ZFS has a ZPL that mappes the POSIX layer onto ZFS. It'd be nice if there was an interface that exposed the raw ZFS objects to a userland system. This would allow things like a userland program handling it's own lookup layer, and cheaper CAS backed storage. |
|
|
|
* Secure python import. |
|
|
|
Currently there isn't a way to ensure that an end user gets the same code that the author tested/wrote against. Or that the code is by the same author as the import. See things like leftpad, or handing off a module to another author that ends up pushing malware into the module. I'd like to see a cryptographically signed way to import python modules and code. This is something like Content addressed Code. The idea is to support something like `from <hash of library or author's key> import module`. This will verify the module is signed by the author, or the module exactly matches the hash of the library. This could make it easier to import code from another project. Say they properly put a useful function in it's own file, you could do: `from <hash of py file> import function`, and the function would be imported as the database would contain a mapping between the hash of the py file, and where to get it. As the hash would be strongly tied, there'd be no issues w/ injecting malicious code. |
