Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not encrypting existing files #29

Open
monicakumari opened this issue May 28, 2020 · 2 comments
Open

Not encrypting existing files #29

monicakumari opened this issue May 28, 2020 · 2 comments

Comments

@monicakumari
Copy link

Hi AFaust,
This add-on is too good and worked but its not working for existing documents.
If I apply this on a new instance to encrypt contentstore, then its working fine but If I apply the amps to the existing instance, then its not working for existing data. The new files created are encrypting but existing files are not encrypting.
Is there any way we can apply rule or something to encrypt existing files ?

Thanks.

@AFaust
Copy link
Member

AFaust commented May 28, 2020

It is correct that the addon is not encrypting existing documents - I consciously did not design an automatic encryption process because if you'd make a mistake in configuration, it would be hard to undo / reverse.
There are actually two parts to the question of encrypting existing documents: 1) encrypting the live state of a document in workspace://SpacesStore, 2) encrypting the state of any node, even in version or archive store

Variant 1) can already be dealt with by this addon. It would be possible to implement a routing store based on a selector property / aspect which is backed by the default content store and an encrypting store. Then, a batch process could apply the selector on all nodes in workspace://SpacesStore and that would copy/move the content over to the encrypted content store (provided the move/copy flag is set in configuration), encrypting existing content on the fly. If the old content is no longer reference, it would be orphaned and removed after the configured orphan protection period.

Variant 2) would be extremely invasive and potentially hard to do. This addon is not just designed to provide the encrypting content store, but also various routing stores. For old versions or archived nodes it would potentially be impossible to determine if their routing would include an encrypting content store, and if they needed to be encrypted or not.
Variant 2) can only work if you decide to globally put EVERY content in the encrypted content store, whereas the design goal of the addon was more towards using many more, granular stores instead of one global one. So that's also the main reason I have not considered this (yet).

I'll have to think about it and see if I can come up with a potential approach to deal with 2).

@sagar-nimmala
Copy link

Hi Alex,

Can you please give me a sample configuration to encrypt existing content using variant 1. Below is my present config for encryption.

simpleContentStores.enabled=true

simpleContentStores.customStores=myEncryptingStore,defaultTenantFileContentStore
simpleContentStores.rootStore=myEncryptingStore

simpleContentStores.customStore.myEncryptingStore.type=encryptingFacadeStore
simpleContentStores.customStore.myEncryptingStore.ref.backingStore=defaultTenantFileContentStore
simpleContentStores.customStore.myEncryptingStore.value.keyStorePath=classpath:keystore.jks
simpleContentStores.customStore.myEncryptingStore.value.keyStorePassword=password1234
simpleContentStores.customStore.myEncryptingStore.value.masterKeyAlias=myRsaKey
simpleContentStores.customStore.myEncryptingStore.value.masterKeyPassword=password1234
simpleContentStores.customStore.myEncryptingStore.value.masterKeyStoreId=SimpleContentStores

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants