Security issue: Logseq leaks graph's content outside of its directory.

[danilofaria]

What happened?

The issue described here is a security flaw.

One would expect that by encrypting all contents in the Logseq notes folder, the notes are safe. But in reality all notes can be read in plain text at ~/.logseq/graphs.

This is a deal breaker for many users.

Reproduce the Bug

• create a logseq graph
• encrypt folder with favorite encryption software
• check ~/.logseq/graphs and see that all contents are still there available in plain text

Expected Behavior

one would expect that after encrypting notes, they are no longer accessible to anyone without the encryption keys.

Screenshots

No response

Desktop Platform Information

No response

Mobile Platform Information

No response

Additional Context

No response

[drawingthesun]

Yep Logseq saves notes data outside of the users selected folder for their graph/notes.

I can see my notes in plaintext in the corresponding ~/.logseq/graphs/xxx.transit file.

For something like VeraCrypt to be useful, all we need is a portable option for the graph, where these files are all stored in the users graph/notes folder.

For example in config.edn:

:make-graph-portable? true

If true, the users graph folder will have one more folder: .graph rather than being in the ~/.logseq/graphs folder.

For example:

.git/
.sync/
assets/
draws/
exports/
journals/
logseq/
pages/
whiteboards/
.graph/ <-------- This is a new folder that contains the graph `.transit` file from `~/.logseq/graphs/`

This way, the graph is 100% portable and can be stored on a VeraCrypt volume securely.

Also you will want to add .graph/ to .gitignore if you use git.

The above is my guess at what a possible solution might look like.

[cnrpman]

Thanks! The solution looks good to me. I'm happy to review PR on this.

[danilofaria]

I would argue that this should not even be a configurable option, it should just be the case always.
I don't see a reason to have this plain text graph inadvertently placed separately from the other files, which trips a lot of people.

[cnrpman]

@danilofaria .transit is a cache file of the index, it's too big for file sync service to sync.

[danilofaria]

@cnrpman the file could be there and just be ignored by the sync service. I don't see any issues. Or am I missing something?

[cnrpman]

@danilofaria It's not a problem for Logseq Sync or git with .gitignore setup. But it's a big issue for common users that using general sync services like dropbox without knowledge about this.

We should keep the default setting simple and make it easy for most people. So a configurable option is more reasonable to me.

[danilofaria]

@cnrpman honestly idk if the biggest surprise is having this large file as part of the contents or having a plaintext file with all your sensitive data lying somewhere else in your computer without you knowing about it.

To me, the latter is a much bigger issue, as it goes against Logseq's philosophy of "you have control of your data".

And in any case, this file is not that big, since it is just text, and also Logseq already has a bunch of text under logseq/bak that takes a comparable amount of space.

It could be configurable, but I would argue that the default should be for it to be together with the other files.

[cnrpman]

@danilofaria
The search cache file is usually has a size of multiple times of the corresponding raw text - it's structured search index. It's totally unacceptable to be synced by default, as it's likely not be delta synced.
Any other idea of consolidating the search cache is welcome

[danilofaria]

@cnrpman I don't think it is so big that you can't put it on Dropbox or similar. But if you think so, then it is alright to do it as @drawingthesun suggested and have it configurable and by default keep it out.

Some users will be surprised to find out their notes are stored elsewhere, but at least they will have a way to configure it to keep all files together.

Do you think there's any chance this ticket will get picked up any time soon?

[cnrpman]

@danilofaria
I can give some pointers if anyone is happy to work on the code:
Basically, it's to make this path configurable:

logseq/src/electron/electron/handler.cljs

Lines 255 to 260 in bc568f6

	(defn- get-graph-path
	[graph-name]
	(when graph-name
	(let [graph-name (sanitize-graph-name graph-name)
	dir (get-graphs-dir)]
	(.join path dir (str graph-name ".transit")))))

And need to use a dummy file to replace the .transit file used here:

logseq/src/electron/electron/handler.cljs

Lines 208 to 215 in bc568f6

	(defn- get-graphs
	"Returns all graph names in the cache directory (strating with `logseq_local_`)"
	[]
	(let [dir (get-graphs-dir)]
	(->> (readdir dir)
	(remove #{dir})
	(map #(path/basename % ".transit"))
	(map graph-name->path))))

[danilofaria]

And need to use a dummy file to replace the .transit file used here:

@cnrpman would you mind explaining this bit in more detail?

[danilofaria]

@cnrpman can you also give pointers on how to define config options and how to access them in code and make the value accessible from this file you linked?

[danilofaria]

@cnrpman I found a workaround to this which was making the leaked .transit file read-only (and deleting its contents). There are some errors in the console logs, but otherwise everything seems to work great and the file remains empty. Do you think I could have any issues with this workaround?

[cnrpman]

And need to use a dummy file to replace the .transit file used here:
@cnrpman would you mind explaining this bit in more detail?

get-graphs lists all .transit files under the graph directory and count them as graphs. So a fast workaround would be creating dummy files for the portable graphs (since they have no .transit file stored in here)
For example, the portable graphs would touch empty files in name of <your graph path>.portable

can you also give pointers on how to define config options and how to access them in code and make the value accessible from this file you linked?

If you mean the global config, it's available in main process (which the file I mentioned above belongs to) https://github.com/logseq/logseq/blob/master/src/electron/electron/configs.cljs

If you mean the per-repo config helper, it is only accessible from renderer process, so IPC required to send the config to main process..

I found a workaround to this which was making the leaked .transit file read-only (and deleting its contents). There are some errors in the console logs, but otherwise everything seems to work great and the file remains empty. Do you think I could have any issues with this workaround?

Logseq would load internal DB cache from the .transit file at start.
Oudated .transit would make internal DB data outdated.
May need to re-index every time you start Logseq.

[conana]

I just came across this issue->discussion after having the same concern. Could symlinks be an option?

I already found sensitive data in the .logseq/git folders and so moved those to encrypted storage and symlinked back to them...this seems to work.

However, trying the same trick with the graphs/*.transit file doesn't work; logseq forgets about the graph that just got moved, presumably because it doesn't follow the symlink.

Any idea if a minor change would allow it to do so?

[aviladev]

My current workaround is to encrypt the contents of ~/.logseq in a separate directory (I’m using gocryptfs with SiriKali, but VeraCrypt and similar should also do), and then mount that directory to ~/.logseq

[conana]

Thanks, that worked like a charm actually to move that whole directory.

1. Closed the graph and quit logseq
2. Moved the main graph and the ~/.logseq directories to an encrypted volume
3. symlinked to that (now encrypted) .logseq directory from ~/.logseq
4. Open logseq app and reopen the graph from its new location
   No issues so far.

[goepigen]

Worked with Cryptomator. Install Cryptomator, choose a custom mount folder (I did this so the name of the folder stays the same so I can symlink to it), place the logseq vault inside the Cryptomator encrypted vault, create a .logseq folder inside this vault as well, create a symlink ln -s path-to-mount-directory/.logseq ~/.logseq. Should be good to go.