@7nsane/zift 1.0.9 → 1.2.0

package/zift-user-test/node_modules/qs/.editorconfig

@@ -1,46 +0,0 @@
-root = true
-
-[*]
-indent_style = space
-indent_size = 4
-end_of_line = lf
-charset = utf-8
-trim_trailing_whitespace = true
-insert_final_newline = true
-max_line_length = 180
-quote_type = single
-
-[test/*]
-max_line_length = off
-
-[LICENSE.md]
-indent_size = off
-
-[*.md]
-max_line_length = off
-
-[*.json]
-max_line_length = off
-
-[Makefile]
-max_line_length = off
-
-[CHANGELOG.md]
-indent_style = space
-indent_size = 2
-
-[LICENSE]
-indent_size = 2
-max_line_length = off
-
-[coverage/**/*]
-indent_size = off
-indent_style = off
-indent = off
-max_line_length = off
-
-[.nycrc]
-indent_style = tab
-
-[tea.yaml]
-indent_size = 2

package/zift-user-test/node_modules/qs/.github/FUNDING.yml

@@ -1,12 +0,0 @@
-# These are supported funding model platforms
-
-github: [ljharb]
-patreon: # Replace with a single Patreon username
-open_collective: # Replace with a single Open Collective username
-ko_fi: # Replace with a single Ko-fi username
-tidelift: npm/qs
-community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
-liberapay: # Replace with a single Liberapay username
-issuehunt: # Replace with a single IssueHunt username
-otechie: # Replace with a single Otechie username
-custom: # Replace with a single custom sponsorship URL

package/zift-user-test/node_modules/qs/.github/SECURITY.md

@@ -1,11 +0,0 @@
-# Security
-
-Please file a private vulnerability report via GitHub, email [@ljharb](https://github.com/ljharb), or see https://tidelift.com/security if you have a potential security vulnerability to report.
-
-## Incident Response Plan
-
-Please see our [Incident Response Plan](https://github.com/ljharb/.github/blob/main/INCIDENT_RESPONSE_PLAN.md).
-
-## Threat Model
-
-Please see [THREAT_MODEL.md](./THREAT_MODEL.md).

package/zift-user-test/node_modules/qs/.github/THREAT_MODEL.md

@@ -1,78 +0,0 @@
-## Threat Model for qs (querystring parsing library)
-
-### 1. Library Overview
-
-- **Library Name:** qs
-- **Brief Description:** A JavaScript library for parsing and stringifying URL query strings, supporting nested objects and arrays. It is widely used in Node.js and web applications for processing query parameters[2][6][8].
-- **Key Public APIs/Functions:** `qs.parse()`, `qs.stringify()`
-
-### 2. Define Scope
-
-This threat model focuses on the core parsing and stringifying functionality, specifically the handling of nested objects and arrays, option validation, and cycle management in stringification.
-
-### 3. Conceptual System Diagram
-
-```
-Caller Application → qs.parse(input, options) → Parsing Engine → Output Object
-                           │
-                           └→ Options Handling
-
-Caller Application → qs.stringify(obj, options) → Stringifying Engine → Output String
-                           │
-                           └→ Options Handling
-                           └→ Cycle Tracking
-```
-
-**Trust Boundaries:**
-- **Input string (parse):** May come from untrusted sources (e.g., user input, network requests)
-- **Input object (stringify):** May contain cycles, which can lead to infinite loops during stringification
-- **Options:** Provided by the caller
-- **Cycle Tracking:** Used only during stringification to detect and handle circular references
-
-### 4. Identify Assets
-
-- **Integrity of parsed output:** Prevent malicious manipulation of the output object structure, especially ensuring builtins/globals are not modified as a result of parse[3][4][8].
-- **Confidentiality of processed data:** Avoid leaking sensitive information through errors or output.
-- **Availability/performance for host application:** Prevent crashes or resource exhaustion in the consuming application.
-- **Security of host application:** Prevent the library from being a vector for attacks (e.g., prototype pollution, DoS).
-- **Reputation of library:** Maintain trust by avoiding supply chain attacks and vulnerabilities[1].
-
-### 5. Identify Threats
-
-| Component / API / Interaction         | S  | T  | R  | I  | D  | E  |
-|---------------------------------------|----|----|----|----|----|----|
-| Public API Call (`parse`)             | –  | ✓  | –  | ✓  | ✓  | ✓  |
-| Public API Call (`stringify`)         | –  | ✓  | –  | ✓  | ✓  | –  |
-| Options Handling                      | ✓  | ✓  | –  | ✓  | –  | ✓  |
-| Dependency Interaction                | –  | –  | –  | –  | ✓  | –  |
-
-**Key Threats:**
-- **Tampering:** Malicious input can, if not prevented, alter parsed output (e.g., prototype pollution via `__proto__`, modification of builtins/globals)[3][4][8].
-- **Information Disclosure:** Error messages may expose internal details or sensitive data.
-- **Denial of Service:** Large or malformed input can exhaust memory or CPU.
-- **Elevation of Privilege:** Prototype pollution can lead to unintended privilege escalation in the host application[3][4][8].
-
-### 6. Mitigation/Countermeasures
-
-| Threat Identified                                 | Proposed Mitigation |
-|---------------------------------------------------|---------------------|
-| Tampering (malicious input, prototype pollution)  | Strict input validation; keep `allowPrototypes: false` by default; use `plainObjects` for output; ensure builtins/globals are never modified by parse[4][8]. |
-| Information Disclosure (error messages)           | Generic error messages without stack traces or internal paths. |
-| Denial of Service (memory/CPU exhaustion)         | Enforce `arrayLimit` and `parameterLimit` with safe defaults; enable `throwOnLimitExceeded`; limit nesting depth[7]. |
-| Elevation of Privilege (prototype pollution)      | Keep `allowPrototypes: false`; validate options against allowlist; use `plainObjects` to avoid prototype pollution[4][8]. |
-
-### 7. Risk Ranking
-
-- **High:** Denial of Service via array parsing or malformed input (historical vulnerability)
-- **Medium:** Prototype pollution via options or input (if `allowPrototypes` enabled)
-- **Low:** Information disclosure in errors
-
-### 8. Next Steps & Review
-
-1. **Audit option validation logic.**
-2. **Add depth limiting to nested parsing and stringification.**
-3. **Implement fuzz testing for parser and stringifier edge cases.**
-4. **Regularly review dependencies for vulnerabilities.**
-5. **Keep documentation and threat model up to date.**
-6. **Ensure builtins/globals are never modified as a result of parse.**
-7. **Support round-trip consistency between parse and stringify as a non-security goal, with the right options[5][9].**

package/zift-user-test/node_modules/qs/.nycrc

@@ -1,13 +0,0 @@
-{
-	"all": true,
-	"check-coverage": false,
-	"reporter": ["text-summary", "text", "html", "json"],
-	"lines": 86,
-	"statements": 85.93,
-	"functions": 82.43,
-	"branches": 76.06,
-	"exclude": [
-		"coverage",
-		"dist"
-	]
-}