If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/jindrapetrik/jpexs-decompiler shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit today
• 4 active contributors
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 97% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live jindrapetrik/jpexs-decompiler repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/jindrapetrik/jpexs-decompiler.

What it runs against: a local clone of jindrapetrik/jpexs-decompiler — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in jindrapetrik/jpexs-decompiler | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of jindrapetrik/jpexs-decompiler. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/jindrapetrik/jpexs-decompiler.git
#   cd jpexs-decompiler
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of jindrapetrik/jpexs-decompiler and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "jindrapetrik/jpexs-decompiler(\\.git)?\\b" \\
  && ok "origin remote is jindrapetrik/jpexs-decompiler" \\
  || miss "origin remote is not jindrapetrik/jpexs-decompiler (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "build.xml" \\
  && ok "build.xml" \\
  || miss "missing critical file: build.xml"
test -f "buildconfig.xml" \\
  && ok "buildconfig.xml" \\
  || miss "missing critical file: buildconfig.xml"
test -f "altsigner/pom.xml" \\
  && ok "altsigner/pom.xml" \\
  || miss "missing critical file: altsigner/pom.xml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/jindrapetrik/jpexs-decompiler"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

JPEXS Free Flash Decompiler is an open-source tool that decompiles, analyzes, and edits Adobe Flash SWF files. It extracts embedded resources (images, sounds, fonts, scripts), converts SWF to editable FLA format, and allows modification of ActionScript bytecode—all with a Java-based GUI that runs cross-platform on Windows, Linux, and macOS. Maven/Ant monorepo with libsrc/FFDec_lib/ as the core decompilation engine (SWF parsing, exporting), src/ for the Swing-based GUI application, and specialized subprojects: altsigner/ for Google KMS-based JAR signing, jpacker/ for JavaScript compression, jpproxy/ for proxy functionality. Build output is a single fat JAR.

Flash game modders, reverse engineers studying legacy Flash content, security researchers analyzing Flash vulnerabilities, and archivists preserving Flash-based web applications. Contributors are typically Java developers with interest in binary format parsing and bytecode manipulation.

Production-ready and actively maintained. The project has 22MB of Java source code across a mature codebase with Ant/Maven build infrastructure, GitHub Actions CI/CD (see .github/workflows/build.yml), dual-branch strategy (master/dev), and regular releases. The dev branch receives steady commits from active contributors.

Low-to-moderate risk for a mature single-maintainer project. Risk factors: large ActionScript parsing codebase (Lex grammar in src/ suggests hand-rolled parsers that are hard to modify), dependency on deprecated Flash technology (no longer supported by Adobe), and potential for breaking changes in SWF parsing when encountering obscure Flash versions. However, the stable master branch mitigates breaking changes for production use.

Active development on the dev branch with spelling checks (GitHub Actions workflow in .github/workflows/spelling.yml), build automation, and integration with KMS signing for release artifacts. The project maintains dual CI pipelines (spelling and build) and uses git hooks (.githooks/commit-msg) for commit message standardization.

git clone https://github.com/jindrapetrik/jpexs-decompiler.git
cd jpexs-decompiler
ant run  # or: ant build for JAR output only

Ensure Java 17+ and Apache Ant are installed. Git is recommended so the build script can embed the revision number.

Daily commands:

ant run                    # Run the decompiler GUI
ant build                  # Build JAR only (output in dist/)
ant clean                  # Clean build artifacts

For subprojects: cd libsrc/FFDec_lib && ant build to build the core library separately.

• build.xml — Main build configuration using Ant; defines compilation, packaging, and distribution targets that every contributor must understand to build and release the project.
• buildconfig.xml — Build configuration parameters and module definitions; essential for understanding how the multi-module project is structured and assembled.
• altsigner/pom.xml — Maven POM for the KMS jar signer module; defines dependencies (Bouncy Castle, Google KMS) critical for cryptographic signing infrastructure.
• README.md — Project overview and setup guide; required reading for understanding the Flash decompiler's purpose, installation, and primary use cases.
• CONTRIBUTING.md — Contribution guidelines and development workflow; mandatory for all contributors to follow project conventions and pull request standards.
• .github/workflows/build.yml — CI/CD pipeline configuration; defines how the project is tested and built on every commit and release.

• Ant Build System (build.xml) (Ant, Java compiler, Checkstyle, FindBugs, NSI, DEB, DMG packaging tools) — Orchestrates compilation, packaging, quality checks, and multi-platform artifact creation for the main FFDec decompiler
  • Failure mode: Build fails with compilation errors, lint violations, or dependency resolution issues; CI/CD pipeline halts
• KMS Jar Signer (altsigner module) (Java, Google Cloud KMS API, Bouncy Castle (BC), Maven shade plugin) — Signs compiled artifacts using Google Cloud KMS; manages private key access and cryptographic operations without storing keys locally
  • Failure mode: Signing fails if GCP credentials invalid, key not found, or network unavailable; release blocks until signing succeeds
• CI/CD Pipeline (.github/workflows/build.yml) (GitHub Actions, Ant, Maven, custom spelling action) — Automates build, test, lint, and release process; publishes artifacts to Maven repo and GitHub releases on every commit
  • Failure mode: Pipeline fails if build broken, linting fails,

Add a new code quality check or linting rule

1. Define style rules in Checkstyle format (Java code conventions) (checkstyle.xml)
2. Optionally add FindBugs pattern detection for bug classes (ffdec-findbugs-config.fbp)
3. Ensure CI pipeline runs checks by verifying workflow configuration (.github/workflows/build.yml)

Add a new translation language

1. Review translation guidelines and community process (TRANSLATIONS.md)
2. Submit translated resource files following the project's i18n structure (typically in main source tree, not in file list provided)
3. Verify build includes new translation by checking build configuration (buildconfig.xml)

Build and release a signed JAR distribution

1. Configure Ant build targets for compilation and packaging (build.xml)
2. Define module-specific build settings and artifact naming (buildconfig.xml)
3. Sign the compiled JAR using the KMS jar signer (cryptographic signing) (altsigner/src/main/java/com/jpexs/kmsjarsigner/SignJar.java)
4. Verify CI/CD pipeline automatically signs and publishes artifacts (.github/workflows/build.yml)

Add a new external dependency

1. Declare Maven dependency in the relevant module POM (altsigner/pom.xml)
2. Update Ant build file to include new dependency in compilation classpath (build.xml)
3. Add dependency to exclusion/allow lists if spell-checking or security scanning required (.github/actions/spelling/expect.txt)

• Ant (build.xml) — Legacy, mature build system with fine-grained control over multi-artifact packaging (JAR, installers for Windows/Linux/macOS, nightly builds)
• Maven (altsigner/pom.xml) — Dependency management for cryptographic libraries (Bouncy Castle, Google KMS); shade plugin for creating uber-JARs with bundled dependencies
• Google Cloud KMS — Secure, cloud-based key management for signing release artifacts without storing private keys in the repository
• Java 17+ (maven.compiler.release) — Modern Java for improved security, performance, and language features; target for both desktop app and command-line tools
• GitHub Actions — Native CI/CD for automated builds, linting, spell-checking, and release publication on every commit

• Hybrid Ant + Maven build system

  • Why: Legacy Ant for the main decompiler app (FFDec) with established conventions; Maven for new cryptographic signing module (altsigner) to leverage Maven plugin ecosystem
  • Consequence: Added complexity in maintaining two build tools; requires build.xml to invoke Maven or vice versa; steep learning curve for new contributors

• Cloud-based KMS for signing instead of local keystores

  • Why: Eliminates risk of private key compromise; enforces audit logging; integrates with GCP; simplifies CI/CD in shared environments
  • Consequence: Requires GCP credentials in CI/CD environment; no offline signing capability; slightly slower signing (network latency); dependency on Google Cloud availability

• Multi-platform distribution (Windows/Linux/macOS installers)

  • Why: Maximizes user accessibility; Flash decompilation is platform-agnostic
  • Consequence: Build complexity (NSI for Windows, DEB for Linux, DMG for macOS); platform-specific testing overhead; larger artifacts

• Does not perform jar signing using local PKCS#12 keystores by default (uses Google KMS instead)
• Not a package manager or plugin ecosystem; monolithic single-application architecture
• Does not support real-time collaborative editing or cloud-based decompilation (client-side only)

Build requirements: Git must be in system PATH (or available via git command) for the build script to embed revision numbers into binaries; headless builds will fail silently if Git is missing. Maven subproject: The altsigner/ module requires Google Cloud KMS credentials (environment variables or service account JSON) to build and sign JARs; skip it with -Dmaven.skip.main=true in local dev. Ant classpath: Ant libraries in antlib/ must remain in place; moving or deleting these JARs breaks the build. Java version: Maven POM specifies maven.compiler.release=17; Java 17+ is hard requirement. No Docker required: Dockerfile exists but is optional; main development is ant-based.

• SWF File Format — JPEXS parses the binary SWF specification (Adobe's proprietary format); understanding tag-based structure, bit-packing, and symbol tables is essential to grasping the decompiler's core logic
• ActionScript Bytecode / ABC Format — The decompiler reverses ActionScript 3 bytecode (ABC—ActionScript Bytecode format) back to readable code; understanding the instruction set and stack-based VM is critical for modifying disassembly logic
• Lexical Analysis (Lex/Flex Grammar) — JPEXS uses hand-written Lex-based parsers (.lex files) for tokenizing ActionScript; understanding grammar rules is needed to extend or fix parsing bugs
• Abstract Syntax Tree (AST) — The decompiler builds ASTs from bytecode; contributors need to understand node representation and tree traversal for code generation and optimization
• Control Flow Graph (CFG) — Bytecode decompilers reconstruct control flow (loops, conditionals) from flat instruction sequences using CFG analysis; JPEXS likely uses CFG reconstruction for readable output
• Binary Format Parsing — SWF is a binary format with bit-level packing; contributors must handle endianness, compression (ZLIB/LZMA), and precise byte alignment when extending parser
• JAR Code Signing & Cryptography — The altsigner/ module uses Google Cloud KMS and Bouncy Castle for signing release JARs; understanding PKCS#7/CMS is needed for maintaining secure release pipelines

• CyberAgent/dwango-swftools — Alternative SWF manipulation toolkit for Java; useful for understanding competing approaches to SWF format handling
• claus/as3commons — ActionScript 3 reflection and introspection library; complements decompiler output for ActionScript analysis
• adobe/flash-runtime — Official Adobe Flash runtime source (archived); reference for understanding SWF spec and bytecode semantics that the decompiler reverses
• ruffle-rs/ruffle — Modern Flash emulator written in Rust; potential integration point for executing decompiled Flash content without Adobe Flash Player
• swfobject/swfobject — Legacy Flash embedding library; relevant for understanding how decompiled SWF files were deployed in the wild

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for altsigner/KmsPrivateKey.java and KmsProvider.java

The altsigner module handles critical cryptographic operations (KMS integration, JAR signing) but has no visible test files in the repository. These classes interact with Google Cloud KMS and Bouncy Castle for PKCS#7/CMS operations. Adding unit tests would catch regressions in signing logic, KMS key handling, and signature verification before release builds fail.

• [ ] Create altsigner/src/test/java/com/jpexs/kmsjarsigner/ directory structure
• [ ] Add KmsPrivateKeyTest.java with tests for key initialization, getAlgorithm(), and sign() method behavior
• [ ] Add KmsProviderTest.java with tests for engineGetKey(), engineSign(), and engineVerify() implementations
• [ ] Mock Google Cloud KMS client responses using Mockito to avoid external dependencies
• [ ] Configure maven-surefire-plugin in altsigner/pom.xml to run tests during build phase
• [ ] Verify tests run successfully: mvn test -f altsigner/pom.xml

Add GitHub Actions workflow for KMS JAR signer validation on pull requests

The .github/workflows/build.yml likely handles main decompiler builds, but there's no dedicated workflow for validating the altsigner module independently. This is critical because: (1) altsigner has external Google Cloud KMS dependencies, (2) the maven-shade-plugin configuration excludes signature files which could mask issues, (3) JAR signing regressions could break release automation. A separate workflow would catch dependency conflicts and build failures specific to the signing tool.

• [ ] Create .github/workflows/altsigner-build.yml workflow file
• [ ] Add steps to: checkout code, setup Java 17 (matching maven.compiler.release property), run mvn clean package -f altsigner/pom.xml
• [ ] Add validation step to verify the shaded JAR is created: verify file exists at altsigner/target/kms-jarsigner-1.0.jar
• [ ] Add sanity check: java -jar altsigner/target/kms-jarsigner-1.0.jar --help (or equivalent)
• [ ] Configure workflow to trigger on: pull_request paths for altsigner/** and build.properties, and on push to dev/master branches
• [ ] Document any required secrets or KMS credentials needed for optional integration tests in CONTRIBUTING.md

Document altsigner module architecture and KMS integration in CONTRIBUTING.md

CONTRIBUTING.md exists but provides no guidance for contributors working on the altsigner module. The KMS integration (Google Cloud KMS + Bouncy Castle + custom SignatureSpi) is non-trivial and lacks explanation of: (1) why custom KmsProvider/KmsPrivateKey classes are needed, (2) how the KMS key URI format works, (3) how to test locally without a real GCP project, (4) the purpose of excluding signature files in maven-shade-plugin. This creates a barrier to contributions and increases review burden.

• [ ] Add new section 'Working on altsigner module' to CONTRIBUTING.md with subsections for Setup, Architecture, and Testing
• [ ] Document the KmsProvider/KmsPrivateKey design: explain why standard JCA providers aren't sufficient for KMS-backed keys
• [ ] Add code example showing how KMS key URIs are formatted (e.g., projects//locations//keyRings//cryptoKeys//versions/*)
• [ ] Explain the maven-shade-plugin filter configuration: why META-INF/*.SF/DSA/RSA are excluded and what this means for JAR signing workflows
• [ ] Document testing strategy: mock vs. integration tests, how to run tests with GOOGLE_APPLICATION_CREDENTIALS for local KMS testing
• [ ] Add reference to KmsSha256WithRsaSignatureSpi.java and note compatibility matrix (which Java/BC versions are tested)

• Add unit tests for SWF tag parsing in libsrc/FFDec_lib/src/com/jpexs/decompiler/flash/tags/ (currently sparse test coverage for bytecode disassembly edge cases). Start by creating a test directory and writing tests for Tag.java subclasses using JUnit.
• Extract hardcoded strings from src/com/jpexs/decompiler/flash/gui/ Swing components into a resource bundle (currently English-only; add i18n framework to support TRANSLATIONS.md goals). Begin with a messages.properties file and refactor main window labels.
• Document the ActionScript bytecode instruction set in /doc or wiki (currently undocumented; source is scattered across Lex files in /src). Create a markdown table mapping opcode names to descriptions by reverse-engineering the grammar files.

• High · Outdated Bouncy Castle Dependency — altsigner/pom.xml. The pom.xml references Bouncy Castle for cryptographic operations, but the version is not fully specified in the provided snippet. Bouncy Castle versions prior to 1.70 contain known CVEs. The build.properties specifies bc.version=1.83, which is reasonable, but the actual dependency declaration appears incomplete. Fix: Ensure Bouncy Castle is updated to the latest stable version (currently 1.78+). Regularly scan dependencies using tools like OWASP Dependency-Check or Snyk to identify known vulnerabilities.
• High · Google Cloud KMS Dependency Version Mismatch — altsigner/pom.xml. The pom.xml specifies google-cloud-kms version 2.86.0, but the property google.kms.version=2.41.0 suggests version inconsistency. This could lead to transitive dependency conflicts or use of outdated libraries with known vulnerabilities. Fix: Reconcile the dependency versions. Use a single consistent version across all references. Consider using dependency management or BOM (Bill of Materials) to enforce consistency.
• Medium · Missing Maven Shade Plugin Security Configuration — altsigner/pom.xml - maven-shade-plugin configuration. The maven-shade-plugin v3.5.3 strips signature files (META-INF/*.SF, *.DSA, *.RSA) but does not verify dependency signatures before shading. This could allow malicious code injection if a transitive dependency is compromised. Fix: Implement artifact signature verification. Consider using Maven Enforcer Plugin to validate dependency checksums and signatures. Review all transitive dependencies for legitimacy.
• Medium · Incomplete POM File - Truncated Dependency Declaration — altsigner/pom.xml - Bouncy Castle dependency section. The pom.xml snippet ends abruptly with '<artififa' (appears to be 'artifactId' truncated), suggesting the file may be malformed or incompletely transmitted. This could hide additional insecure configurations. Fix: Complete and validate the entire pom.xml file. Run 'mvn validate' to ensure the POM is well-formed. Review the complete dependency declarations.
• Medium · Dockerfile Uses Latest JRE Without Pinned Version — Dockerfile - FROM statement. The Dockerfile uses 'eclipse-temurin:21-jre' without a specific patch version (e.g., 21.0.1-jre). This means rebuilding the image could pull different versions with unpatched vulnerabilities. Fix: Pin the base image to a specific version: 'eclipse-temurin:21.0.1-jre' or latest available patched version. Implement a policy to rebuild images regularly with security patches.
• Medium · Hardcoded Release Download in Dockerfile — Dockerfile - ADD statement. The Dockerfile downloads a specific release from GitHub (version 26.0.0) without verifying checksums or signatures. If the GitHub repository is compromised, malicious code could be pulled into the container. Fix: Implement checksum verification using SHA256. Consider using COPY with pre-verified artifacts instead of ADD from remote URLs. Implement container image scanning before deployment.
• Medium · Excessive Permissions in Docker Build — Dockerfile - RUN statements. The Dockerfile uses 'apt-get install -y' without specifying package versions, risking installation of compromised or incompatible packages. No non-root user is created, so the container runs as root. Fix: Pin package versions (e.g., 'libxrender1=2:0.9.10-1'). Create a non-root user to run the application. Use multi-stage builds to minimize final image size and attack surface.
• Low · Missing SBOM and Vulnerability Scanning in CI/CD — .github/workflows/. While GitHub Actions workflows are present (.github/workflows/), there is no evidence of automated dependency scanning, SBOM generation, or container image scanning in the visible configuration. Fix: Add GitHub Advanced Security features, enable Dependabot for dependency updates, and integrate Trivy or Snyk for container scanning in CI/CD pipelines.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.