Keep everything in one folder mode for use with VeraCrypt (Right now Logseq leaks all notes in plaintext regardless of graph/notes location)

NOTE: This post/feature request does not involve the Logseq Sync feature in any way! This feature request will only be of interest to a small fraction of Logseq users who want their graph encrypted on their local disk at rest.

The removal of the inbuilt local encryption feature is a good move, maintaining any encryption feature requires immense resources and opens any app to many different attack vectors. (see: Deprecation of on-disk encryption) All of the Logseq teams resources regarding encryption will be put towards the end to end sync encryption.

For anyone that requires local encryption of their notes at rest, this feature request is for you.

Putting your Logseq graph into a VeraCrypt container is the best way forward, that way you know that the code encrypting your local files is purposely designed and maintained for this purpose.

However there are currently some issues with this setup due to Logseq and require fixing.

Logseq creates a large file in ~/.logseq/graphs that contains your graph in plaintext.

For people that want to use VeraCrypt this file makes any local encryption null and void!

If your files from your VeraCrypt container are being written in plaintext to the disk in this graphs folder, you might as well not be using any encryption applications at all.

Feature Request: An option in config.edn that tells Logseq to put this graphs file in a specific folder. I suggest a .graphs folder inside your Logseq graph/notes folder to keep things simple.

This option could be:

config.edn:

:make-graph-portable? true

That way the graphs folder for the graph/notes will always be encrypted with the rest of your notes.

According to this option, any other tmp files that contain notes content, should either be disabled or moved to perhaps a .tmp folder inside your graphs/notes folder.

For anyone that uses git, ensure .graphs and .tmp are ignored.

Feature Request (expanded): Basically an option that when enabled, moves the ~/.logseq/graphs/xxxxx.transit file for your graph into a .graphs folder inside your graph/notes folder, so that everything is self-contained, and thus anyone locating their graph/notes inside a VeraCrypt container will no longer have to worry about Logseq writing all of their notes in plaintext to these various tmp locations.

oh wow, I didn’t know that, that’s shocking! This is a strong security issue.

I have been using Logseq with file encryption for a while so that I can open it on my work laptop without its backup software being able to read the files. Turns out it has been able to read this graph file the whole time. Really disappointing to be honest, not intuitive at all.

I will have to stop using Logseq until this is fixed :sob:

3 Likes

I created this issue to track this bug. I hope it gets picked up soon considering the announcement where they drop native encryption and encourage people to use other encryption options of their choice.

4 Likes

I agree… This is a deal breaker for those of us who prefer private local encryption sync’d via local processes vs. the paid “group” sync product.

I agree… This is a deal breaker for those of us who prefer private local encryption sync’d via local processes vs. the paid “group” sync product.

…well then please don’t forget to upvote this feature request :smile:

@drawingthesun I have the impression this won’t get fixed any time soon. However, I did find a workaround. Just open the ~/.logseq/graphs/x.transit file and delete its contents, then make the file read-only. Logseq won’t be able to update the contents of the file.

Logseq will still function normally, except that every time you open your graph, it will take a little bit longer to load as it will have to recompute whatever data it was storing in that .transit file.

In case you need to work with multiple graphs, you can avoid reloading your graphs by opening Logseq in multiple windows one for each graph.

I will be doing that while this issue is not fixed.

2 Likes