mde/utilities

A classic collection of JavaScript utilities

utilities

A classic collection of JavaScript utilities

Deprecated

This package is deprecated. There is an unresolved vulnerability, so don't use this package.

utilities's Issues

array.humanize modifies the passed-in array

Relative time at "one week" says two different times

The times are just seconds apart but as you see some say "1 weeks" and some "one week"

Inflections lib needs custom singular/plural/uncountable

Make logging more flexible

<mde> I think they're just asking about custom logging.
<larzconwell> Yeah maybe. 
<mde> Which we don't support yet. I was going to attack the logging, until we bumped the auth stuff up.
<mde> That logging is in pretty terrible shape.
<larzconwell> Yeah it is, I'm going go to check out this thing for techwraith, and then after that I'll look at the logging stuff.
<mde> The code for it lives in three different places.
<larzconwell> Yeah let me know those, I'm gonna make an issue
<mde> What I really want is to use the one in utilities, and set it up so you can pass in a custom logger.
<larzconwell> Yeah that's what I was thinking as well
<mde> So, there's two types of logging -- the stdout and stderr.
<mde> And then the access log.
<mde> Right now we've hacked "access" to be treated like a log level.
<mde> But that's fucked up.
<larzconwell> So what should we do?
<mde> So, we need a base Logger class.
<mde> And there will be two subclasses: the one for stdout/stderr, and the one for access.
<larzconwell> Makes sense
<mde> The stdout/stderr one to support the different levels.
<mde> And the access one just to write to the access log.
<mde> But the access one will also support custom log-format.
<larzconwell> Okay that's nice]
<larzconwell> How will the log formatting be configured?
<mde> http://httpd.apache.org/docs/2.2/mod/mod_log_config.html
<mde> It will be a function much like the strftime thing in the date utility.
<larzconwell> Okay awesome, didn't know about that!
<mde> You can take a look at that, and just do the same basic thing.
<mde> So people will set a logFormat property in the config, and it will default to the normal Apache extended.
<larzconwell> Yeah that's what I'm gonna do
<mde> You can see in the current logging how it maps the different levels to either stdout or stderr
<mde> And there's this option of also printing to the console at the same time as logging.
<mde> It's a lot of work -- it'll keep you busy for a while. :D
<larzconwell> Do we wan't access to print to console or std*
<larzconwell> brb
<mde> Okay, so by default, all three logs should also print to the console.
<larzconwell> Wait keep going
<larzconwell> haha
<mde> And it's confusing, because Node's actual process.stdout is the same as console.log. :D
<larzconwell> That's what happens currently?
<mde> Yes.
<mde> But in our logging universe, the stdout.log is just a logfile we stream to.

Will format properly later, a bit busy at the moment

Trying to get in touch regarding a security issue

Hey there!

I'd like to report a security issue but cannot find contact instructions on your repository.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

uri.paramify() should work recursively

When paramifying nested objects I get an [object Object].

uri.paramify() should either work recursively by default or provide a recursive flag.

Test case:

{
  name: {
    foo: 'bar', list: [2, 3, 4], obj: {a: 2, b: {c: 2}}
  }
}

should become

name[foo]=bar&name[list][0]=2&name[list][1]=3&name[list][2]=4&name[obj][a]=2&name[obj][b][c]=2

watch needs some fallback logic

Hey @mde I brought this up in IRC yesterday and thought I would dig into it a little more to see if there was something I could fix or file a bug report with node itself. The problem is here: https://github.com/mde/utilities/blob/master/lib/file.js#L199-L203

p is set to null on SmartOS. I read the documentation again and somehow overlooked this important paragraph:

Filename Argument

Providing filename argument in the callback is not supported on every platform (currently it's only supported on Linux and Windows). Even on supported platforms filename is not always guaranteed to be provided. Therefore, don't assume that filename argument is always provided in the callback, and have some fallback logic if it is null.

So is there anything that could be done here when p is null such that the restart mechanism in geddy would still work? I hacked it by just setting p = '.js' but I don't think thats the right approach for a proper fix.

TypeError: log has no method log

file.js imports './log' as out and then attempts to call out.log. However the function log exported by log.js has no such method.

Full trace is below (I got it when building Typescript via jake but it's not specific to that):

TypeError: Object function (obj) {
  _output(obj, 'info');
} has no method 'log'
    at logger.log (C:\Stuff\Sources\typescript\node_modules\jake\node_modules\utilities\lib\file.js:35:9)
    at EventEmitter.fileUtils.cpR (C:\Stuff\Sources\typescript\node_modules\jake\node_modules\utilities\lib\file.js:251:14)
    at null.action (C:\Stuff\Sources\typescript\Jakefile:300:9)
    at TaskBase.run (C:\Stuff\Sources\typescript\node_modules\jake\lib\task\task.js:199:27)
    at TaskBase.handlePrereqComplete (C:\Stuff\Sources\typescript\node_modules\jake\lib\task\task.js:181:12)
    at null.<anonymous> (C:\Stuff\Sources\typescript\node_modules\jake\lib\task\task.js:149:16)
    at g (events.js:180:16)
    at EventEmitter.emit (events.js:92:17)
    at FileBase.complete (C:\Stuff\Sources\typescript\node_modules\jake\lib\task\file_task.js:92:10)
    at api.complete (C:\Stuff\Sources\typescript\node_modules\jake\lib\api.js:287:15)

I fixed it for myself by adding log.log = log; to log.js

Preserve file permissions/mode with cpR

This was originally created in the Jake repo at jakejs/jake#145.

To mimic the cp -R command, file permissions should be kept on copied files if they're not overwriting existing files. If files are being overwritten, they'll keep the original permissions unless an option (such as preserveMode) is specified.

Node 0.10 breaking changes break utilities (and jake)

As per https://github.com/joyent/node/wiki/Api-changes-between-v0.8-and-v0.10 , path.resolve & path.join will now throw an error on non-string input (previously they ignored it).

I was just trying to build TypeScript (which uses jake) with the latest Node v0.10 and hit issues. mkDirP in ./lib/file.js doesn't initialize currPath, so the first call to path.join with it (https://github.com/mde/utilities/blob/master/lib/file.js#L285) throws an exception now.

Simply changing the currPath declaration 10 lines earlier to ' currPath = "" ' (an empty string) fixed the issue for me. Not sure any other areas you might get bitten by this!

Prototype Pollution using utilities.i18n.loadLocale()

Hi,There's a prototype pollution vulnerability in function _mix() in utilities/lib/core.js, the risk locate is in here:

utilities/lib/core.js

Line 65 in ba6be1f

_mix(targ, sources[i], merge);

utilities/lib/core.js

Line 41 in ba6be1f

targ[p] = src[p];

and the POC is:
var utilities = require("utilities")
bad_objects= {test:"123"}
console.log("Before:"+{}.test)
utilities.i18n.loadLocale("proto",bad_objects,{},true)
console.log("After:"+{}.test)

In the file i18n.js, there is a function called loadLocale, which calls the mixin function in utilities/lib/core.js, and it calls the _mix function in 22 lines, and in the _mix function, where the object is merged, resulting in prototype pollution

More information about the vulnerability: https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf

file.rmRf() works incorrectly with symlinks

Originally file against Jake.

When a directory that is a symlink or contains a symlink is passed into file.rmRf(), the symlink is not deleted and the contents of any linked folders are deleted. Dangerous behavior that does not accurately mirror rm -rf in Bash.

I have a PR coming with tests that document steps to reproduce and expected results.