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

Feedback Feature Requests
1

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.

2

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
3

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
4

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.

5

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:

6

@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.

3 Likes
7

I agree that this is a bad approach since it’s not made clear to the user where the data is. Anyway, this is a common issue, even Web browsers don’t encrypt anything by default.

Sadly it’s assumed you cares for the security of your storage.

In general full-disk encryption is a thing and it should be more common.

In case you still want to encrypt specific folders, there are tools that can restore folders in their path automatically when decrypting it.

For example, KDE Plasma ships with an integrated tool called Plasma Vault that let you encrypt and decrypt any folder (including .logseq for example) and it’s so well integrated with the system that when you switch to a so called “Activity” (for example from work to personal) it can automatically decrypt some folders and place them at the correct location, eventually asking a password and encrypt them back in certain conditions like suspending.

8

Also why not simply replace .logseq with a link that points to a folder in a VeraCrypt drive?

2 Likes
9

Also why not simply replace .logseq with a link that points to a folder in a VeraCrypt drive?

Hey, that’s a great idea! I don’t know why I didn’t think of that before!
I just did that and it worked like a charm. Thanks for the suggestion!

1 Like
10

I can only think of two niche use case where encrypting specific folders makes sense:

  • for whatever reason you can’t enable full-disk encryption on your PC.
  • you can but you want certain folders to stay encrypted for example while you are away from keyboard but the PC is switched on (as an additional layer of security to lockscreen).

Instead using encrypted folders/drivers on machines you don’t control doesn’t seem secure at all to me, because you will have to type a password and you can’t know if there is a keylogger hidden somewhere. This is why two-factors authentication exist for services but I’m not aware of an equivalent security measure for encrypted folders/drivers.

My conclusions so far: you must be in control of the machine and its OS because otherwise there is nothing an application can do to use encrypted storage securely. So, at this point the OS should provide the tools for the two use cases above. And to me an application like Logseq providing on-disk encrypted graphs sound like a false sense of security.

11

I will tell you about my use case.

I spend many hours a day working on my company’s laptop and they have software installed on the computer that does frequent backups of the disk.

I have a Logseq graph for work, which is fine to leave in plain text but I also want sometimes to open my personal Logseq graph when I am at work. And for my personal graph, I don’t want the contents to be visible in plain text as part of the computer’s backup.

So I encrypt them using Mac’s disk utility which creates an encrypted image that gets mounted similarly to an external disk when I open it with my password.

It is not a computer with malicious software, but rather a computer with a backup software that my company has access to and I just don’t want my personal Logseq to be in that backup in plain text for privacy reasons.

1 Like
12

Isn’t this more of a workaround to an inconvenience than a security measure? Wouldn’t plugging-in a USB drive be an even better workaround since your data won’t be trasfered at all through the network (I presume)?

13

First, even if I used a USB drive, I would still be surprised to find out that my graph is being written in plain text on the computer running Logseq (in ~/.logseq/graphs). I would have expected my data not to leave my USB drive. That’s quite an unexpected privacy issue.

And second, I can’t do that because my work lap top won’t allow external USB devices to be connected :sweat_smile:

1 Like
14

Indeed as I said in my first reply all software should make clear what it does and here Logseq is misleading users in believing their data is in the graph folder only.

To be clear I’m in favour of keeping everything in one folder if possible. I was arguing about encryption and the poor situation of desktop computing in general.

1 Like
15

I have a solution that I used with joplin before.
It’s sketchy and not bulletproof but works for what you want.

note: I made it in Linux, I think it can be replicated in windows.
but you need someone who knows how to write batch scripts.

first you move all the ~/.logseq folder to your encrypted drive.
then write a simple bash script in your drive that does this:
1- move the .logseq folder folder from the encrypted drive to ~
2- open logseq appimage.
3- move the ~/.logseq folder from ~ to the encrypted drive.

since bash holds for every process, as long as your have logseq open it won’t move the folder back,
once you finish and close logseq it will move the folder back and you can unmount the encrypted drive.

Every time you need to open logseq:
1- mount the encrypted drive.
2- click on the bash script.
3- use logseq as long as you want.
4- close it when done and the script takes care of the rest.

16

I tried using symlink Junction on Windows as a workaround to put .logseq under a secure vault and it worked fine. The symlink seemed to have survived multiple mounting and un-mounting of the secure vault without problems.

As a minimum, better documentation of where plain text data resides would be super helpful here. I, too, was very surprised when I found out all my data was leaked in plain text outside of my graph folder.

1 Like
17

This might be a naive question from someone who hasn’t tried full disc encryption, but if the full disc is encrypted, wouldn’t all applications on the computer see only the un-encrypted data once the disc unlocks and OS starts up? If so, wouldn’t I need to encrypt the data again if I want to sync a particular folder up to a cloud service for backup or storage (i.e. I don’t want to put clear text onto my storage cloud)?
That’s my use case for having specific encrypted folders. Also, for performance reasons, I only want to use encryption for a fraction of the (sensitive) data on my computer that I want to back up.

18

Yes, you definitely need to encrypt that data, because the application uploading it on the Internet is not aware of it being stored encrypted on the hard drive: it’s the OS (or a dedicated app like VeraCrypt) that cares of encrypting/decrypting and present the data unencrypted to applications for their convenience.

You can think of your hard drive as a drawer and encryption as a padlock. When you read/write documents you take them from the unlocked drawer, you put them on the table (the RAM) and treat them as unencrypted. So if you want to send a document securely over a network, you need to seal the letter with encryption.

19

You Sir are a genius! I now use the dir structure:

…\Logseq
…\Logseq\.logseq
…\Logseq\ProductionGraph
…\Logseq\SandboxGraph
…\Logseq\.git

I now symlink …\Logseq\.logseq to where the GUI expects it and make \Logseq a git repo to back EVERTHING up in one place.

As a recent loqseq user, I’m simply blown away by its capabilities! The only irritation has been the claim that “everything in one folder” is misleading and that you need the master .logseq folder to actually archive state. I wish each graph folder just had its own unified .logseq folder so backup would just be a folder thing.

2 Likes
20

Discussion of this topic often confuses two different issues and implicitly concludes that VeraCrypt, Cryptomator and such solve the same problem than proper app in-rest encryption would have solved, except for some slightly annoying extra setup. But that’s not the case, you have to mount, attach, etc. (each tool has its term) the encrypted store in order to make it available to the target app, but in that step you also expose it to many other apps, plugins, addons, etc. running in your system. And there is no such thing as a secure system, folder access control is pretty much non existent in all major desktop OSs, plugins in powerful apps like Code, Logseq, Obsidian come from uncontrolled third party ecosystems that one has to assume operate in good faith and which in turn depend on even larger open ecosystems like Node, frequent updates increase the risk of getting a rogue version, etc. So it’s no small loss that the team has dropped inbuilt support for in-rest encryption, that’s not the kind of thing about which you may say well it’s for the better, keep the core lean and let plugins cope with the rest (in fact, the attitude of letting plugins fill every little hole makes the security problem much worse, at least Logseq is pretty functional without plugins). Now, you may say, let’s the guys make some money by selling in-rest + e2e encryption. Well, that’s understandable at least, but you aren’t getting that with some ingenious tricks, you need to fork and actually implement it at the app layer.