Prepare release of version 1.3.2

Fix issues #39 and #40

configure.ac

@@ -4,7 +4,7 @@ dnl Copyright (C) 2019-2021 Ulrich Telle <[email protected]>
 dnl
 dnl This file is covered by the same licence as the entire SQLite3 Multiple Ciphers package.
 
-AC_INIT([sqlite3mc], [1.3.1], [[email protected]])
+AC_INIT([sqlite3mc], [1.3.2], [[email protected]])
 
 dnl This is the version tested with, might work with earlier ones.
 AC_PREREQ([2.69])

readme.md

@@ -6,12 +6,15 @@ In the course of time several developers had asked for a stand-alone version of
 
 In late February 2020 work started on a new implementation of a SQLite encryption extension that will be able to support SQLite 3.32.0 and later. The new approach is based on [SQLite's VFS feature](https://www.sqlite.org/vfs.html). This approach has its pros and cons. On the one hand, the code is less closely coupled with SQLite itself; on the other hand, access to SQLite's internal data structures is more complex.
 
-This project is _Work In Progress_. As of March 2021, the code base is now rather stable, however, further major code modifications and/or reorganizations may still occur.
+This project is _Work In Progress_. As of May 2021, the code base is now rather stable, however, further major code modifications and/or reorganizations may still occur.
 
 The code was mainly developed under Windows, but was tested under Linux as well. At the moment no major issues are known.
 
 ## Version history
 
+* 1.3.2 - *May 2021*
+  - Added configuration parameter `mc_legacy_wal` (issue #40)
+  - Fix issue #39: Corrupted WAL journal due to referencing the wrong codec pointer
 * 1.3.1 - *April 2021*
   - Prevent rekey in WAL journal mode
   - Fix issue in user authentication extension that prevented VACUUMing or rekeying

src/cipher_common.c

@@ -3,7 +3,7 @@
 ** Purpose:     Implementation of SQLite codecs
 ** Author:      Ulrich Telle
 ** Created:     2020-02-02
-** Copyright:   (c) 2006-2020 Ulrich Telle
+** Copyright:   (c) 2006-2021 Ulrich Telle
 ** License:     MIT
 */
 
@@ -23,9 +23,9 @@ static unsigned char padding[] =
 
 static CipherParams commonParams[] =
 {
-  { "cipher",     CODEC_TYPE, CODEC_TYPE, 1, CODEC_TYPE_MAX },
-  { "hmac_check",          1,          1, 0,              1 },
-  { "mc_legacy_wal",       0,          0, 0,              1 },
+  { "cipher",                  CODEC_TYPE,           CODEC_TYPE, 1, CODEC_TYPE_MAX },
+  { "hmac_check",                       1,                    1, 0,              1 },
+  { "mc_legacy_wal", SQLITE3MC_LEGACY_WAL, SQLITE3MC_LEGACY_WAL, 0,              1 },
   CIPHER_PARAMS_SENTINEL
 };
 

src/cipher_common.h

@@ -3,7 +3,7 @@
 ** Purpose:     Header for the ciphers of SQLite3 Multiple Ciphers
 ** Author:      Ulrich Telle
 ** Created:     2020-02-02
-** Copyright:   (c) 2006-2020 Ulrich Telle
+** Copyright:   (c) 2006-2021 Ulrich Telle
 ** License:     MIT
 */
 
@@ -240,4 +240,31 @@ SQLITE_PRIVATE void sqlite3mcCodecGetKey(sqlite3* db, int nDb, void** zKey, int*
 #define SQLITE3MC_DEBUG_HEX(DESC,BUFFER,LEN)
 #endif
 
+/*
+** If encryption was enabled and WAL journal mode was used,
+** SQLite3 Multiple Ciphers encrypted the WAL journal frames up to version 1.2.5
+** within the VFS implementation. As a consequence the WAL journal file was not
+** compatible with legacy encryption implementations (for example, System.Data.SQLite
+** or SQLCipher). Additionally, the implementation of the WAL journal encryption
+** was broken, because reading and writing of complete WAL frames was not handled
+** correctly. Usually, operating in WAL journal mode worked nevertheless, but after
+** crashes the WAL journal file could be corrupted leading to data loss.
+**
+** Version 1.3.0 introduced a new way to handle WAL journal encryption. The advantage
+** is that the WAL journal file is now compatible with legacy encryption implementations.
+** Unfortunately the new implementation is not compatible with that used up to version
+** 1.2.5. To be able to access WAL journals created by prior versions, the configuration
+** parameter 'mc_legacy_wal' was introduced. If the parameter is set to 1, then the
+** prior WAL journal encryption mode is used. The default of this parameter can be set
+** at compile time by setting the symbol SQLITE3MC_LEGACY_WAL accordingly, but the actual
+** value can also be set at runtime using the pragma or the URI parameter 'mc_legacy_wal'.
+**
+** In principle, operating generally in WAL legacy mode is possible, but it is strongly
+** recommended to use the WAL legacy mode only to recover WAL journals left behind by
+** prior versions without data loss.
+*/
+#ifndef SQLITE3MC_LEGACY_WAL
+#define SQLITE3MC_LEGACY_WAL 0
+#endif
+
 #endif

src/sqlite3mc_vfs.c

@@ -3,7 +3,7 @@
 ** Purpose:     Implementation of SQLite VFS for Multiple Ciphers
 ** Author:      Ulrich Telle
 ** Created:     2020-02-28
-** Copyright:   (c) 2020 Ulrich Telle
+** Copyright:   (c) 2020-2021 Ulrich Telle
 ** License:     MIT
 */
 
@@ -1046,7 +1046,6 @@ static int mcIoWrite(sqlite3_file* pFile, const void* buffer, int count, sqlite3
     */
   }
 #endif
-#if 1
   /*
   ** The page content is encrypted in memory in the WAL journal handler.
   ** This provides for compatibility with legacy applications using the
@@ -1056,7 +1055,6 @@ static int mcIoWrite(sqlite3_file* pFile, const void* buffer, int count, sqlite3
   {
     rc = mcWriteWal(pFile, buffer, count, offset);
   }
-#endif
   else
   {
     rc = REALFILE(pFile)->pMethods->xWrite(REALFILE(pFile), buffer, count, offset);