Giters

vrtmrz / obsidian-livesync

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

generate_setupuri.ts is not using user-defined passphrase

pickaxe828 opened this issue · comments

commented

Abstract

Passphrase unable to be set using the obsidian-livesync/main/utils/flyio/generate_setupuri.ts script.
Instead, welcome is being used instead for the passphrase.
Procedures from docs/setup_own_server.md

Expected behaviour

  • Set passphrase by export passphrase=your_own_passphrase
  • Run the deno script.
  • Put the outputted URI in the LiveSync settings page, with your set passphrase
  • LiveSync settings page should connect sucessfully and bring you to another page for the rest of the settings

Actually happened

  • The passphrase became welcome no matter what you've set.
    (The problem is in this line, where it should pass the environment var passphrase instead of "welcome" into the ecrypt() function)

Reproducing procedure

  1. Follow docs/setup_own_server.md step 1 and 2
  2. Enter your own passphrase that's set by export passphrase=your_own_passphrase
  3. You can see Couldn't parse or decrypt configuration uri. in the log of LiveSync (Show log)
  4. Use the same URI, but enter "welcome" as passphrase into the LiveSync settings page
  5. You can connect sucessfully, meaning the passphrase is set to "welcome" instead of your own passphrase

Same problem

After I wrote this issue, I find this problem being mentioned in #350, with same finding in this comment

commented

Thank you for opening the issue!
This is a designed behaviour, but it is indeed confusable.

The passphrase for Valut End-to-End Encryption is different from the passphrase for the configuration URI. This is to change the E2EE passphrase and CouchDB password in the event of unexpected exposure of the configuration URI or its passphrase.

Therefore, I have planned to use a volatile one instead of welcome at first. However, after a short thought, I changed my mind; this might confuse people more. Then I came up with a simple one, but I think we have a more confusable as a result. This is the current status.

Now I have two plans.

  1. Accept the environment variable setupuri_passphrase for the Setup URI.
    A. If not supplied, welcome is used. (Current behaviour).
    B. If not supplied, a random one will be used and displayed only once. (The original design).

I would love to hear your views on whether option A or B is preferable!

commented

Tho the uri passphrase might not be as important, imho, it's always better to be secure.
I think B is a better choice, as it is more secure than a same uri passphrase for everyone who didn't set a value for it.
And B is actually quite intuitive for me 😆

commented

Thank you for your suggestion! I am so happy to implement it and make it better!
Would you mind if I ask you to check the behaviour, please?