Gathering detailed insights and metrics for whomst
Gathering detailed insights and metrics for whomst
Gathering detailed insights and metrics for whomst
Gathering detailed insights and metrics for whomst
npm install whomst
Typescript
Module System
Node Version
NPM Version
JavaScript (74.9%)
Shell (25.1%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
MIT License
2 Stars
16 Commits
3 Forks
2 Watchers
4 Branches
1 Contributors
Updated on Mar 04, 2023
Latest Version
0.1.5
Package Id
whomst@0.1.5
Unpacked Size
20.53 kB
Size
7.80 kB
File Count
12
NPM Version
3.10.10
Node Version
6.11.2
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
Gets user and group info, by any means necessary
Node doesn't have a built-in function to resolve an OS username or groupname to a UID or GID (or vice versa). There are a few native modules that expose the functions necessary to get this information, but native modules can't always be relied upon (in environments where the toolchain isn't present, or the architecture isn't supported, or the targeted ABI is unmaintained, or any of a number of other possible ways native modules can break).
There are other ways to get this information, but they've all got possible pitfalls themselves. You can query the system database with the getent
binary, but that will fail if getent
isn't present. You can try reading the contents of /etc/passwd
, but that will fail if the current user doesn't have permission to access /etc/passwd
(or if user IDs are coming from a different source, such as LDAP). You can exploit the locations in Node's code where it calls out to the relevant functions as a side effect (namely process.setuid
and os.userInfo
, which both incorporate getpwnam
under the hood), but this requires the user to have permission to setuid to the user being queried, not to mention being incredibly hacky. (Nonetheless, this last technique is the approach actually used internally by npm.)
For a program to truly be resilient against all these possible contingencies, it should be ready to try all of the possible techniques.
whomst will try obtaining info, in order of availability, from:
getpwnam
and getgrnam
functions from the posix modulegetent(1)
binary/etc/passwd
and /etc/group
setuid
or setgid
with the given name (as used by the uid-number module)As of v0.1.2, not all of these code paths have been tested (though they are all believed to be implemented).
whomst.user
andwhomst.group
take a number or string and return a promise. whomst.sync.user
and whomst.sync.group
do the same thing, but synchronously instead of via promises.
These functions return objects compatible with the return values of the corresponding functions from the posix
package. See the documentation for posix.getpwnam and posix.getgrnam for examples of returns from whomst.user and whomst.group, respectively.
Note that not all fields are guaranteed: if whomst.group
has to fall back to the setgid
hack method for determining a group's gid, the return value may only contain name
and gid
(or even only gid
, if the name wasn't provided). This means that you may not be able to determine a group's name from its gid, if all the more-reliable mechanisms fail.
Unlike some similar modules like uid-number
, whomst
does not cache any results between calls (as these results could, in theory, change between two separate invocations). If you wish to cache results between calls to this function (say, if you're going to make thousands of calls to it in the space of a very short time), you may wish to implement a memoization layer like fast-memoize around whomst
.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
4 existing vulnerabilities detected
Details
Reason
no SAST tool detected
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 0/16 approved changesets -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Score
Last Scanned on 2025-06-30
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More