MokoConsulting/MokoJoomBackup
1
0
Fork 0
Code Issues 22 Pull Requests Packages Projects Releases 2 Wiki Activity

Feature: backup archive encryption (AES-256) #17

New Issue
Open
opened 2026-06-02 20:29:31 +00:00 by jmiller · 1 comment
jmiller commented 2026-06-02 20:29:31 +00:00
Owner
Copy Link
Copy Source

Encrypt backup archives for GDPR compliance and secure offsite storage.

Description

Password-protect backup archives using AES-256 encryption. Critical when storing backups in cloud storage (Google Drive, S3) that may contain PII.

Requirements

  • Optional encryption password per profile
  • AES-256 encryption of ZIP archive
  • Encrypted archives must be decryptable by standard ZIP tools (7-Zip, WinZip)
  • Kickstart restore.php must handle encrypted archives
  • Password stored securely (not in plaintext? or accept plaintext in DB?)
Encrypt backup archives for GDPR compliance and secure offsite storage. ## Description Password-protect backup archives using AES-256 encryption. Critical when storing backups in cloud storage (Google Drive, S3) that may contain PII. ## Requirements - [ ] Optional encryption password per profile - [ ] AES-256 encryption of ZIP archive - [ ] Encrypted archives must be decryptable by standard ZIP tools (7-Zip, WinZip) - [ ] Kickstart restore.php must handle encrypted archives - [ ] Password stored securely (not in plaintext? or accept plaintext in DB?)
jmiller added the type: featurepriority: mediumcomponent: enginestatus: ready labels 2026-06-02 20:29:31 +00:00
jmiller commented 2026-06-02 20:29:31 +00:00
Author
Owner
Copy Link
Copy Source

Testing Plan

TC-F4.1: Encrypted backup

  1. Set encryption password in profile
  2. Run backup
  3. Try to open ZIP without password — verify it fails
  4. Open with correct password — verify contents accessible

TC-F4.2: Restore with encryption

  1. Create encrypted backup
  2. Restore via admin UI (should prompt for password)
  3. Verify restore succeeds

TC-F4.3: Kickstart with encryption

  1. Create encrypted backup with Kickstart enabled
  2. Use restore.php on blank server
  3. Verify password prompt in Step 2 (extraction)
  4. Verify restore completes

TC-F4.4: No encryption

  1. Leave password empty
  2. Verify backup is not encrypted (normal ZIP)
## Testing Plan **TC-F4.1: Encrypted backup** 1. Set encryption password in profile 2. Run backup 3. Try to open ZIP without password — verify it fails 4. Open with correct password — verify contents accessible **TC-F4.2: Restore with encryption** 1. Create encrypted backup 2. Restore via admin UI (should prompt for password) 3. Verify restore succeeds **TC-F4.3: Kickstart with encryption** 1. Create encrypted backup with Kickstart enabled 2. Use restore.php on blank server 3. Verify password prompt in Step 2 (extraction) 4. Verify restore completes **TC-F4.4: No encryption** 1. Leave password empty 2. Verify backup is not encrypted (normal ZIP)
Sign in to join this conversation.
Labels
Clear labels
component: admin
Admin UI and views
 component: api
REST API
 component: engine
Backup/restore engine
 component: remote
Remote storage (FTP/GDrive)
 component: scheduler
Scheduled tasks
 priority: critical
Must fix before release
 priority: high
Important for release
 priority: low
Nice to have
 priority: medium
Normal priority
 status: blocked
Blocked by dependency
 status: ready
Ready for development
 type: bug
Something is broken
 type: docs
Documentation
 type: feature
New feature or enhancement
 type: testing
Testing and QA
bug
Something is not working
 chore
Maintenance and housekeeping
 documentation
Documentation improvements
 enhancement
Improvement to existing functionality
 feature
New feature or request
 pending: dependency
Blocked by another issue or external dependency
 pending: deployment
Tested and approved, awaiting deployment to production
 pending: design
Needs UI/UX or architecture design before implementation
 pending: documentation
Feature works, needs documentation/wiki update
 pending: feedback
Awaiting feedback or decision from stakeholder
 pending: review
Implementation complete, awaiting code review
 pending: testing
Feature implemented but not yet tested
 priority: critical
Must fix immediately
 priority: high
Should fix soon
 priority: low
Nice to have
 priority: medium
Fix when convenient
 refactor
Code restructuring without behavior change
 roadmap
Planned feature or enhancement tracked on the roadmap
 scope: client
Client-specific work
 scope: dolibarr
Dolibarr modules and customizations
 scope: infrastructure
Server, CI, backups, monitoring
 scope: joomla
Joomla templates and extensions
 scope: waas
MokoWaaS platform
 security
Security vulnerability or hardening
 status: blocked
Waiting on external dependency
 status: duplicate
Duplicate of another issue
 status: in-progress
Being worked on
 status: needs-review
Ready for review
 status: wontfix
Will not be addressed
No labels component: engine priority: medium status: ready type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jmiller (Jonathan Miller)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/MokoJoomBackup#17
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?