Backup: сократить копирование буферов импорта и экспорта без смены формата

未关闭
  • 哪里不对？
#394 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
38/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
活跃
技术栈
csharp
领域
backend, security

调研方向

Start with SettingsViewModel.OpenBackup and BackupArchive.Decrypt, then trace the export serialization and existing tests related to #334. Check the current archive format, size limits, authentication behavior, and storage handling before changing buffer ownership. Done means preserving v1 compatibility and safe export guarantees, passing the specified boundary and failure tests, and confirming lower allocations with a repeatable isolated benchmark.

由索引模型根据 Issue 内容生成。

描述

enhancement P3 performance

Проблема

SettingsViewModel.OpenBackup загружает файл в растущий MemoryStream, затем делает ToArray(). BackupArchive.Decrypt дополнительно выделяет plaintext размером с payload. Экспорт сначала создаёт полный JSON-массив, затем отдельный массив результата. Лимит экспорта проверяется только после полной сериализации.

Измерения

Windows x64, .NET 10.0.7 Release, без tiered compilation; два прогрева, медиана семи повторов. Синтетический набор: 200 профилей с отдельными конфигурациями по 128 КиБ, JSON около 25,1 МиБ.

  • Чтение в памяти + текущая расшифровка: 100,58 мс, 164,58 МиБ аллокаций.
  • C#-прототип с заранее выделенным буфером, без ToArray() и с расшифровкой на месте: 83,93 мс, 75,47 МиБ.
  • Текущий экспорт: 83,58 мс, 113,78 МиБ.
  • Сериализация в поток с последующим шифрованием на месте: 83,41 мс, 65,84 МиБ.
  • Отказ текущего экспорта для набора с примерно 38 МиБ исходных конфигураций всё равно выделяет около 165 МиБ.

Аллокации суммарные, не пик RAM. Реальный диск, Avalonia storage providers, получение секретов и полное восстановление не измерялись. Прототипы совместимы с текущим форматом; выигрыш по времени для небольших наборов не установлен.

Решение

Оптимизировать буферы в C#, сохранив формат v1, лимит 32 МиБ, AES-GCM, PBKDF2, AAD и обработку ошибок. При достоверно известной длине заранее выделять буфер после проверки лимита; для потока неизвестной длины использовать ограниченное накопление. Исключить ToArray() перед расшифровкой, рассмотреть шифрование/расшифровку на месте в буфере с эксклюзивным владением. Ограничивать сериализацию в процессе записи, до неограниченного роста результата.

Готово, когда

  • Старые архивы читаются, новые читаются прежней реализацией; заголовок, версии и криптографические параметры совместимы.
  • Тесты проверяют неверный пароль, повреждение, усечение, точную границу размера и превышение лимита для потоков с известной и неизвестной длиной.
  • Plaintext не выдаётся вызывающему коду до успешной аутентификации и не пишется во временные файлы; принадлежащие компоненту временные секретные буферы очищаются на ошибках.
  • Сохраняются гарантии безопасного экспорта, исправленные в #334; особенности IStorageFile не обходятся предположением о локальном пути.
  • Повторяемый изолированный бенчмарк подтверждает снижение аллокаций; измерения отделены от пика RAM и дискового I/O.

Связано с #18 и #334. Смена языка, новый блочный формат, сжатие и ослабление KDF не входят в задачу. Все проверки — BYDLO_SAFE_DEV=1, фейки, без движков и изменения сети.

主要语言
C#
星标
5
派生
1
平均合并
46 分钟
30 天内合并 PR
179

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

endercodezz/BYDLO 的其他 Issue

查看 endercodezz/BYDLO 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。