Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-1156

allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s:
    • Fix Version/s:
    • Component/s: Store
    • Labels:
    • Urgency:


      encrypted database to be re-encrypted with a new password.

      Here are some ideas for an initial implementation.

      The easiest way to do this is to make sure we have exclusive access to the
      data and that no log is required in the new copy of the db. I want to avoid
      the log as it also is encrypted. Here is my VERY high level plan:

      1) Force exclusive access by putting all the work in the low level store,
      offline boot method. We will do redo recovery as usual, but at the end
      there will be an entry point to do the copy/encrypt operation.

      copy/encrypt process:

      0) The request to encrypt/re-encrypt the db will be handled with a new set
      of url flags passed into store at boot time. The new flags will provide
      the same inputs as the current encrypt flags. So at high level the
      request will be "connect db old_encrypt_url_flags; new_encrypt_url_flags".
      TODO - provide exact new flag syntax.

      1) Open a transaction do all logged work to do the encryption. All logging
      will be done with existing encryption.

      2) Copy and encrypt every db file in the database. The target files will
      be in the data directory. There will be a new suffix to track the new
      files, similar to the current process used for handling drop table in
      a transaction consistent manner without logging the entire table to the log.
      Entire encrypted destination file is guaranteed synced to disk before
      transaction commits. I don't think this part needs to be logged.
      Files will be read from the cache using existing mechanism and written
      directly into new encrypted files (new encrypted data does not end up in
      the cache).

      3) Switch encrypted files for old files. Do this under a new log operation
      so the process can be correctly rolled back if the encrypt db operation
      transaction fails. Rollback will do file at a time switches, no reading
      of encrypted data is necessary.

      4) log a "change encryption of db" log record, but do not update
      system.properties with the change.

      5) commit transaction.

      6) update system.properties and sync changes.

      7) TODO - need someway to handle crash between steps 5 and 6.

      6) checkpoint all data, at this point guaranteed that there is no outstanding
      transaction, so after checkpoint is done there is no need for the log.

      o there probably should be something that catches a request to encrypt to
      whatever db was already encrypted with.


        1. encryptspec.html
          34 kB
          Suresh Thalamati
        2. reencrypt_1.diff
          79 kB
          Suresh Thalamati
        3. reencrypt_2.diff
          2 kB
          Suresh Thalamati
        4. reencrypt_3.diff
          33 kB
          Suresh Thalamati
        5. reencrypt_4.diff
          26 kB
          Suresh Thalamati
        6. reencrypt_5.diff
          16 kB
          Suresh Thalamati
        7. reencrypt_6.diff
          90 kB
          Suresh Thalamati
        8. reencryptspec_1.html
          37 kB
          Suresh Thalamati

        Issue Links



            • Assignee:
              tsuresh Suresh Thalamati
              mikem Mike Matrigali


              • Created:

                Issue deployment