Недавно я изменил приложение iOS, чтобы включить сериализованный режим для базы данных, зашифрованной с использованием SQLCipher и незашифрованной базы данных (также SQLite). Я также поддерживаю статическое соединение sqlite3 для каждой базы данных, и каждый из них открывается один раз (просто проверяя нулевые значения) и совместно используемого на протяжении всего срока действия приложения.База данных, зашифрованная SQLCipher в приложении iOS, становится постоянно недоступной
Приложение должно иметь синхронное поведение, которое будет загружать тонну записей из удаленной базы данных через регулярные промежутки времени с использованием запроса на мыло и обновлять содержимое локальной зашифрованной базы данных. Конечно, человек, использующий приложение, может или не может обновлять или считывать из базы данных, в зависимости от того, что они делают, поэтому я внес изменения, упомянутые в предыдущем параграфе.
При проведении краткосрочных испытаний не возникает никаких проблем с тем, как все работает, и у меня еще есть какие-либо проблемы.
Однако некоторые пользователи сообщают, что они потеряли доступ к зашифрованной базе данных, и я пытаюсь понять, почему.
Мои мысли таковы: Методы, написанные другим разработчиком, объявили, что все sqlite3_stmt являются статическими (я считаю, что этот код был в проблемном выпуске). Раньше я замечал сбои, когда два потока, использующих конкретный метод, выполнялись одновременно. Один поток завершает, изменяет или заменяет sqlite3_stmt, а другой поток использует его. Авария не всегда происходит, потому что он завернул большую часть своего кода SQLite в блоках try/catch. Если это правда, что SQLite использует подготовку и завершение для реализации блокировки, может ли сиротство sqlite3_stmt, возникающее из-за их статического характера в этом контексте, привести базу данных в нерабочее состояние? Например, когда оператор получает эксклюзивную блокировку после шага, заменяется назначением в том же методе, запущенном в другом потоке?
Я понимаю, что это не обязательно означает, что база данных будет полностью неработоспособным, но, рассмотрим следующий сценарий:
В какой-то момент в течение срока службы приложения будет повторно ключ зашифрованную базу данных и ключ хранится в другой базе данных. Предположим, что он успешно переквалифицирует зашифрованную базу данных, но затем новый ключ не сохраняется в другой базе данных из-за того, что я упомянул выше. При условии, что в какой-то момент база данных не испортилась (на самом деле я не считаю, что это так), это единственное объяснение, которое я могу придумать, почему пользователь не может использовать зашифрованную базу данных после перезапуска приложения iOS, поскольку приложение будет единственным, кто будет обращаться к файлу базы данных.
Будучи тем, что я не могу воссоздать эту проблему, я могу только догадываться о том, что такое рассуждение. Какие у вас мысли? Это похоже на правдоподобный сценарий для чего-то, что случается редко? Есть ли у вас еще одна идея о чем-то взглянуть?
Что вы думаете о пятом абзаце? Кажется ли это разумным объяснением того, почему ключ не может быть сохранен в незашифрованной базе данных? – Jayko
Да, это то, что я подразумевал. Предположим, что в точке жизненного цикла приложений вы заново зашифровали базу данных. Это завершается, и теперь он зашифрован новым ключом. Однако из-за проблем, о которых вы говорили со статическими структурами sqlite3, обновление этого ключа шифрования во второй базе данных теряется. Теперь основная база данных недоступна. Трудно получить более конкретную информацию, не зная точной структуры программы, но это определенно является потенциальной проблемой. –