go/sqlite3
1
0
Fork 0
mirror of https://github.com/ncruces/go-sqlite3.git synced 2026-01-11 21:49:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

Wrap FilePersistentWAL.

Browse Source
This commit is contained in:
Nuno Cruces
2024-10-18 11:59:36 +01:00
parent d6aebe67cc
commit 89f750a6e9
5 changed files with 49 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
vfs/README.md
View File

@@ -94,4 +94,6 @@ The VFS can be customized with a few build tags:
- [`github.com/ncruces/go-sqlite3/vfs/memdb`](https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/memdb)
implements an in-memory VFS.
- [`github.com/ncruces/go-sqlite3/vfs/readervfs`](https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/readervfs)
implements a VFS for immutable databases.
implements a VFS for immutable databases.
- [`github.com/ncruces/go-sqlite3/vfs/xts`](https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/xts)
wraps a VFS to offer encryption at rest.

16
vfs/adiantum/README.md
View File

@@ -39,10 +39,12 @@ This means that an adversary who can get ahold of multiple snapshots
(e.g. backups) of a database file can learn precisely:
which blocks changed, which ones didn't, which got reverted.
This is slightly weaker than other forms of SQLite encryption
that include *some* nondeterminism; with limited nondeterminism,
an adversary can't distinguish between
blocks that actually changed, and blocks that got reverted.
This is weaker than other forms of SQLite encryption
that include *some* nondeterminism.
With limited nondeterminism, an adversary can't distinguish between
pages that actually changed, and pages that got reverted;
a `VACUUM` can fully rebuild the database file,
preventing this differential analysis.
> [!CAUTION]
> This package does not claim protect databases against tampering or forgery.
@@ -52,11 +54,11 @@ if you're keeping `"adiantum"` encrypted backups of your database,
and want to protect against forgery, you should sign your backups,
and verify signatures before restoring them.
This is slightly weaker than other forms of SQLite encryption
This is weaker than other forms of SQLite encryption
that include page-level [MACs](https://en.wikipedia.org/wiki/Message_authentication_code).
Page-level MACs can protect against forging individual pages,
but can't prevent them from being reverted to former versions of themselves.
> [!TIP]
> The [`"xts"`](../xts/README.md) package also offers encryption at rest.
> AES-XTS uses _only_ NIST and FIPS-140 approved cryptographic primitives.
> The [`"xts"`](../xts/README.md) VFS also offers encryption at rest.
> AES-XTS uses _only_ NIST and FIPS 140 approved cryptographic primitives.

13
vfs/adiantum/hbsh.go
View File

@@ -243,6 +243,19 @@ func (h *hbshFile) Overwrite() error {
return sqlite3.NOTFOUND
}
func (h *hbshFile) PersistentWAL() bool {
if f, ok := h.File.(vfs.FilePersistentWAL); ok {
return f.PersistentWAL()
}
return false
}
func (h *hbshFile) SetPersistentWAL(keepWAL bool) {
if f, ok := h.File.(vfs.FilePersistentWAL); ok {
f.SetPersistentWAL(keepWAL)
}
}
func (h *hbshFile) CommitPhaseTwo() error {
if f, ok := h.File.(vfs.FileCommitPhaseTwo); ok {
return f.CommitPhaseTwo()

17
vfs/xts/README.md
View File

@@ -14,6 +14,9 @@ to derive AES-128 keys from plain text where needed.
File contents are encrypted in 512 byte sectors, matching the
[minimum](https://sqlite.org/fileformat.html#pages) SQLite page size.
This VFS uses _only_ NIST and FIPS 140-2 approved cryptographic primitives,
which _may_ help you become FIPS compliant.
The VFS encrypts all files _except_
[super journals](https://sqlite.org/tempfiles.html#super_journal_files):
these _never_ contain database data, only filenames,
@@ -39,10 +42,12 @@ This means that an adversary who can get ahold of multiple snapshots
(e.g. backups) of a database file can learn precisely:
which sectors changed, which ones didn't, which got reverted.
This is slightly weaker than other forms of SQLite encryption
that include *some* nondeterminism; with limited nondeterminism,
an adversary can't distinguish between
sectors that actually changed, and sectors that got reverted.
This is weaker than other forms of SQLite encryption
that include *some* nondeterminism.
With limited nondeterminism, an adversary can't distinguish between
pages that actually changed, and pages that got reverted;
a `VACUUM` can fully rebuild the database file,
preventing this differential analysis.
> [!CAUTION]
> This package does not claim protect databases against tampering or forgery.
@@ -52,12 +57,12 @@ if you're keeping `"xts"` encrypted backups of your database,
and want to protect against forgery, you should sign your backups,
and verify signatures before restoring them.
This is slightly weaker than other forms of SQLite encryption
This is weaker than other forms of SQLite encryption
that include page-level [MACs](https://en.wikipedia.org/wiki/Message_authentication_code).
Page-level MACs can protect against forging individual pages,
but can't prevent them from being reverted to former versions of themselves.
> [!TIP]
> The [`"adiantum"`](../adiantum/README.md) package also offers encryption at rest.
> The [`"adiantum"`](../adiantum/README.md) VFS also offers encryption at rest.
> In general Adiantum performs significantly better,
> and as a "wide-block" cipher, _may_ offer improved security.

13
vfs/xts/xts.go
View File

@@ -240,6 +240,19 @@ func (x *xtsFile) Overwrite() error {
return sqlite3.NOTFOUND
}
func (x *xtsFile) PersistentWAL() bool {
if f, ok := x.File.(vfs.FilePersistentWAL); ok {
return f.PersistentWAL()
}
return false
}
func (x *xtsFile) SetPersistentWAL(keepWAL bool) {
if f, ok := x.File.(vfs.FilePersistentWAL); ok {
f.SetPersistentWAL(keepWAL)
}
}
func (x *xtsFile) CommitPhaseTwo() error {
if f, ok := x.File.(vfs.FileCommitPhaseTwo); ok {
return f.CommitPhaseTwo()