00:29:02  * contrahaxquit (Quit: Sleeping)
01:43:10  * phatedquit (Remote host closed the connection)
02:12:56  * h0x00ajoined
03:09:59  * h0x00aquit (Ping timeout: 250 seconds)
03:13:03  * phatedjoined
03:18:06  * phatedquit (Ping timeout: 276 seconds)
03:30:32  * toddselfquit (Read error: Connection reset by peer)
03:30:42  * toddselfjoined
03:32:37  * toddselfquit (Read error: Connection reset by peer)
03:35:40  * toddselfjoined
03:40:02  * toddselfquit (Read error: Connection reset by peer)
03:40:40  * toddselfjoined
03:43:32  * toddselfquit (Read error: Connection reset by peer)
03:45:43  * toddselfjoined
03:57:19  * pfrazequit (Remote host closed the connection)
04:00:23  * pfrazejoined
04:10:52  * contrahaxjoined
04:22:20  * pfrazequit (Remote host closed the connection)
04:25:50  * contrahaxquit (Quit: Sleeping)
04:40:15  <emilbayes>If I wanted to use and then securely delete a value, eg. a private key, would storing it in a Buffer, and then writing all zeros to the buffer when done, suffice? Or would different browsers handle this differently?
04:47:13  <emilbayes>I guess yes (?) based on this: https://github.com/dchest/tweetnacl-js/issues/59
05:01:30  * phatedjoined
05:05:39  * phatedquit (Ping timeout: 244 seconds)
05:15:34  <guybrush>emilbayes, i think writing zeros to the buffer would be save (but i am not completely sure)
05:18:10  <guybrush>though i wonder what makes you think that you have to write zeros to be save, if i understand your question?
05:19:10  <guybrush>every browser will give you a zero-allocated buffer anyway when you call `new ArrayBuffer` right?
05:20:03  <guybrush>or do you mean that someone could somehow access the not-yet GC'ed arraybuffers from outside the browser?
05:23:57  * fotoveritequit (Quit: fotoverite)
05:24:29  <guybrush>also i think this issue is related: https://github.com/nodejs/node/issues/4660
05:36:12  <emilbayes>guybrush: Yeah, that's kinda what I'm thinking, or someone forgetting they passed a reference somewhere. So zeroing it out after use would erase the value (though whoever got the reference could have copied it)
05:37:00  <emilbayes>guybrush: Yep, followed that issue since it was filed. That's also something I am considering
05:37:16  <guybrush>i think zeroing out would be very safe
05:37:34  <guybrush>the issue is about the node-buffer-implementation though
05:37:50  <guybrush>when you use browserify you will use feross's user-land impl
05:38:54  <guybrush>but i guess i am not the right guy to talk about this anyway :D
05:39:20  <guybrush>zeroing out the buffer is defenitely pretty safe
05:43:51  * phatedjoined
05:48:28  * phatedquit (Ping timeout: 264 seconds)
05:48:48  * jjjjohnnyjoined
06:40:50  * hyperirc-9d25a90quit (Remote host closed the connection)
06:40:56  * hyperirc-9d25a90joined
08:38:01  * jjjjohnnyquit (Ping timeout: 244 seconds)
10:26:05  <feross>zeroing out the buffer is a good idea if you know the data is not needed anymore
10:31:30  * thealphanerdquit (Quit: farewell for now)
10:31:55  * thealphanerdjoined
11:23:18  <emilbayes>feross: thanks! Just wanted to make sure
12:02:42  * pspiquit (Ping timeout: 258 seconds)
12:13:39  * pspijoined
12:18:59  * pspiquit (Ping timeout: 244 seconds)
12:35:46  * pspijoined
13:18:01  * Tristitiajoined
13:40:50  * pfrazejoined
13:58:41  * contrahaxjoined
14:02:55  * contrahaxquit (Ping timeout: 252 seconds)
14:28:06  * pfrazequit (Remote host closed the connection)
14:41:13  * pfrazejoined
14:49:43  <substack>working more on my o5m writer today, need to get the map batch job running
15:09:00  * pspiquit (Ping timeout: 258 seconds)
15:11:33  * pspijoined
16:34:34  * toddselfquit (Quit: Lost terminal)
17:39:41  * dudejoined
17:41:19  * dudequit (Client Quit)
18:16:22  <noffle>thinking about an api design: you have a module that provides a function returning a new readable stream. the stream never exhauts itself, since it's reading from e.g. some hardware device. Readable streams don't have a notion of being closed from their public API, right? But it's desirable to let the user 'close' it to deallocate resources, etc.
18:16:36  <noffle>thoughts on this?
18:20:33  <yoshuawuyts>noffle: stream.destroy() closes the stream; also .pipe() when the source stops reading iirc
18:20:57  <yoshuawuyts>noffle: though .destroy() isn't an official streams API, despite being used everywhere (including core)
18:23:08  * fotoveritejoined
18:28:33  <noffle>yoshuawuyts: yeah I saw that destroy was a thing! but was worried about going "unofficial"
18:29:19  <noffle>yoshuawuyts: what do you mean by "when the source stops reading", specifically?
19:00:11  <yoshuawuyts>noffle: if the writestream closes, the readstream it's piping from will be closed too unless you pass .pipe(writer, { close: false }) for it to stay open
19:00:22  <yoshuawuyts>noffle: https://nodejs.org/api/stream.html#stream_readable_pipe_destination_options
19:05:44  * ralphtheninjaquit (Quit: leaving)
19:54:53  * pfrazequit (Remote host closed the connection)
20:16:32  <noffle>yoshuawuyts: thanks -- that makes sense. I'll dig into that some more
21:13:34  * phatedjoined
21:34:23  <mafintosh>noffle: use .destroy()
21:48:17  <noffle>mafintosh: but but but, not part of the official api :o
21:49:50  <mafintosh>noffle: all core streams have it, plenty of open prs to add it as well
21:50:24  <mafintosh>noffle: and the streams wg accepts it. we just havent had the time to make it an official thing yet
21:50:33  <noffle>oh neat
21:52:22  * phatedquit (Read error: Connection reset by peer)
21:52:55  * phatedjoined
21:54:56  * phatedquit (Remote host closed the connection)
22:17:57  * nofflequit (Quit: WeeChat 1.5-rc2)
22:24:48  * nofflejoined
23:05:37  * phatedjoined
23:10:04  * phatedquit (Ping timeout: 240 seconds)