You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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!
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 ofFileSink
is opened only forWrite
withFileShare.Read
. Due to our configuration, this is additionally wrapped inWriteCountingStream
. TheFileStream
itself would be seekable (CanSeek
is also true onWriteCountingStream
, but theSeek
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, whenWriteCountingStream
is out of the game.The alternative would be to have the stream opened with
ReadWrite
permission. In this case, we would still need theWriteCountingStream
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 theRollingFileSink
. 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.
The text was updated successfully, but these errors were encountered: