Libelektra: cache: compatibility with crypto plugins

[mpranj]

One thing that came up during development of the cache plugin was the security implications for crypto plugins.

The current implementation of cache does not know about crypto plugins, and once decrypted will happily cache the data coming from there.

@petermax2 do you have any ideas concerning this?

The default approach could of course be to not store the cache, if something comes from a crypto plugin. We would need a way of detecting that though.

[markus2330]

I think the easiest and most secure way would be to completely encrypt the cache with fcrypt. Unfortunately this is:

• maybe even slower than not using the cache
• not very user-friendly (gpg setup would be needed)

In the meantime I think we should simply give resolvers some config option to avoid caching in such situations.

[petermax2]

@petermax2 do you have any ideas concerning this?

Besides not caching confidential content, no sorry. Maybe we can mark a key or a moint-point as confidential somehow and then avoid to cache it.

[stale[bot]]

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions :sparkling_heart:

[mpranj]

@petermax2 would it be possible to add a marker within the crypto plugins (e.g. a confidential meta key) such that we can filter this? (not urgent at all)

[markus2330]

For the crypto plugin this is already the case (metadata crypto/encrypt gets added to encrypted keys). For fcrypt we could do something like this in the parentkey (or crypto/encrypt to all the keys the plugin emits).

The cache system would need to iterate over all keys and check if they have this meta data. While this might sound expensive, usually such iterations are no problem compared to other stuff going on.

[mpranj]

The cache system would need to iterate over all keys and check if they have this meta data.

Thanks for the info. Indeed, mmapstorage already iterates over everything twice so a strcmp might not be extremely expensive (but we will se that).