Howard Chu writes:
> Modified Files:
> slapd-bdb.5 1.38 -> 1.39
> Support DB encryption
When this topic was first raised, I thought it was pretty useless:
I can think of reasons to use it:
- Protecting data on the machine itself, if it gets stolen or carelessly
sold. I don't know much about how that works though, in particular
if one wants slapd to come up at reboot. Store the key physically
in a different place, on a remote filesystem?
Data even from deleted files can be extracted. OS calls to wipe files
when deleting them help, but I'm not sure if those are a guarantee
that the data can't be recovered.
- Machines and OpenLDAP are quite fast nowadays. Enough so that speed
may be less important to an admin than keeping backup routines as
simple as possible. Or having as small exceptions as possible from
site-wide practice, since DB backup needs an exception in any case.
Still, a flag which might be more useful is DB_CHKSUM, as described
in "Berkeley DB Reference Guide: Berkeley DB recoverability"
Could offer options to (a) not use it, (b) use it when the filesystem
block size differs from the DB file size, and (c) always use it.
Except, I wonder if there is a good reason why this isn't already a