Not FIPS compliant; breaks npm when FIPS-compliance compiled about fs-write-stream-atomic HOT 7 CLOSED

Since we're not using MD5 for anything other than a fast and convenient way to get some entropy into a filename to avoid collisions, I don't think we'd have any objection to landing a patch that switches to another hashing algorithm (pure-JS murmur would probably be a smart choice). If you wanted to put a patch together, it would probably get landed and released without too much delay. Thanks for bringing this to our attention!

from fs-write-stream-atomic.

@ayohrling This issue affects me as well.

@othiym23 Any reason why you prefer to introduce a dependency on a pure JS implementation of murmur? Hashes don't introduce entropy, that's given by the invocations counter and the filename as input.

Instead, we cam simply append crypto.randomBytes(16).toString('hex') to each filename. (If you want the same 128 bit length as MD5.)

Are you okay with that? If so, I'll do the pull request.

from fs-write-stream-atomic.

This code is hot enough (at least in npm) that I'd prefer to have an algorithm designed for speed involved. The problem with crypto.randomBytes(), I am learning, is that it can cause problems for users in some environments, depending on the size of their entropy pool and the version of Node they're using. You're right that it's not so much entropy we want there as an absence of collisions / even distribution of values, and murmur is both fast and fairly uniform in the distribution of its output. I'd strongly prefer that for this purpose.

from fs-write-stream-atomic.

@othiym23

That makes sense. I've done a pull request here #6

I hope it's okay, I'm still new to JS! :)

Edit:
That took a few tries, but I got it working with an incremental version so it should be pretty fast. As a bonus, I fixed travis-ci too.

from fs-write-stream-atomic.

I didn't have time to get to this this week, but I'll try to land and merge it early next week. I'll leave this tab open until it's done. Thanks for putting this together and for hanging in there with me!

from fs-write-stream-atomic.

Thanks to merging PR #6, this is now addressed. Thanks for your patience and for putting together the fix, @stefanmb!

from fs-write-stream-atomic.

(I like the murmur, but if we did want random bytes, crypto.pseudoRandomBytes provides a nice alternative to crypto.randomBytes for those times when you don't want to block and/or eat your server's entropy and you don't actually need those kinds of guarantees of non-repeatability.)

from fs-write-stream-atomic.