This article is now published on my website: A one-off git repo server.
UPDATE working on this here!
so… I've had this weird idea recently...
In git (and in other secure + distributed systems) you have a tree of hashes where each object is identified by it's hash and objects contain pointers to other objects. They just have the hash of other objects stored inside them.
We need better crypto primitives and modules - there are lots of standards out there that are dangerous! Things that seem like they should work, don't and this leaves security holes where they shouldn't be, or creates situations where an application must be implemented with knowledge of the internal features of crypto "primitives". example: length-extention attack on api authentication
What is right about the word primitive: simple api + clear security properties (* this isn't always the case, but it can and should be)
But, there are other great crypto "primitives" (modules) that are made from actual primitives but never the less provide a simple api and clear properties. A good example of this is nacl's crypto_box
it has eliptic curves, salsa20 and poly1305 to create a encrypted buffer that can only be decrypted by the intended key.
- hash (except hashes that have length extension attacks)
- digital signatures (bu
A short list of hurdles to get Electron working more like Node, and how I'm tackling them.
- using renderer
process.stdin
with Buffer seems difficult/impossible- alternative: send buffered stdin as a string to the renderer
- renderer
process.argv
needs to berequire('remote').process.argv
- should be patched in preload script to ensure your Node dependencies work correctly
- syntax errors in
<script src="index.js">
do not print to terminalwindow.onerror
in a preload script can be used to detect these problems- only provides file, line number and a minimal error message
- stderr gets cluttered with Chromium logs