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/icsharpcode/SharpZipLib 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.

GO — Healthy across all four use cases

• 15 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits

_{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 icsharpcode/SharpZipLib repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/icsharpcode/SharpZipLib.

What it runs against: a local clone of icsharpcode/SharpZipLib — 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 icsharpcode/SharpZipLib | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 643 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of icsharpcode/SharpZipLib. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/icsharpcode/SharpZipLib.git
#   cd SharpZipLib
#
# 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 icsharpcode/SharpZipLib and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "src/ICSharpCode.SharpZipLib/Zip/ZipFile.cs" \\
  && ok "src/ICSharpCode.SharpZipLib/Zip/ZipFile.cs" \\
  || miss "missing critical file: src/ICSharpCode.SharpZipLib/Zip/ZipFile.cs"
test -f "src/ICSharpCode.SharpZipLib/Zip/ZipInputStream.cs" \\
  && ok "src/ICSharpCode.SharpZipLib/Zip/ZipInputStream.cs" \\
  || miss "missing critical file: src/ICSharpCode.SharpZipLib/Zip/ZipInputStream.cs"
test -f "src/ICSharpCode.SharpZipLib/Zip/ZipOutputStream.cs" \\
  && ok "src/ICSharpCode.SharpZipLib/Zip/ZipOutputStream.cs" \\
  || miss "missing critical file: src/ICSharpCode.SharpZipLib/Zip/ZipOutputStream.cs"
test -f "src/ICSharpCode.SharpZipLib/Deflate/Deflater.cs" \\
  && ok "src/ICSharpCode.SharpZipLib/Deflate/Deflater.cs" \\
  || miss "missing critical file: src/ICSharpCode.SharpZipLib/Deflate/Deflater.cs"
test -f "src/ICSharpCode.SharpZipLib/BZip2/BZip2InputStream.cs" \\
  && ok "src/ICSharpCode.SharpZipLib/BZip2/BZip2InputStream.cs" \\
  || miss "missing critical file: src/ICSharpCode.SharpZipLib/BZip2/BZip2InputStream.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 643 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~613d)"
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/icsharpcode/SharpZipLib"
  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).

SharpZipLib is a pure C# compression library implementing Zip (with PKZIP 2.0 and AES encryption), GZip, BZip2, Tar (with GNU long filename extensions), and raw deflate/inflate codecs—originally ported from GNU Classpath's java.util.zip. It provides both high-level APIs (ZipFile, GZipInputStream) and low-level streaming compression primitives without requiring native DLL dependencies. Monolithic solution (ICSharpCode.SharpZipLib.sln) with namespace-organized modules: src/ICSharpCode.SharpZipLib/BZip2, Checksum, Core, Encryption, GZip, Lzw, Tar, Zip directories each contain format-specific implementations. Tests in a sibling test/ folder (standard .NET layout). Benchmark suite in benchmark/ICSharpCode.SharpZipLib.Benchmark/ for performance-critical paths (compression streams, checksums). Assets including strongname key (assets/ICSharpCode.SharpZipLib.snk) for GAC installation.

.NET developers (C#, VB.NET, F#) building applications that need to read/write compressed archives (ZIP, TAR, GZIP, BZIP2) without P/Invoke or external native libraries. Common use cases: backup tools, asset bundling, cross-platform file distribution, embedded systems requiring pure-managed compression.

Production-ready and actively maintained. The project has transitioned to MIT licensing (issue #103), maintains CI/CD pipelines (GitHub Actions in .github/workflows/), includes benchmarking suites (benchmark/ directory), and spans 1.2M+ lines of C#. Recent activity visible in automated workflows (build-test.yml, codeql-analysis.yml, release.yml), indicating ongoing security and release management.

Low technical risk: pure C# implementation eliminates native dependency issues. However, licensing history (transitioned from GPL 2.0 to MIT around issue #103) means older versions may carry compliance concerns. No evidence of single-maintainer risk from file structure, but check GitHub issue/PR velocity to confirm maintenance cadence. Deflate64 is explicitly unsupported (per README), so large ZIP64 archives with that compression are out of scope.

Active CI/CD: build-test.yml runs on commits, release.yml automates NuGet publishing, codeql-analysis.yml enforces security scanning. No specific milestone or PR data visible in file list, but the presence of structured issue templates (bug.yml, feature_request.yml, CONTRIBUTING.md) and PR template (.github/PULL_REQUEST_TEMPLATE.md) indicates organized development workflow. Recent docs/ structure (FILEFMTS_* markdown files) suggests ongoing format documentation.

git clone https://github.com/icsharpcode/SharpZipLib.git
cd SharpZipLib
dotnet build ICSharpCode.SharpZipLib.sln
dotnet test  # if test project exists in solution

Daily commands: This is a library, not an application. Build it: dotnet build ICSharpCode.SharpZipLib.sln. Run benchmarks: dotnet run --project benchmark/ICSharpCode.SharpZipLib.Benchmark/ICSharpCode.SharpZipLib.Benchmark.csproj. Reference the built DLL in consumer projects or install via NuGet: dotnet add package SharpZipLib.

• src/ICSharpCode.SharpZipLib/Zip/ZipFile.cs — Core Zip file handling class—entry point for reading/writing ZIP archives; all contributors must understand its API and state management.
• src/ICSharpCode.SharpZipLib/Zip/ZipInputStream.cs — Streaming reader for ZIP entries; critical for understanding how compressed data is extracted and decompressed on-the-fly.
• src/ICSharpCode.SharpZipLib/Zip/ZipOutputStream.cs — Streaming writer for creating ZIP archives; essential for understanding entry compression, storage modes, and data flow during archive creation.
• src/ICSharpCode.SharpZipLib/Deflate/Deflater.cs — Deflate compression engine shared across Zip, GZip, and Zlib formats; understand this to modify compression behavior or fix algorithm bugs.
• src/ICSharpCode.SharpZipLib/BZip2/BZip2InputStream.cs — BZip2 decompression implementation; critical for understanding format-specific decompression and error handling patterns.
• ICSharpCode.SharpZipLib.sln — Main solution file defining all projects and dependencies; necessary for building and understanding project structure.
• .github/workflows/build-test.yml — CI/CD pipeline; shows how the codebase is built, tested, and validated across platforms before release.

Add Support for a New Compression Format

1. Create a new folder under src/ICSharpCode.SharpZipLib/{FormatName}/ mirroring the structure of BZip2 or GZip (src/ICSharpCode.SharpZipLib/)
2. Implement {Format}InputStream.cs by inheriting from an appropriate base stream and implementing decompression logic (src/ICSharpCode.SharpZipLib/BZip2/BZip2InputStream.cs)
3. Implement {Format}OutputStream.cs for compression with proper header/trailer writing (src/ICSharpCode.SharpZipLib/BZip2/BZip2OutputStream.cs)
4. If format-specific checksums are needed, add a checksum class similar to BZip2Crc.cs (src/ICSharpCode.SharpZipLib/BZip2/BZip2Crc.cs)
5. Add format constants and exception types (e.g., BZip2Exception) to handle errors gracefully (src/ICSharpCode.SharpZipLib/BZip2/BZip2Constants.cs)
6. Add unit tests under the test project following the naming pattern {Format}Tests.cs (test/ICSharpCode.SharpZipLib.Tests/)
7. Update README.md and documentation in docs/help/articles/intro.md to document the new format (README.md)

Add Encryption Support to an Existing Format

1. Review existing encryption implementations to understand the pattern (PKZIP vs AES) (src/ICSharpCode.SharpZipLib/Encryption/PkzipClassic.cs)
2. Create a new encryption class in src/ICSharpCode.SharpZipLib/Encryption/{AlgorithmName}.cs (src/ICSharpCode.SharpZipLib/Encryption/)
3. Modify the format's InputStream (e.g., ZipInputStream.cs) to decrypt data when reading encrypted entries (src/ICSharpCode.SharpZipLib/Zip/ZipInputStream.cs)
4. Modify the format's OutputStream (e.g., ZipOutputStream.cs) to encrypt data when writing and set encryption flags in entry headers (src/ICSharpCode.SharpZipLib/Zip/ZipOutputStream.cs)
5. Add encryption-related properties to the entry metadata class (e.g., ZipEntry.cs) to track cipher type and key material (src/ICSharpCode.SharpZipLib/Zip/ZipEntry.cs)
6. Write comprehensive tests covering encrypted read/write cycles and password validation (test/ICSharpCode.SharpZipLib.Tests/)

Optimize Compression Performance

1. Run benchmarks using the existing benchmark project to identify bottlenecks (benchmark/ICSharpCode.SharpZipLib.Benchmark/Program.cs)
2. For deflate-based compression, profile Deflater.cs and DeflaterEngine.cs for algorithmic improvements (src/ICSharpCode.SharpZipLib/Deflate/Deflater.cs)
3. Consider buffer sizing and memory allocation in compression streams (e.g., DeflaterOutputStream.cs) (src/ICSharpCode.SharpZipLib/Deflate/DeflaterOutputStream.cs)
4. For format-specific optimizations, examine BZip2InputStream.cs or BZip2OutputStream.cs block processing (src/ICSharpCode.SharpZipLib/BZip2/BZip2InputStream.cs)
5. Add new benchmark cases to benchmark/ICSharpCode.SharpZipLib.Benchmark/ with before/after measurements (benchmark/ICSharpCode.SharpZipLib.Benchmark/Program.cs)

1. Encryption is legacy: Traditional Zip encryption (Crc32-based) is cryptographically weak; AES encryption in newer ZIP specs is supported but ensure consumers know the trade-off. 2. Zip64 vs Deflate64: Code supports Zip64 (large archives) but NOT Deflate64 compression method—files using Deflate64 will fail silently or error at decompression. 3. Stream disposal: Inflater/Deflater and *InputStream/*OutputStream require explicit Close() or using() blocks; leaks cause hung threads and memory bloat. 4. Strong-name key: assets/ICSharpCode.SharpZipLib.snk gates GAC installation; modifying the library and re-signing changes version binding in downstream apps. 5. No built-in async: All APIs are synchronous; high-throughput scenarios may block threads (mitigated by benchmarks/ but not by built-in Task/await patterns).

• DEFLATE (RFC 1951) — Core compression algorithm in Zip/GZip/Zlib; understanding LZ77 phrase matching and Huffman coding is essential to debug decompression bugs in Inflater.cs.
• CRC32 polynomial validation — Every archive format (ZIP, TAR, GZip, BZip2) uses CRC32 checksums; Crc32.cs is the bottleneck for file integrity—understanding polynomial division mod 2 helps optimize this path.
• Zip64 extensions (PK, PK records) — Enables archives >4GB and files >4GB within archives; essential for modern large-file scenarios, but Deflate64 compression method is unsupported—a common source of silent failures.
• Stream-based I/O and backpressure — SharpZipLib uses abstract InputStream/OutputStream for memory efficiency; understanding buffer fill/drain cycles and why synchronous APIs block threads is critical for high-throughput scenarios.
• PKWARE traditional encryption (ZipCrypto) vs AES-256 — Legacy PKWARE encryption in PkwareTraditional.cs is cryptographically broken (CRC32-based key derivation); modern ZIPs use AES—contributors must understand why old encrypted ZIPs are vulnerable.
• TAR ustar format and GNU long filename extensions — Tar implementation supports both POSIX ustar and GNU long names (>100 char paths); must know which variant is in use to avoid path truncation or incompatibility with other tar readers.
• Huffman tree construction and canonical code ordering — Deflater.cs builds optimal prefix-free codes; understanding canonical Huffman ordering (required by DEFLATE spec) is crucial for compression ratio tuning and correctness verification.

• dotnet/runtime — Contains System.IO.Compression (ZipArchive, DeflateStream) as built-in .NET alternative; SharpZipLib offers more fine-grained control and BZip2/Tar support.
• jzabroski/DotNetZip — Legacy .NET ZIP library (Ionic.Zip); SharpZipLib is the modern, actively-maintained successor with broader format support and MIT licensing.
• kphillips/TarLibraryDotNet — Minimal Tar-only implementation; SharpZipLib integrates Tar alongside ZIP/GZIP/BZip2 in a unified API.
• icsharpcode/SharpDevelop — Original consumer of SharpZipLib; SharpDevelop IDE (predecessor of Roslyn tooling) needed gzip/zip for project bundling and plugin distribution.
• MicroKnox/7zpy — Companion project for 7-Zip format support; developers often need both SharpZipLib + 7-Zip capabilities in .NET applications.

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 BZip2 edge cases and format compliance

The benchmark directory shows BZip2 implementations exist (benchmark/ICSharpCode.SharpZipLib.Benchmark/BZip2/BZip2InputStream.cs), but the repository lacks visible BZip2-specific unit tests. This is critical for a compression library to ensure format compliance, handle corrupted streams, and prevent regressions. New contributors can add tests for block size boundaries, checksum validation, stream concatenation, and malformed file handling.

• [ ] Create src/ICSharpCode.SharpZipLib.Tests/BZip2 directory structure (following existing test patterns)
• [ ] Add unit tests for BZip2InputStream covering: valid blocks, incomplete blocks, EOF conditions, checksum errors, and block boundary conditions
• [ ] Add unit tests for BZip2OutputStream covering: compression levels, block sizes, stream flushing, and large file handling
• [ ] Add regression tests for known BZip2 format quirks (e.g., concatenated streams, random-access block markers)
• [ ] Reference: benchmark/ICSharpCode.SharpZipLib.Benchmark/BZip2/BZip2InputStream.cs as implementation to test

Add code coverage reporting and enforcement to CI pipeline

The .github/workflows contains build-test.yml and codeql-analysis.yml, but there's no code coverage workflow. With a compression library handling security-sensitive operations (encryption, format parsing), enforcing minimum coverage thresholds prevents untested code paths in critical components. This prevents future security regressions in Zip encryption, Tar parsing, and GZip handling.

• [ ] Add Coverlet integration to benchmark/ICSharpCode.SharpZipLib.Benchmark/ICSharpCode.SharpZipLib.Benchmark.csproj (or create proper test project if missing)
• [ ] Create .github/workflows/code-coverage.yml using codecov/codecov-action with Coverlet output
• [ ] Set minimum coverage threshold to 75%+ for critical paths: Zip encryption, Tar header parsing, GZip stream handling
• [ ] Add badge to README.md linking to codecov dashboard
• [ ] Reference: .github/workflows/build-test.yml as template for workflow structure

Implement Deflate64 support (RFC 1951 extension) with integration tests

The README explicitly states 'Deflate64 is not yet supported,' but Zip64 is already supported. Adding Deflate64 is a natural next step that would enable handling modern ZIP archives that use compression method 9 (Deflate64). This requires implementing the algorithm and comprehensive tests to ensure compatibility with WinRAR/7-Zip Deflate64 files.

• [ ] Add new class src/ICSharpCode.SharpZipLib/Zip/Compression/Deflate64.cs following existing Deflate.cs pattern
• [ ] Implement 32KB+ history buffer window following RFC documentation (unlike standard deflate's 32KB limit)
• [ ] Update src/ICSharpCode.SharpZipLib/Zip/ZipInputStream.cs and ZipOutputStream.cs to recognize and use compression method 9
• [ ] Add integration tests: benchmark/ICSharpCode.SharpZipLib.Benchmark/Zip/Deflate64.cs for compression/decompression round-trips
• [ ] Add test fixtures with real Deflate64-compressed ZIP files from WinRAR and 7-Zip for compatibility verification
• [ ] Update README.md to document Deflate64 support and remove the unsupported note

• Add unit tests for BZip2 edge cases (empty files, single-byte files, max compression blocks) in a new test/BZip2Tests.cs—currently no dedicated BZip2 test file visible in the file list.
• Document the Tar implementation's GNU long filename extension handling with code examples in docs/ (currently docs/future/FILEFMTS_* are placeholders)—contributors often miss that TarEntry supports paths >100 chars.
• Implement IAsyncEnumerable support for ZipFile iteration (ZipInputStream.ReadEntryAsync()) to unblock modern async/.NET Core codebases; benchmarks/ already has streaming perf baselines to verify against.
• Add a comprehensive encryption compatibility test matrix (traditional PKWARE, WinZip AES-128, AES-256) that validates round-trip with external tools like 7-Zip—currently no visible test covering real-world encrypted ZIP interop.
• Extract Checksum algorithms (Crc32, Adler32, BZip2Crc) into a separate NuGet package (ICSharpCode.SharpZipLib.Checksum) for projects needing only checksums without compression overhead—monolith packaging wastes resources.

SharpZipLib is a well-maintained compression library with reasonable security practices, including strong naming and established vulnerability reporting channels. However, the library handles untrusted binary data (archives) which introduces inherent risks. Primary concerns are path traversal during extraction, decompression bomb attacks, and proper validation of archive headers. The cryptographic components warrant security review. The codebase lacks explicit security documentation and safe usage guidelines for consumers. Overall security posture is moderate; with enhanced input validation, decompression limits, and security documentation, this could be improved to a higher security score.

• Medium · Potential Path Traversal in Archive Extraction — src/Zip/*.cs, src/Tar/*.cs, src/BZip2/*.cs. A compression/decompression library handling Zip, Tar, GZip, and BZip2 formats may be vulnerable to path traversal attacks if filenames within archives are not properly validated. Malicious archives could contain entries with paths like '../../../etc/passwd' that extract outside the intended directory. Fix: Implement strict path validation when extracting archive entries. Validate that resolved paths remain within the intended extraction directory. Use Path.GetFullPath() and ensure it starts with the target directory. Consider using a whitelist approach for allowed path characters.
• Medium · Potential DoS via Zip Bomb / Compression Bomb — src/Zip/ZipInputStream.cs, src/BZip2/BZip2InputStream.cs, src/GZip/*. The library extracts compressed files without enforcing limits on decompressed size. Malicious archives with extremely high compression ratios (zip bombs) could cause memory exhaustion or disk space exhaustion attacks. Fix: Implement decompression size limits and quotas. Add configurable maximum decompressed size checks. Monitor extraction progress and abort if thresholds are exceeded. Document safe usage patterns in API documentation.
• Medium · Missing Input Validation on Archive Headers — src/Zip/ZipFile.cs, src/Tar/TarInputStream.cs, src/BZip2/BZip2InputStream.cs. Archive format parsers may not properly validate all header fields and metadata. Malformed or malicious headers could lead to buffer overflows, out-of-bounds reads, or other memory safety issues. Fix: Add comprehensive input validation for all archive header fields. Validate magic numbers, version fields, size fields, and checksums. Implement bounds checking on all header reads. Add fuzzing tests with malformed archives.
• Low · Encryption Implementation Review Recommended — src/Encryption/*.cs, src/Zip/ZipFile.cs. The library supports AES encryption and PKZIP 2.0 style encryption. Cryptographic implementations require careful review to ensure proper key derivation, IV handling, and padding implementations. Fix: Conduct a security audit of all cryptographic code. Ensure compliance with OWASP cryptographic storage guidelines. Use well-tested crypto libraries where possible. Document encryption algorithms and key derivation functions used. Add test vectors from official sources.
• Low · Lack of Security.md Vulnerability Disclosure Detail — SECURITY.md. The SECURITY.md file provides basic reporting instructions but lacks additional security guidance such as vulnerability scope, excluded components, or safe harbor policies that could reduce unnecessary disclosures. Fix: Expand SECURITY.md with: vulnerability scope definition, information about which versions/components are in scope, guidelines for responsible disclosure, expected response times, and any safe harbor policies. Consider establishing a bug bounty program.
• Low · No Visible Code Signing or Integrity Verification — assets/ICSharpCode.SharpZipLib.snk, Release workflows. While a strong naming key exists (assets/ICSharpCode.SharpZipLib.snk), there's no visible documentation about package signing, NuGet signature verification, or release integrity checks. Fix: Implement and document NuGet package signing. Add checksums/hashes to releases. Document the strong naming key usage. Implement binary signature verification in CI/CD. Publish security advisories for known vulnerabilities.

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.