@hybridlabor-api/aos 4.4.1 → 4.4.2-beta.1

package/mcps/davinci-mcp-professional/.claude/commands/security-review.md

@@ -1,191 +0,0 @@
----
-allowed-tools: Bash(git diff:*), Bash(git status:*), Bash(git log:*), Bash(git show:*), Bash(git remote show:*), Read, Glob, Grep, LS, Task
-description: Complete a security review of the pending changes on the current branch
----
-
-You are a senior security engineer conducting a focused security review of the changes on this branch.
-
-GIT STATUS:
-
-```
-!`git status`
-```
-
-FILES MODIFIED:
-
-```
-!`git diff --name-only origin/HEAD...`
-```
-
-COMMITS:
-
-```
-!`git log --no-decorate origin/HEAD...`
-```
-
-DIFF CONTENT:
-
-```
-!`git diff --merge-base origin/HEAD`
-```
-
-Review the complete diff above. This contains all code changes in the PR.
-
-
-OBJECTIVE:
-Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential. This is not a general code review - focus ONLY on security implications newly added by this PR. Do not comment on existing security concerns.
-
-CRITICAL INSTRUCTIONS:
-1. MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability
-2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings
-3. FOCUS ON IMPACT: Prioritize vulnerabilities that could lead to unauthorized access, data breaches, or system compromise
-4. EXCLUSIONS: Do NOT report the following issue types:
-   - Denial of Service (DOS) vulnerabilities, even if they allow service disruption
-   - Secrets or sensitive data stored on disk (these are handled by other processes)
-   - Rate limiting or resource exhaustion issues
-
-SECURITY CATEGORIES TO EXAMINE:
-
-**Input Validation Vulnerabilities:**
-- SQL injection via unsanitized user input
-- Command injection in system calls or subprocesses
-- XXE injection in XML parsing
-- Template injection in templating engines
-- NoSQL injection in database queries
-- Path traversal in file operations
-
-**Authentication & Authorization Issues:**
-- Authentication bypass logic
-- Privilege escalation paths
-- Session management flaws
-- JWT token vulnerabilities
-- Authorization logic bypasses
-
-**Crypto & Secrets Management:**
-- Hardcoded API keys, passwords, or tokens
-- Weak cryptographic algorithms or implementations
-- Improper key storage or management
-- Cryptographic randomness issues
-- Certificate validation bypasses
-
-**Injection & Code Execution:**
-- Remote code execution via deseralization
-- Pickle injection in Python
-- YAML deserialization vulnerabilities
-- Eval injection in dynamic code execution
-- XSS vulnerabilities in web applications (reflected, stored, DOM-based)
-
-**Data Exposure:**
-- Sensitive data logging or storage
-- PII handling violations
-- API endpoint data leakage
-- Debug information exposure
-
-Additional notes:
-- Even if something is only exploitable from the local network, it can still be a HIGH severity issue
-
-ANALYSIS METHODOLOGY:
-
-Phase 1 - Repository Context Research (Use file search tools):
-- Identify existing security frameworks and libraries in use
-- Look for established secure coding patterns in the codebase
-- Examine existing sanitization and validation patterns
-- Understand the project's security model and threat model
-
-Phase 2 - Comparative Analysis:
-- Compare new code changes against existing security patterns
-- Identify deviations from established secure practices
-- Look for inconsistent security implementations
-- Flag code that introduces new attack surfaces
-
-Phase 3 - Vulnerability Assessment:
-- Examine each modified file for security implications
-- Trace data flow from user inputs to sensitive operations
-- Look for privilege boundaries being crossed unsafely
-- Identify injection points and unsafe deserialization
-
-REQUIRED OUTPUT FORMAT:
-
-You MUST output your findings in markdown. The markdown output should contain the file, line number, severity, category (e.g. `sql_injection` or `xss`), description, exploit scenario, and fix recommendation. 
-
-For example:
-
-# Vuln 1: XSS: `foo.py:42`
-
-* Severity: High
-* Description: User input from `username` parameter is directly interpolated into HTML without escaping, allowing reflected XSS attacks
-* Exploit Scenario: Attacker crafts URL like /bar?q=<script>alert(document.cookie)</script> to execute JavaScript in victim's browser, enabling session hijacking or data theft
-* Recommendation: Use Flask's escape() function or Jinja2 templates with auto-escaping enabled for all user inputs rendered in HTML
-
-SEVERITY GUIDELINES:
-- **HIGH**: Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass
-- **MEDIUM**: Vulnerabilities requiring specific conditions but with significant impact
-- **LOW**: Defense-in-depth issues or lower-impact vulnerabilities
-
-CONFIDENCE SCORING:
-- 0.9-1.0: Certain exploit path identified, tested if possible
-- 0.8-0.9: Clear vulnerability pattern with known exploitation methods
-- 0.7-0.8: Suspicious pattern requiring specific conditions to exploit
-- Below 0.7: Don't report (too speculative)
-
-FINAL REMINDER:
-Focus on HIGH and MEDIUM findings only. Better to miss some theoretical issues than flood the report with false positives. Each finding should be something a security engineer would confidently raise in a PR review.
-
-FALSE POSITIVE FILTERING:
-
-> You do not need to run commands to reproduce the vulnerability, just read the code to determine if it is a real vulnerability. Do not use the bash tool or write to any files.
->
-> HARD EXCLUSIONS - Automatically exclude findings matching these patterns:
-> 1. Denial of Service (DOS) vulnerabilities or resource exhaustion attacks.
-> 2. Secrets or credentials stored on disk if they are otherwise secured.
-> 3. Rate limiting concerns or service overload scenarios.
-> 4. Memory consumption or CPU exhaustion issues.
-> 5. Lack of input validation on non-security-critical fields without proven security impact.
-> 6. Input sanitization concerns for GitHub Action workflows unless they are clearly triggerable via untrusted input.
-> 7. A lack of hardening measures. Code is not expected to implement all security best practices, only flag concrete vulnerabilities.
-> 8. Race conditions or timing attacks that are theoretical rather than practical issues. Only report a race condition if it is concretely problematic.
-> 9. Vulnerabilities related to outdated third-party libraries. These are managed separately and should not be reported here.
-> 10. Memory safety issues such as buffer overflows or use-after-free-vulnerabilities are impossible in rust. Do not report memory safety issues in rust or any other memory safe languages.
-> 11. Files that are only unit tests or only used as part of running tests.
-> 12. Log spoofing concerns. Outputting un-sanitized user input to logs is not a vulnerability.
-> 13. SSRF vulnerabilities that only control the path. SSRF is only a concern if it can control the host or protocol.
-> 14. Including user-controlled content in AI system prompts is not a vulnerability.
-> 15. Regex injection. Injecting untrusted content into a regex is not a vulnerability.
-> 16. Regex DOS concerns.
-> 16. Insecure documentation. Do not report any findings in documentation files such as markdown files.
-> 17. A lack of audit logs is not a vulnerability.
-> 
-> PRECEDENTS -
-> 1. Logging high value secrets in plaintext is a vulnerability. Logging URLs is assumed to be safe.
-> 2. UUIDs can be assumed to be unguessable and do not need to be validated.
-> 3. Environment variables and CLI flags are trusted values. Attackers are generally not able to modify them in a secure environment. Any attack that relies on controlling an environment variable is invalid.
-> 4. Resource management issues such as memory or file descriptor leaks are not valid.
-> 5. Subtle or low impact web vulnerabilities such as tabnabbing, XS-Leaks, prototype pollution, and open redirects should not be reported unless they are extremely high confidence.
-> 6. React and Angular are generally secure against XSS. These frameworks do not need to sanitize or escape user input unless it is using dangerouslySetInnerHTML, bypassSecurityTrustHtml, or similar methods. Do not report XSS vulnerabilities in React or Angular components or tsx files unless they are using unsafe methods.
-> 7. Most vulnerabilities in github action workflows are not exploitable in practice. Before validating a github action workflow vulnerability ensure it is concrete and has a very specific attack path.
-> 8. A lack of permission checking or authentication in client-side JS/TS code is not a vulnerability. Client-side code is not trusted and does not need to implement these checks, they are handled on the server-side. The same applies to all flows that send untrusted data to the backend, the backend is responsible for validating and sanitizing all inputs.
-> 9. Only include MEDIUM findings if they are obvious and concrete issues.
-> 10. Most vulnerabilities in ipython notebooks (*.ipynb files) are not exploitable in practice. Before validating a notebook vulnerability ensure it is concrete and has a very specific attack path where untrusted input can trigger the vulnerability.
-> 11. Logging non-PII data is not a vulnerability even if the data may be sensitive. Only report logging vulnerabilities if they expose sensitive information such as secrets, passwords, or personally identifiable information (PII).
-> 12. Command injection vulnerabilities in shell scripts are generally not exploitable in practice since shell scripts generally do not run with untrusted user input. Only report command injection vulnerabilities in shell scripts if they are concrete and have a very specific attack path for untrusted input.
-> 
-> SIGNAL QUALITY CRITERIA - For remaining findings, assess:
-> 1. Is there a concrete, exploitable vulnerability with a clear attack path?
-> 2. Does this represent a real security risk vs theoretical best practice?
-> 3. Are there specific code locations and reproduction steps?
-> 4. Would this finding be actionable for a security team?
-> 
-> For each finding, assign a confidence score from 1-10:
-> - 1-3: Low confidence, likely false positive or noise
-> - 4-6: Medium confidence, needs investigation
-> - 7-10: High confidence, likely true vulnerability
-
-START ANALYSIS:
-
-Begin your analysis now. Do this in 3 steps:
-
-1. Use a sub-task to identify vulnerabilities. Use the repository exploration tools to understand the codebase context, then analyze the PR changes for security implications. In the prompt for this sub-task, include all of the above.
-2. Then for each vulnerability identified by the above sub-task, create a new sub-task to filter out false-positives. Launch these sub-tasks as parallel sub-tasks. In the prompt for these sub-tasks, include everything in the "FALSE POSITIVE FILTERING" instructions.
-3. Filter out any vulnerabilities where the sub-task reported a confidence less than 8.
-
-Your final reply must contain the markdown report and nothing else.

package/mcps/davinci-mcp-professional/.claude/settings.json

@@ -1 +0,0 @@
-{}

package/mcps/davinci-mcp-professional/.editorconfig

@@ -1,27 +0,0 @@
-# editorconfig.org
-
-root = true
-
-[*]
-charset = utf-8
-end_of_line = lf
-indent_size = 4
-indent_style = space
-insert_final_newline = true
-trim_trailing_whitespace = true
-
-[*.{c,cpp,h,hpp}]
-indent_size = 4
-
-[*.{js,ts,json,yaml,yml}]
-indent_size = 2
-
-[Makefile]
-indent_style = tab
-
-[*.{md,txt}]
-indent_size = 2
-max_line_length = 79
-
-[*.{py,sh,bash}]
-indent_size = 4

package/mcps/davinci-mcp-professional/.gitattributes

@@ -1,207 +0,0 @@
-# GIT ATTRIBUTES
-#
-# These settings are for any project.
-#
-# Details per file setting:
-#   text:   These files should be normalized (i.e. convert CRLF to LF).
-#           unless otherwise specified.
-#   binary: These files are binary and should be left untouched.
-#
-# * Note that binary is a macro for -text -diff.
-# ---------------------------------------------------------------------
-
-# AUTO-DETECT
-#   Handle line endings automatically for files detected as
-#   text and leave all files detected as binary untouched.
-#   This will handle all files NOT defined below.
-* text=auto
-
-# SOURCE CODE
-*.{bat,[bB][aA][tT]}    text eol=crlf
-*.c                     text
-*.class                 binary
-*.{cmd,[cC][mM][dD]}    text eol=crlf
-*.coffee                text
-*.cpp                   text
-*.css                   text
-*.h                     text
-*.hpp                   text
-*.htm                   text
-*.html                  text
-*.inc                   text
-*.ini                   text eol=crlf
-*.java                  text
-*.js                    text
-*.json                  text
-*.jsx                   text
-*.less                  text
-*.od                    text
-*.onlydata              text
-*.php                   text
-*.pl                    text
-*.properties            text
-*.py                    text
-*.rb                    text
-*.sass                  text
-/hooks/*                text eol=lf
-*.scm                   text
-*.scss                  text
-*.sh                    text eol=lf
-*.sql                   text
-*.styl                  text
-*.tag                   text
-*.ts                    text
-*.tsx                   text
-*.txt                   text eol=crlf
-*.xml                   text
-*.xhtml                 text
-
-# DOCKER
-*.dockerignore  text
-Dockerfile      text
-
-# DOCUMENTATION
-*.markdown      text
-*.md            text
-*.mdwn          text
-*.mdown         text
-*.mkd           text
-*.mkdn          text
-*.mdtxt         text
-*.mdtext        text
-*.rst           text
-*.txt           text
-AUTHORS         text
-CHANGELOG       text
-CHANGES         text
-CONTRIBUTING    text
-COPYING         text
-copyright       text
-*COPYRIGHT*     text
-INSTALL         text
-license         text
-LICENSE         text
-NEWS            text
-readme          text
-*README*        text
-TODO            text
-
-# TEMPLATES
-*.dot           text
-*.ejs           text
-*.haml          text
-*.handlebars    text
-*.hbs           text
-*.hbt           text
-*.jade          text
-*.latte         text
-*.mustache      text
-*.njk           text
-*.phtml         text
-*.tmpl          text
-*.tpl           text
-*.twig          text
-
-# LINTERS
-.babelrc        text
-.csslintrc      text
-.eslintrc       text
-.htmlhintrc     text
-.jscsrc         text
-.jshintrc       text
-.jshintignore   text
-.prettierrc     text
-.stylelintrc    text
-
-# CONFIGS
-*.bowerrc       text
-*.cnf           text
-*.conf          text
-*.config        text
-.browserslistrc text
-.editorconfig   text
-.gitattributes  text
-.gitconfig      text
-.gitignore      text
-.htaccess       text
-*.npmignore     text
-*.yaml          text
-*.yml           text
-browserslist    text
-Makefile        text
-makefile        text
-
-# HEROKU
-Procfile    text
-.slugignore text
-
-# GRAPHICS
-*.ai    binary
-*.bmp   binary
-*.eps   binary
-*.gif   binary
-*.ico   binary
-*.jng   binary
-*.jp2   binary
-*.jpg   binary
-*.jpeg  binary
-*.jpx   binary
-*.jxr   binary
-*.pdf   binary
-*.png   binary
-*.psb   binary
-*.psd   binary
-*.svg   text
-*.svgz  binary
-*.tif   binary
-*.tiff  binary
-*.wbmp  binary
-*.webp  binary
-
-# AUDIO
-*.kar   binary
-*.m4a   binary
-*.mid   binary
-*.midi  binary
-*.mp3   binary
-*.ogg   binary
-*.ra    binary
-
-# VIDEO
-*.3gpp  binary
-*.3gp   binary
-*.as    binary
-*.asf   binary
-*.asx   binary
-*.fla   binary
-*.flv   binary
-*.m4v   binary
-*.mng   binary
-*.mov   binary
-*.mp4   binary
-*.mpeg  binary
-*.mpg   binary
-*.ogv   binary
-*.swc   binary
-*.swf   binary
-*.webm  binary
-
-# ARCHIVES
-*.7z    binary
-*.gz    binary
-*.jar   binary
-*.rar   binary
-*.tar   binary
-*.tgz   binary
-*.zip   binary
-
-# FONTS
-*.ttf   binary
-*.eot   binary
-*.otf   binary
-*.woff  binary
-*.woff2 binary
-
-# EXECUTABLES
-*.exe   binary
-*.pyc   binary

package/mcps/davinci-mcp-professional/.github/CODEOWNERS

@@ -1,2 +0,0 @@
-# Default code owner for the entire repository
-* @hoyt-harness

package/mcps/davinci-mcp-professional/.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,33 +0,0 @@
-name: Bug Report
-description: Report a problem or unexpected behavior
-title: "[BUG] "
-labels: [bug]
-assignees: []
-
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Please describe the issue clearly and concisely.
-  - type: input
-    id: version
-    attributes:
-      label: Software Version
-      placeholder: e.g., 2.2.1
-    validations:
-      required: true
-  - type: textarea
-    id: what-happened
-    attributes:
-      label: What happened?
-      placeholder: Describe the issue.
-    validations:
-      required: true
-  - type: textarea
-    id: steps
-    attributes:
-      label: Steps to Reproduce
-      placeholder: |
-        1. Go to '...'
-        2. Click on '...'
-        3. Observe the behavior

package/mcps/davinci-mcp-professional/.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,19 +0,0 @@
-name: Feature Request
-description: Suggest an improvement or new idea
-title: "[FEATURE] "
-labels: [enhancement]
-assignees: []
-
-body:
-  - type: textarea
-    id: what-feature
-    attributes:
-      label: What would you like to see added or changed?
-      description: Be as specific as possible.
-    validations:
-      required: true
-  - type: textarea
-    id: motivation
-    attributes:
-      label: Why would this be useful?
-      description: Explain how it improves functionality or user experience.

package/mcps/davinci-mcp-professional/.github/PULL_REQUEST_TEMPLATE.md

@@ -1,20 +0,0 @@
-## Summary
-
-Briefly explain what this PR does and why it's needed.
-
-## Type of Change
-- [ ] Bug fix
-- [ ] New feature
-- [ ] Documentation update
-- [ ] Refactor or tech debt cleanup
-- [ ] Other (please explain):
-
-## Checklist
-- [ ] I've read the CONTRIBUTING.md file
-- [ ] My changes are consistent with the project's style and goals
-- [ ] I’ve tested my changes locally
-- [ ] I’ve updated documentation as needed
-- [ ] This PR is ready for review
-
-## Related Issues
-Link to any related issues here (e.g., `Fixes #42`, `Closes #17`)

package/mcps/davinci-mcp-professional/.github/SECURITY.md

@@ -1,97 +0,0 @@
-# Security Policy
-
-## Supported Versions
-
-We actively support the following versions with security updates:
-
-| Version | Supported          | End of Support |
-| ------- | ------------------ | -------------- |
-| 2.2.x   | :white_check_mark: | TBD            |
-| 2.1.x   | :white_check_mark: | 2025-12-31     |
-| < 2.0   | :x:                | 2024-12-31     |
-
-## Reporting a Vulnerability
-
-### How to Report
-
-**For security vulnerabilities, please do NOT create a public GitHub issue.**
-
-Instead, please report security vulnerabilities through one of these methods:
-
-1. **Private Security Advisory** (Preferred): Use GitHub's private vulnerability reporting feature
-2. **Email**: Send details to `hoyt.harness@gmail.com` with subject line `[SECURITY] DaVinci MCP Professional`
-3. **PGP Encrypted Email**: If you have sensitive information, request our PGP key first
-
-### What to Include
-
-Please provide as much information as possible:
-
-- **Description**: Clear description of the vulnerability
-- **Steps to Reproduce**: Detailed steps to reproduce the issue
-- **Impact Assessment**: Your assessment of the potential impact
-- **Affected Versions**: Which versions are affected
-- **Proof of Concept**: Code or screenshots demonstrating the issue (if applicable)
-- **Suggested Fix**: Any recommendations for fixing the vulnerability (optional)
-
-### Response Timeline
-
-We are committed to responding to security reports promptly:
-
-- **Initial Response**: Within 48-72 hours
-- **Triage Assessment**: Within 5 business days
-- **Fix Development**: Varies by severity (see below)
-- **Public Disclosure**: Coordinated with reporter, typically 30-90 days after fix
-
-### Severity Levels
-
-| Severity | Response Time | Examples |
-|----------|---------------|----------|
-| **Critical** | 24-48 hours | Remote code execution, authentication bypass |
-| **High** | 3-5 days | Privilege escalation, significant data exposure |
-| **Medium** | 7-14 days | Cross-site scripting, information disclosure |
-| **Low** | 30 days | Minor information leaks, non-exploitable issues |
-
-### Security Best Practices
-
-When using DaVinci MCP Professional:
-
-- **Keep Updated**: Always use the latest version
-- **Secure Environment**: Run in isolated environments when possible
-- **Access Control**: Limit access to DaVinci Resolve API credentials
-- **Monitor Logs**: Regularly review application logs for anomalies
-- **Network Security**: Use encrypted connections when available
-
-### Security Features
-
-Current security measures in place:
-
-- **Dependency Scanning**: Automated dependency vulnerability scanning
-- **Static Analysis**: Code quality and security analysis
-- **Input Validation**: Comprehensive input sanitization
-- **Error Handling**: Secure error messages that don't leak sensitive information
-- **Audit Logging**: Activity logging for forensic analysis
-
-### Hall of Fame
-
-We appreciate security researchers who help make our project safer:
-
-- [Your name could be here!]
-
-### Legal
-
-This security policy applies to the DaVinci MCP Professional project. By participating in our security program, you agree to:
-
-- Make a good faith effort to avoid privacy violations and service disruption
-- Only interact with systems you own or have explicit permission to test
-- Not access or modify user data without explicit permission
-- Follow responsible disclosure practices
-
-We commit to:
-
-- Respond to your report promptly and work with you to understand the issue
-- Not pursue legal action against researchers who follow this policy
-- Recognize your contribution publicly (if desired) after the issue is resolved
-
----
-
-**Contact**: For questions about this security policy, contact hoyt.harness@gmail.com

package/mcps/davinci-mcp-professional/.github/dependabot.yml

@@ -1,27 +0,0 @@
-version: 2
-updates:
-  - package-ecosystem: "pip"
-    directory: "/"
-    schedule:
-      interval: "weekly"
-      day: "monday"
-      time: "08:00"
-      timezone: "America/Chicago"
-    open-pull-requests-limit: 3
-    rebase-strategy: "auto"
-    commit-message:
-      prefix: "deps"
-      include: "scope"
-    # Security-focused configuration
-    allow:
-      - dependency-type: "security"
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "weekly"
-      day: "monday"
-      time: "08:00"
-      timezone: "America/Chicago"
-    commit-message:
-      prefix: "deps"
-      include: "scope"

package/mcps/davinci-mcp-professional/.github/workflows/ci.yml

@@ -1,39 +0,0 @@
-name: CI
-
-on:
-  push:
-    branches: [ "main" ]
-  pull_request:
-    branches: [ "main" ]
-
-permissions:
-  contents: read
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-
-    strategy:
-      matrix:
-        python-version: ['3.10', '3.11', '3.12', '3.13']
-
-    steps:
-    - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
-
-    - name: Install uv
-      uses: astral-sh/setup-uv@cec208311dfd045dd5311c1add060b2062131d57 # v8.0.0
-      with:
-        python-version: ${{ matrix.python-version }}
-
-    - name: Run CI checks
-      run: bash hooks/ci-check.sh
-
-    - name: Upload security artifacts
-      uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
-      if: always()
-      with:
-        name: security-reports-py${{ matrix.python-version }}
-        path: |
-          bandit-report.json
-          licenses.json
-        retention-days: 30

package/mcps/davinci-mcp-professional/ATTRIBUTION.md

@@ -1,4 +0,0 @@
-# Attribution
-The following are publicly claimed by Positronikal et al:
-
-- DaVinciMCP Professional

package/mcps/davinci-mcp-professional/AUTHORS.md

@@ -1,9 +0,0 @@
-# Authors
-- Hoyt Harness
-- Claude AI
-
-This project is a hard/project fork from: https://github.com/samuelgursky/davinci-resolve-mcp
-
-Local Variables:\
-coding: UTF-8\
-End: