Enhance refactor commands with controller-aware Route() updates and fix code quality violations
Add semantic token highlighting for 'that' variable and comment file references in VS Code extension Add Phone_Text_Input and Currency_Input components with formatting utilities Implement client widgets, form standardization, and soft delete functionality Add modal scroll lock and update documentation Implement comprehensive modal system with form integration and validation Fix modal component instantiation using jQuery plugin API Implement modal system with responsive sizing, queuing, and validation support Implement form submission with validation, error handling, and loading states Implement country/state selectors with dynamic data loading and Bootstrap styling Revert Rsx::Route() highlighting in Blade/PHP files Target specific PHP scopes for Rsx::Route() highlighting in Blade Expand injection selector for Rsx::Route() highlighting Add custom syntax highlighting for Rsx::Route() and Rsx.Route() calls Update jqhtml packages to v2.2.165 Add bundle path validation for common mistakes (development mode only) Create Ajax_Select_Input widget and Rsx_Reference_Data controller Create Country_Select_Input widget with default country support Initialize Tom Select on Select_Input widgets Add Tom Select bundle for enhanced select dropdowns Implement ISO 3166 geographic data system for country/region selection Implement widget-based form system with disabled state support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
0
node_modules/resolve/.github/FUNDING.yml
generated
vendored
Executable file → Normal file
0
node_modules/resolve/.github/FUNDING.yml
generated
vendored
Executable file → Normal file
119
node_modules/resolve/.github/INCIDENT_RESPONSE_PROCESS.md
generated
vendored
Normal file
119
node_modules/resolve/.github/INCIDENT_RESPONSE_PROCESS.md
generated
vendored
Normal file
@@ -0,0 +1,119 @@
|
||||
# Incident Response Process for **resolve**
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
We take the security of **resolve** very seriously. If you believe you’ve found a security vulnerability, please inform us responsibly through coordinated disclosure.
|
||||
|
||||
### How to Report
|
||||
|
||||
> **Do not** report security vulnerabilities through public GitHub issues, discussions, or social media.
|
||||
|
||||
Instead, please use one of these secure channels:
|
||||
|
||||
1. **GitHub Security Advisories**
|
||||
Use the **Report a vulnerability** button in the Security tab of the [browserify/resolve repository](https://github.com/browserify/resolve).
|
||||
|
||||
2. **Email**
|
||||
Follow the posted [Security Policy](https://github.com/browserify/resolve/security/policy).
|
||||
|
||||
### What to Include
|
||||
|
||||
**Required Information:**
|
||||
- Brief description of the vulnerability type
|
||||
- Affected version(s) and components
|
||||
- Steps to reproduce the issue
|
||||
- Impact assessment (what an attacker could achieve)
|
||||
- Confirm the issue is not present in test files (in other words, only via the official entry points in `exports`)
|
||||
|
||||
**Helpful Additional Details:**
|
||||
- Full paths of affected source files
|
||||
- Specific commit or branch where the issue exists
|
||||
- Required configuration to reproduce
|
||||
- Proof-of-concept code (if available)
|
||||
- Suggested mitigation or fix
|
||||
|
||||
## Our Response Process
|
||||
|
||||
**Timeline Commitments:**
|
||||
- **Initial acknowledgment**: Within 24 hours
|
||||
- **Detailed response**: Within 3 business days
|
||||
- **Status updates**: Every 7 days until resolved
|
||||
- **Resolution target**: 90 days for most issues
|
||||
|
||||
**What We’ll Do:**
|
||||
1. Acknowledge your report and assign a tracking ID
|
||||
2. Assess the vulnerability and determine severity
|
||||
3. Develop and test a fix
|
||||
4. Coordinate disclosure timeline with you
|
||||
5. Release a security update and publish an advisory and CVE
|
||||
6. Credit you in our security advisory (if desired)
|
||||
|
||||
## Disclosure Policy
|
||||
|
||||
- **Coordinated disclosure**: We’ll work with you on timing
|
||||
- **Typical timeline**: 90 days from report to public disclosure
|
||||
- **Early disclosure**: If actively exploited
|
||||
- **Delayed disclosure**: For complex issues
|
||||
|
||||
## Scope
|
||||
|
||||
**In Scope:**
|
||||
- **resolve** package (all supported versions)
|
||||
- Official examples and documentation
|
||||
- Core resolution APIs
|
||||
- Dependencies with direct security implications
|
||||
|
||||
**Out of Scope:**
|
||||
- Third-party wrappers or extensions
|
||||
- Bundler-specific integrations
|
||||
- Social engineering or physical attacks
|
||||
- Theoretical vulnerabilities without practical exploitation
|
||||
- Issues in non-production files
|
||||
|
||||
## Security Measures
|
||||
|
||||
**Our Commitments:**
|
||||
- Regular vulnerability scanning via `npm audit`
|
||||
- Automated security checks in CI/CD (GitHub Actions)
|
||||
- Secure coding practices and mandatory code review
|
||||
- Prompt patch releases for critical issues
|
||||
|
||||
**User Responsibilities:**
|
||||
- Keep **resolve** updated
|
||||
- Monitor dependency vulnerabilities
|
||||
- Follow secure configuration guidelines for module resolution
|
||||
|
||||
## Legal Safe Harbor
|
||||
|
||||
**We will NOT:**
|
||||
- Initiate legal action
|
||||
- Contact law enforcement
|
||||
- Suspend or terminate your access
|
||||
|
||||
**You must:**
|
||||
- Only test against your own installations
|
||||
- Not access, modify, or delete user data
|
||||
- Not degrade service availability
|
||||
- Not publicly disclose before coordinated disclosure
|
||||
- Act in good faith
|
||||
|
||||
## Recognition
|
||||
|
||||
- **Advisory Credits**: Credit in GitHub Security Advisories (unless anonymous)
|
||||
|
||||
## Security Updates
|
||||
|
||||
**Stay Informed:**
|
||||
- Subscribe to npm updates for **resolve**
|
||||
- Enable GitHub Security Advisory notifications
|
||||
|
||||
**Update Process:**
|
||||
- Patch releases (e.g., 1.22.10 → 1.22.11)
|
||||
- Out-of-band releases for critical issues
|
||||
- Advisories via GitHub Security Advisories
|
||||
|
||||
## Contact Information
|
||||
|
||||
- **Security reports**: Security tab of [browserify/resolve](https://github.com/browserify/resolve/security)
|
||||
- **General inquiries**: GitHub Discussions or Issues
|
||||
|
||||
74
node_modules/resolve/.github/THREAT_MODEL.md
generated
vendored
Normal file
74
node_modules/resolve/.github/THREAT_MODEL.md
generated
vendored
Normal file
@@ -0,0 +1,74 @@
|
||||
## Threat Model for resolve (module path resolution library)
|
||||
|
||||
### 1. Library Overview
|
||||
|
||||
- **Library Name:** resolve
|
||||
- **Brief Description:** Implements Node.js `require.resolve()` algorithm for synchronous and asynchronous file path resolution. Used to locate modules and files in Node.js projects.
|
||||
- **Key Public APIs/Functions:** `resolve.sync()` / `resolve/sync`, `resolve()` / `resolve/async`
|
||||
|
||||
### 2. Define Scope
|
||||
|
||||
This threat model focuses on the core path resolution algorithm, including filesystem interaction, option handling, and cache management.
|
||||
|
||||
### 3. Conceptual System Diagram
|
||||
|
||||
```
|
||||
Caller Application → resolve(id, options) → Resolution Algorithm → File System
|
||||
│
|
||||
└→ Options Handling
|
||||
└→ Cache System
|
||||
```
|
||||
|
||||
**Trust Boundaries:**
|
||||
- **Input module IDs:** May come from untrusted sources (user input, configuration)
|
||||
- **Filesystem access:** The library interacts with the filesystem to resolve paths
|
||||
- **Options:** Provided by the caller
|
||||
- **Cache:** Used to improve performance, but could be a vector for tampering or information disclosure if not handled securely
|
||||
|
||||
### 4. Identify Assets
|
||||
|
||||
- **Integrity of resolution output:** Ensure correct and safe file path matching.
|
||||
- **Confidentiality of configuration:** Prevent sensitive path information from being leaked.
|
||||
- **Availability/performance for host application:** Prevent crashes or resource exhaustion.
|
||||
- **Security of host application:** Prevent path traversal or unintended filesystem access.
|
||||
- **Reputation of library:** Maintain trust by avoiding supply chain attacks and vulnerabilities[1][3][4].
|
||||
|
||||
### 5. Identify Threats
|
||||
|
||||
| Component / API / Interaction | S | T | R | I | D | E |
|
||||
|-----------------------------------------------------|----|----|----|----|----|----|
|
||||
| Public API Call (`resolve/async`, `resolve/sync`) | ✓ | ✓ | – | ✓ | – | – |
|
||||
| Filesystem Access | – | ✓ | – | ✓ | ✓ | – |
|
||||
| Options Handling | ✓ | ✓ | – | ✓ | – | – |
|
||||
| Cache System | – | ✓ | – | ✓ | – | – |
|
||||
|
||||
**Key Threats:**
|
||||
- **Spoofing:** Malicious module IDs mimicking legitimate packages, or spoofing configuration options[1].
|
||||
- **Tampering:** Caller-provided paths altering resolution order, or cache tampering leading to incorrect results[1][4].
|
||||
- **Information Disclosure:** Error messages revealing filesystem structure or sensitive paths[1].
|
||||
- **Denial of Service:** Recursive or excessive resolution exhausting filesystem handles or causing application crashes[1].
|
||||
- **Path Traversal:** Malicious input allowing access to files outside the intended directory[4].
|
||||
|
||||
### 6. Mitigation/Countermeasures
|
||||
|
||||
| Threat Identified | Proposed Mitigation |
|
||||
|--------------------------------------------|---------------------|
|
||||
| Spoofing (malicious module IDs/config) | Sanitize input IDs; validate against known patterns; restrict `basedir` to app-controlled paths[1][4]. |
|
||||
| Tampering (path traversal, cache) | Validate input IDs for directory escapes; secure cache reads/writes; restrict cache to trusted sources[1][4]. |
|
||||
| Information Disclosure (error messages) | Generic "not found" errors without internal paths; avoid exposing sensitive configuration in errors[1]. |
|
||||
| Denial of Service (resource exhaustion) | Limit recursive resolution depth; implement timeout; monitor for excessive filesystem operations[1]. |
|
||||
|
||||
### 7. Risk Ranking
|
||||
|
||||
- **High:** Path traversal via malicious IDs (if not properly mitigated)
|
||||
- **Medium:** Cache tampering or spoofing (if cache is not secured)
|
||||
- **Low:** Information disclosure in errors (if error handling is generic)
|
||||
|
||||
### 8. Next Steps & Review
|
||||
|
||||
1. **Implement input sanitization for module IDs and configuration.**
|
||||
2. **Add resolution depth limiting and timeout.**
|
||||
3. **Audit cache handling for race conditions and tampering.**
|
||||
4. **Regularly review dependencies for vulnerabilities.**
|
||||
5. **Keep documentation and threat model up to date.**
|
||||
6. **Monitor for new threats as the ecosystem and library evolve[1][3].**
|
||||
Reference in New Issue
Block a user