-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security concerns in case a bad-actor scenario happens #102
Comments
Instead of - pip install git+https://github.com/MatthieuBizien/roam-to-git.git@master
+ pip install git+https://github.com/MatthieuBizien/roam-to-git.git@8cb601bbde6a8252e9d28d3ef7343c00fad49933 This way you don't have to maintain a fork, which makes updates to the code easier. |
yes, I've considered this as well - it's a good starting point. but still, the repository is not in your control, and the commit hash, while almost impossible to create an identical one, there's still a chance, and I prefer not relying on extremely bad luck and/or heck knows what computational power in the future. plus, updating the fork isn't very hard either. but fair, the commit is already much better than the master branch. |
Hi @sarpik, I've considered that possibility, but as Roam interface may evolve without any warning, and break the current version of that repository, I've considered it's better to auto-update by default. Changing the recommended workflow may work for new users, but it will not increase the security of existing users. I think the best solution would be to limit my own rights on that repository, so my own PR would only be approved if a trusted reviewer validates them. If someone knows a good workflow/tooling for that, I can set it up. |
Hey there, thanks for the great tool!
I was concerned about the possible security issues, e.g. a bad actor could steal everyone's notes with just a single faulty commit.
The potential impact is high because the source of the backup tool is centralized (this github repo), and the default schedule to run the tool (cron schedule in the provided github workflow that almost nobody changes) is often (hourly).
Currently, the way one is recommended to setup the backup github workflow includes this step:
the problem with this is:
the main problem is that the user does not control the backup code that will be ran (it's centralized). if they're security-conscious - they might as well assume the code ran there is arbitrary, because it could be.
the work-around currently is to fork the
roam-to-git
repository and replace the source in the same.github/workflows/main.yml
:which makes you, the individual user, in control of the updates to the code (syncing from upstream becomes manual - and that's what we want, since we can now verify code changes ourselves, and that doesn't need to happen often either).
but this is what the "advanced" users are doing. Until we find a better solution - perhaps this should be the recommended, if not the only, default?
What do you think?
The text was updated successfully, but these errors were encountered: