Skip to content

Append an encrypted file #199

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

Closed
Falco20019 opened this issue Jan 18, 2021 · 1 comment
Closed

Append an encrypted file #199

Falco20019 opened this issue Jan 18, 2021 · 1 comment

Comments

@Falco20019
Copy link
Contributor

Falco20019 commented Jan 18, 2021

Right now, we use the FileLifecycleHooks to encrypt our logging. This works great, as long as we don’t try to append to this file after it was closed (due to the final Block with padding). Sadly, the stream of FileSink is opened only for Write with FileShare.Read. Due to our configuration, this is additionally wrapped in WriteCountingStream. The FileStream itself would be seekable (CanSeek is also true on WriteCountingStream, but the Seek method was overwritten to throw an exception which feels misleading).

After seeing #189, I wanted to open the file for reading, extract the last two blocks, encrypt the last one with the second to last as IV, reset the cursor using Seek by one block and afterwards rewrite the last block without padding to the given stream, keeping the stream open for all further operations. This only works, when WriteCountingStream is out of the game.

The alternative would be to have the stream opened with ReadWrite permission. In this case, we would still need the WriteCountingStream to allow seeking (for overwriting the last block), but don’t need a second stream on the same file.

The best option for me would be to have a pre-hook to just being called before the file is opened (so that I can open the file with any permission needed and prepare it). This way, I could get the IV and the last block or even remove the last block already. When the file is opened, I could wrap the stream opened by the sink and write the last block. This way, I don’t even need WriteCountingStream to be seekable.

But as it is now, it‘s hard to append to encrypted files. So to circumvent the files getting corrupted, we throw an IOException if the underlying stream is not empty to force-start a new file on the RollingFileSink. I also found no other workaround to enforce the start of the next file.

Maybe I am just missing something. So if anyone has already done encryption on the logging, just let me know! Every help is appreciated.

@nblumhardt
Copy link
Member

Hi! We're triaging issues in this tracker and the current one appears to be stale. If your issue relates to a usage question, asking on Stack Overflow and posting a link here will get the most eyes on it (only a small number of maintainers actively track this repository). If your issue relates to a possible bug that still needs attention, please feel free to comment/request reopening. Thanks!

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

2 participants