fix: prevent excessive disk usage from repo backups

[arunavo4]

Summary

Fixes #234 — repo-backups directory growing to 17GB+ due to a backward-compatibility trap where legacy configs silently resolve to "always backup" mode.

• Fix backward-compat trap: backupBeforeSync: true (the mapper default) was silently mapping to "always" in resolveBackupStrategy, creating full git bundles on every sync. Now maps to "on-force-push" (smart backup) instead.
• Fix UI round-trip regression: Legacy backupBeforeSync: false configs were being overwritten to "on-force-push" after any auto-save. mapDbToUiConfig now correctly preserves the "disabled" state.
• Lower default retention: Reduced backupRetentionCount from 20 to 5 bundles per repo across all layers (schema, defaults, mapper, UI).
• Add time-based retention: New backupRetentionDays field (default 30 days) deletes old bundles alongside count-based retention, with a safety net to always keep at least 1 bundle.
• Expose retention days in UI: Added "Snapshot retention days" input to the backup settings form (was documented but missing from UI).
• Add UI warning: "Always Backup" option now shows "(high disk usage)" in the description.
• Update docs: FORCE_PUSH_PROTECTION.md updated with new defaults and backward-compat table.

Test plan

• All 171 tests pass (2 test assertions updated for new behavior)
• Production build succeeds
• Verified legacy backupBeforeSync: false round-trip with direct mapper repro
• Verified all 4 legacy config scenarios map correctly:
  • backupBeforeSync: false + no strategy → "disabled"
  • backupBeforeSync: true + no strategy → "on-force-push"
  • Explicit backupStrategy → preserved as-is
  • No fields at all → "on-force-push" (default)

[cloudflare-workers-and-pages]

Deploying gitea-mirror-website with    Cloudflare Pages

Latest commit:	67e085f
Status:	✅  Deploy successful!
Preview URL:	https://85fe8e95.gitea-mirror-website.pages.dev
Branch Preview URL:	https://fix-234-disk-space-backup-re.gitea-mirror-website.pages.dev

View logs

[github-actions]

🐳 Docker Image Built Successfully

Your PR image is available for testing:

Image Tag: pr-235
Full Image Path: ghcr.io/raylabshq/gitea-mirror:pr-235

Pull and Test

docker pull ghcr.io/raylabshq/gitea-mirror:pr-235
docker run -d   -p 4321:4321   -e BETTER_AUTH_SECRET=your-secret-here   -e BETTER_AUTH_URL=http://localhost:4321   --name gitea-mirror-test ghcr.io/raylabshq/gitea-mirror:pr-235

Docker Compose Testing

services:
  gitea-mirror:
    image: ghcr.io/raylabshq/gitea-mirror:pr-235
    ports:
      - "4321:4321"
    environment:
      - BETTER_AUTH_SECRET=your-secret-here
      - BETTER_AUTH_URL=http://localhost:4321
      - BETTER_AUTH_TRUSTED_ORIGINS=http://localhost:4321

💡 Note: PR images are tagged as pr-<number> and built for both linux/amd64 and linux/arm64.
Production images (latest, version tags) use the same multi-platform set.

---

📦 View in GitHub Packages

[github-actions]

🔍 Vulnerabilities of gitea-mirror:scan

📦 Image Reference gitea-mirror:scan

digest	sha256:416159814b999bec1fa112a4f01db206745af3c136e6fd7573049e9c28db5253
vulnerabilities
platform	linux/amd64
size	283 MB
packages	800

📦 Base Image debian:trixie

digest	sha256:13f29b6806e531c3ff3b565bb6eed73f2132506c8c9d41bb996065ca20fb27f2
vulnerabilities

glibc 2.41-12+deb13u1 (deb) pkg:deb/debian/glibc@2.41-12%2Bdeb13u1?os_distro=trixie&os_name=debian&os_version=13 Affected range <2.41-12+deb13u2 Fixed version 2.41-12+deb13u2 EPSS Score 0.008% EPSS Percentile 1st percentile Description Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption. Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc. Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments. glibc 2.42-8 (bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125678) [trixie] - glibc 2.41-12+deb13u2 [bookworm] - glibc (Minor issue) [bullseye] - glibc (Minor issue, unlikely scenario) https://sourceware.org/bugzilla/show_bug.cgi?id=33796 https://www.openwall.com/lists/oss-security/2026/01/16/5 Introduced with: https://sourceware.org/git/?p=glibc.git;a=commit;h=9bf8e29ca136094f73f69f725f15c51facc97206 (glibc-2.30) Fixed by: https://sourceware.org/git/?p=glibc.git;a=commit;h=c9188d333717d3ceb7e3020011651f424f749f93 (glibc-2.43) Affected range <2.41-12+deb13u2 Fixed version 2.41-12+deb13u2 EPSS Score 0.019% EPSS Percentile 5th percentile Description Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver. glibc 2.42-8 (bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125748) [trixie] - glibc 2.41-12+deb13u2 [bookworm] - glibc (Minor issue) [bullseye] - glibc (Minor issue, high attack complexity) https://sourceware.org/bugzilla/show_bug.cgi?id=33802 https://www.openwall.com/lists/oss-security/2026/01/16/6 Introduced with: https://sourceware.org/git/?p=glibc.git;a=commit;h=5f0e6fc702296840d2daa39f83f6cb1e40073d58 (glibc-1.93) Fixed by: https://sourceware.org/git/?p=glibc.git;a=commit;h=e56ff82d5034ec66c6a78f517af6faa427f65b0b (glibc-2.43) Affected range <2.41-12+deb13u2 Fixed version 2.41-12+deb13u2 EPSS Score 0.053% EPSS Percentile 16th percentile Description Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process. glibc 2.42-11 (bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1126266) [trixie] - glibc 2.41-12+deb13u2 [bookworm] - glibc (Minor issue) [bullseye] - glibc (Minor issue, unlikely scenario) https://www.openwall.com/lists/oss-security/2026/01/20/3 Introduced with: https://sourceware.org/git/?p=glibc.git;a=commit;h=8f2ece695d8822e9ecc63ecd157e90bf17a6fe65 (glibc-2.0.92) Fixed by: https://sourceware.org/git/?p=glibc.git;a=commit;h=80cc58ea2de214f85b0a1d902a3b668ad2ecb302 (glibc-2.43)

fast-xml-parser 5.5.5 (npm) pkg:npm/fast-xml-parser@5.5.5 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') Affected range >=4.0.0-beta.3 <=5.5.5 Fixed version 5.5.6 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Description Summary The fix for CVE-2026-26278 added entity expansion limits (maxTotalExpansions, maxExpandedLength, maxEntityCount, maxEntitySize) to prevent XML entity expansion Denial of Service. However, these limits are only enforced for DOCTYPE-defined entities. Numeric character references (&#NNN; and &#xHH;) and standard XML entities (&lt;, &gt;, etc.) are processed through a separate code path that does NOT enforce any expansion limits. An attacker can use massive numbers of numeric entity references to completely bypass all configured limits, causing excessive memory allocation and CPU consumption. Affected Versions fast-xml-parser v5.x through v5.5.3 (and likely v5.5.5 on npm) Root Cause In src/xmlparser/OrderedObjParser.js, the replaceEntitiesValue() function has two separate entity replacement loops: Lines 638-670: DOCTYPE entities — expansion counting with entityExpansionCount and currentExpandedLength tracking. This was the CVE-2026-26278 fix. Lines 674-677: lastEntities loop — replaces standard entities including num_dec (/&#([0-9]{1,7});/g) and num_hex (/&#x([0-9a-fA-F]{1,6});/g). This loop has NO expansion counting at all. The numeric entity regex replacements at lines 97-98 are part of lastEntities and go through the uncounted loop, completely bypassing the CVE-2026-26278 fix. Proof of Concept const { XMLParser } = require('fast-xml-parser'); // Even with strict explicit limits, numeric entities bypass them const parser = new XMLParser({ processEntities: { enabled: true, maxTotalExpansions: 10, maxExpandedLength: 100, maxEntityCount: 1, maxEntitySize: 10 } }); // 100K numeric entity references — should be blocked by maxTotalExpansions=10 const xml = `<root>${'&#65;'.repeat(100000)}</root>`; const result = parser.parse(xml); // Output: 500,000 chars — bypasses maxExpandedLength=100 completely console.log('Output length:', result.root.length); // 500000 console.log('Expected max:', 100); // limit was 100 Results: 100K &#65; references → 500,000 char output (5x default maxExpandedLength of 100,000) 1M references → 5,000,000 char output, ~147MB memory consumed Even with maxTotalExpansions=10 and maxExpandedLength=100, 10K references produce 50,000 chars Hex entities (&#x41;) exhibit the same bypass Impact Denial of Service — An attacker who can provide XML input to applications using fast-xml-parser can cause: Excessive memory allocation (147MB+ for 1M entity references) CPU consumption during regex replacement Potential process crash via OOM This is particularly dangerous because the application developer may have explicitly configured strict entity expansion limits believing they are protected, while numeric entities silently bypass all of them. Suggested Fix Apply the same entityExpansionCount and currentExpandedLength tracking to the lastEntities loop (lines 674-677) and the HTML entities loop (lines 680-686), similar to how DOCTYPE entities are tracked at lines 638-670. Workaround Set htmlEntities:false

[github-actions]

Recommended fixes for local gitea-mirror:scan

Base image is debian:trixie

Name	trixie
Digest	sha256:13f29b6806e531c3ff3b565bb6eed73f2132506c8c9d41bb996065ca20fb27f2
Vulnerabilities
Pushed	3 weeks ago
Size	49 MB
Packages	111

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

✅ There are no tag recommendations at this time.

[github-actions]

Overview

Image reference	ghcr.io/raylabshq/gitea-mirror:latest	gitea-mirror:scan
- digest	2aa51a15990b	416159814b99
- tag	latest	scan
- provenance	67e085f	oven-sh/bun@30e609e
- vulnerabilities
- platform	linux/amd64	linux/amd64
- size	245 MB	283 MB (+38 MB)
- packages	800	800
Base Image	debian:trixie	debian:trixie
- vulnerabilities

Labels (8 changes)

• ± 8 changed

-org.opencontainers.image.created=2026-03-18T09:27:42.378Z
+org.opencontainers.image.created=2026-02-26T07:10:54.054Z
-org.opencontainers.image.description=Gitea Mirror auto-syncs GitHub repos to your self-hosted Gitea/Forgejo, with a sleek Web UI and easy Docker deployment.
+org.opencontainers.image.description=Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
-org.opencontainers.image.licenses=AGPL-3.0
+org.opencontainers.image.licenses=NOASSERTION
-org.opencontainers.image.revision=67e085f6c0729a6d3abcabe28425d06de73363c7
+org.opencontainers.image.revision=30e609e08073cf7114bfb278506962a5b19d0677
-org.opencontainers.image.source=https://github.com/RayLabsHQ/gitea-mirror
+org.opencontainers.image.source=https://github.com/oven-sh/bun
-org.opencontainers.image.title=gitea-mirror
+org.opencontainers.image.title=bun
-org.opencontainers.image.url=https://github.com/RayLabsHQ/gitea-mirror
+org.opencontainers.image.url=https://github.com/oven-sh/bun
-org.opencontainers.image.version=pr-235
+org.opencontainers.image.version=1.3.10-debian