No support for Google Drive, OneDrive or Dropbox or other cloud app?

[KirkH420]

Add Web login support for Cloud services like OneDrive and Dropbox. I saw that I could use google drive, but I am working on getting away from using google software as much as possible.

KeepPass2Android isna good example of how this is done and it allows for one cloud saved keyfile to sync multiple password managers across several devices.

[J-Jamet]

There are several reasons why cloud code is not directly integrated into KeePassDX :

• Google Drive, OneDrive and Dropbox are not free software, and KeePassDX wants to stay under GPLv3 license.
• If I start to integrate connection code directly in the application, it will integrate all the APIs of all existing clouds to not favor one more than another (can do a lot of problems).
• With KeePass in connected mode, it will be necessary to put the Internet permissions, which will open security breaches.
• It does not respect the mode of encapsulation of Android applications. The phone's file manager should be the only one to access files (even remote)
• If OneDrive and DropBox have not correctly created their applications to be compatible with the file manager and URI links of the device, it's not the fault of KeePassDX. GoogleDrive is integrated with the default file manager and works (in part, even if it has caching and synchronization problems).
• The application ~is still in beta~ and the synchronization must be created to retrieve the last partially updated data. (Edit : The data merge has been done , the management of file conflicts will be done in the FileSync application)

I've been thinking of creating another file manager application for this proprietary cloud API but I have to previously finish KeePassDX. I do not prevent anyone from using non-free services, it's only a matter of trust, but I personally trust only the servers I have.

https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync

[Riajyuu]

@J-Jamet So do you indicate that KeePass2Android and KeePassDX address different user groups?

[J-Jamet]

@Riajyuu Yes and no, not necessarily. It depends on the needs of each user. I personally created KeePass DX because the technical, functional and code requirements of other applications did not meet my expectations. So I realize this application according to my beliefs in the field of free software and using the technical choices that I learned during my studies.

[Riajyuu]

@J-Jamet OK. One more question:

With KeePass in connected mode, it will be necessary to put the Internet permissions, which will open security breaches.

Why & how? I don't think keepass database has any problem when being transferred even over HTTP. And I personally transfer that over HTTP if you have to ask, no concern involved.

[J-Jamet]

This is the principle of encapsulation. In software architecture, the software must be created to solve a single main problem. Recovering and sending files over the network has nothing to do with a password manager (In my opinion, let me explain).

To compare with other software. It's like LibreOffice, it does not connect to the internet. To share a text file with a team, we include the file in a shared folder, or we use another FTP service or the synchronization with another application. It's the same with KeePass DX.

If we start to integrate elements related to file sync by third party protocols, we will have to manage all the protocols and sync API in the main app. This means that we have to be security experts for each of the integrated elements (potentially dangerous because connected to remote servers). It's worse with closed APIs because we do not know the inner code.

Maintainability is also a big problem in this case, for each transfer protocol or integrated API, we must update the entire application and go through the validation workflow.

This is the purpose of a separate file manager application to do these actions (GDrive app, webdav app, or something else) . If your default file manager is not appropriate to your need, simply download one who do what you want. It is also possible to create a file manager connected with plugins for each synchronization protocol. (I have this project in mind but I must already release a final version of KeePass DX.)

So, KeePass DX doesn't directly manage the files but interacts with the content provider https://developer.android.com/guide/topics/providers/content-providers of a file manager application in your device (by default an app with the name "File"). By using a content provider, there is no need for internet access. The app sees the elements that it just needs, no more, no less.

If you see Google Drive during your file selection, it's an integrated file manager app and KeePass DX accesses files by the content provider of this app (with the Storage Access Framework https://developer.android.com/guide/topics/providers/document-provider ) of your file manager.

Each tool does what it needs to do, which is much better for security and interoperability. In the case of Dropbox, the dropbox app seems to not support the Storage Access Framework implementation https://github.com/Kunzisoft/KeePassDX/issues/90 used by the content provider. But it's the fault of dropbox. To alleviate this problem, as I said above, it is possible to create a separate file manager application to handle particular cases.

[cptechnik]

I had tested kpdx with nextcloud sync — not practical... The function syncing the database by opening and closing... is so necessary... essential...! I read and understand the problems, ... But today, the database should be syncable easily... I mean webdav in this case... (Or ftp or ssh) If there is a how-to to sync automatically by starting and changing database... I am interested...!

Proprietary file-access maybe like onedrive or Dropbox shouldn't be supported.

[LAGonauta]

If you install OneDrive in your Android you are able to open a KeePass DB in OneDrive, just not create a new one through the app. Not sure why.

[J-Jamet]

The function syncing the database by opening and closing... is so necessary... essential...! I read and understand the problems, ... But today, the database should be syncable easily...

For me, the problem is the event that triggers the synchronization of the file of your external manager. The synchronization of your manager should be automatic if the stream of the file used in KeePassDX is written and closed or if another specific event is recovered (a broadcast for example). In this case, what matters is not the transport protocol but only the events which indicate that a file has been modified.

[J-Jamet]

If you install OneDrive in your Android you are able to open a KeePass DB in OneDrive, just not create a new one through the app. Not sure why.

@LAGonauta Simply because this manager ignores requests to open document from Android (Intent ACTION_OPEN_DOCUMENT) because it is not implemented. (See wiki)

[pstorch]

I have successfully opened and stored a keepass database in KeePassDX via OneDrive. First I couldn't save (or save didn't upload). But after I've marked the file in the OneDrive app as "offline" and enabled synchronizing offline files via wifi + mobile then the database was uploaded after I've changed it in KeePassDX.

[pstorch]

After a while KeePassDX said the file does not exist anymore. I assume OneDrive has revoked the access. I had to open it again via FileManager and OneDrive app. But the settings got lost (Biometric unlocking and my keyfile location). Can KeePassDX remember those?

[J-Jamet]

Can KeePassDX remember those?

KeePassDX keeps URI links in memory for biometric recognition and associated settings. If the link is changed by the file manager, KeePassDX cannot link the new URI to an old one since it is simply not the same.

It's like changing the URL of a website. If you specify specific options for this website in your browser, when you change URLs, they are no longer the same options specifically specified in the previous site.

[pstorch]

@J-Jamet never mind. It doesn't happen so often.

[HaujetZhao]

I understand the author's obsession of keeping this excellent app clean. Though, I still got to say I vote for the support for standard open protocal such as ftp, webdav.

I'm a half tech guy, just between the amateur geek and normal dumb users. I can handle the sync problem using Syncthing or other tools. But, a stone is always in my throat about KeepassDX, that is I can't introduce KeepassDX to my friends.

My friends are all common people, not experts with phones or computers, they just the common people, not geeks. Common people all have troubles of forgetting passwords.

I really want to recommand them a excellently beautiful, easy to use, convinient, clean, free and secure password manager, since Keepass2Android's UI and translation is not good, KeepassDX seems to be the only one password manager good enough.

But the lethal problem of introducing KeepassDX to my friends is that: KeepassDX can't backup the database to remote storage. If, on a single chance, the user's phone got damaged, lost, their password will lost forever.

You may say, you got to backup your database, man?

Yeah, I know backup of course, but how about common folks? How much is the percentage that common people know and do the backup? It is a really low percentage! ! !

I don't think KeepassDX is only for geeks, the author also have the desire to provide a clean and pure experience to as many people as possible.

But for now, KeepassDX can't accomplish this goal: Put password in it, set once, secure for after.

The principal of keeping data safe requires at least one copy of the important data must be in a remote storage. If KeepassDX can't do that, the database for KeepassDX users are not secured properly. Even if a part of KeepassDX users backup manually using other apps, still, a big group of KeepassDX user's database are not secured.

I don't count on KeepassDX introducing Dropbox Api or GDrive Api or Onedrive Api, I don't like them either. @J-Jamet

Introducing open protocals (ftp, webdav...) do introduce the netword access permissions, but it won't contaminate the purity of KeepassDX.

On the contrary, if KeepassDX can't make a backup on a remote storage by itself, The Kee in KeepassDX is not qualified since the Keepass means keep password for users and KeepassDX can't keep the database safe following 3-2-1 backup rule.

I have a vision:

One day, KeepassDX can give each database one or more webdav/ftp address, KeepassDX will automaticlly periodly backup these databases. Normal users can just give password to KeepassDX with no more backup steps to to. Even if the phones are lost, they can easily get their latest version of database back.

By that day, I can proudly recommand KeepassDX to my fellows and tell them: you just create a database in KeepassDX and give it your webdav cloud disk backup address, you will have no worry of losing passwords forever!

I wish the vision could come true oneday, or I still got to worry if my backup program is still running everyday.

[pstorch]

@HaujetZhao at least for OneDrive I can say (as reported above) KeePassDX works good together with the OneDrive App (which you should have installed anyway when using this service).

[J-Jamet]

KeePassDX is only a file editor, what you want is a file manager that does what you say. I understand people prefer all-in-one tools, but here it would just be enough of a file manager app that connects to WebDAV and syncs correctly with KeePassDX (keeping URIs enabled)

At the moment, it's just that none of the file managers you use meet your constraints with Webdav. The solution for this is to create a new WebDAV file manager dedicated app which offers with its content provider the correct synchronization elements to KeePassDX. From a user point of view, it would be enough to simply download this app in addition to KeePassDX. I just don't have time to create it because I have a lot of other things to deal with.

If the problem is the lack of knowledge of the users, then they must be trained, with a presentation of the operation and animations that explain the concept.

I understand that a lot of people are tempted because all other file managers offer the all built-in method. But I specifically created KeePassDX to separate these elements. Today it just lacks the second good application that could work plugin-based (to add the cloud APIs that everyone wants) and in fact, there are good foundations for creating it (already existing open source apps).

[HaujetZhao]

KeePassDX is only a file editor, what you want is a file manager that does what you say. I understand people prefer all-in-one tools, but here it would just be enough of a file manager app that connects to WebDAV and syncs correctly with KeePassDX (keeping URIs enabled)

At the moment, it's just that none of the file managers you use meet your constraints with Webdav. The solution for this is to create a new WebDAV file manager dedicated app which offers with its content provider the correct synchronization elements to KeePassDX. From a user point of view, it would be enough to simply download this app in addition to KeePassDX. I just don't have time to create it because I have a lot of other things to deal with.

If the problem is the lack of knowledge of the users, then they must be trained, with a presentation of the operation and animations that explain the concept.

I understand that a lot of people are tempted because all other file managers offer the all built-in method. But I specifically created KeePassDX to separate these elements. Today it just lacks the second good application that could work plugin-based (to add the cloud APIs that everyone wants) and in fact, there are good foundations for creating it (already existing open source apps).

So I understand it now. KeepassDX is focus on editing keepass database.

I actually got another idea, which won't need the internet permission, while making KeepassDX accord with the 3-2-1 data safety rule.

When users opens KeepassDX, it opens a keepass database from a certain URI, right? The weak point is that, that single file might be damaged, lost, causing data lost. That's why we need a remote storage path. But people also don't like backup manually.

Since KeepassDX can get URI from other content provider, I think it will be no conceptual problem binding multi backup URI address to one existing local keepass database.

So, that's the basic concept: User create or open a local keepass database, which is the main database. Users can also bind single or multi backup address to the main database in KeepassDX. All the backup address are URIs provides by content providers, such as some file manager, or OneDrive app. The read and write process are applied to the main database, but KeepassDX updates all the backup URIs in certain circumstance. Since the remote storage URIs can be provided by the content provider, KeepassDX can periods create remote backup of local database.

The failure of backup process won't cause local database damage, maybe it's just the content provider is not running in the background, using a toast to alert user to check or update the backup URI is enough.

That's it, one database, multi URIs, no Internet permissions. Seems to be a perfect solution.

[pstorch]

@HaujetZhao for Backup there is already a feature request #704

[HaujetZhao]

@HaujetZhao for Backup there is already a feature request #704

Actually they are pretty not the same. The #704 means to create backup version files before saving in prevent of writing error, and it requires KeepassDX to have built-in file manager so that it can create a new backup file.

But the backup I mentioned above is more like sync (single direction sync), it doesn't require KeepassDX to create a new backup file, it just need user to provide one or more (remote) URIs and overwrite them all after saving in prevent of device lost. So this don't need KeepassDX to introduce a built-in file manager.

Without introducing a new component, the development will be way more easier.

[J-Jamet]

Without introducing a new component, the development will be way more easier.

I answered in your new issue but clearly no! The development will not be easier at all. You should not be afraid of new projects (external tool). Finding hacks to solve a problem instead of creating the correct architecture is clearly not a sustainable solution.

Here it is not just two files, they are pipelines. Concretely, KeePassDX has data streams as input and copying streams is not at all easy depending on the state of these streams.The solution you propose to link two streams coming from different URIs requires to synchronize data (same data in two steams else error), to implement buffers, to verify that the access and the metadata are the same for the two streams, and that the write access is guaranteed. In addition, you have to manage the interface to know which URIs to link, which implies new elements to manage in the internal database of the application, new user screens, etc ...

Or simply make a copy of files with an external tool. (Copying unchanging data with only one input and one output is very easy).

[J-Jamet]

I actually got another idea, which won't need the internet permission, while making KeepassDX accord with the 3-2-1 data safety rule.

In the diagram of the 3-2-1 backup rule, KeePassDX is not a storage actor, it is up to you to implement this storage part according to your needs. The easiest way is to retrieve the file stream closing event when the data has been sent to start the backup routines.

[pstorch]

@HaujetZhao

Actually they are pretty not the same. The #704 means to create backup version files before saving in prevent of writing error, and it requires KeepassDX to have built-in file manager so that it can create a new backup file.

You are right, saving the old version as backup versus saving the same version in a backup location. I mentioned it because the other ticket might be more related than this one. But I now saw you already opened a specific issue for your new idea.

[ghost]

Against this one, the idea behind KeePass was to keep your data locally on your machines and not on some corporate companies' privacy invasive server.

[alanhu-dev]

Against this one, too. Respect the dev, please keeping the faith of software development.

[xd003]

I haven't yet found a easy sync solution for desktop yet but this works great for syncing database file to google drive in my android device - https://play.google.com/store/apps/details?id=com.ttxapps.drivesync . It even has auto sync option but i have it kept it off to save battery , i just prefer to manually trigger sync with a single click affect my database file has been updated locally

[tallship]

Comprehensive, perhaps tl;dr covaerage of KeepassDX kdbx filesync solutions on Android.

This may be a bit of a long read. Take your time and do it in small chunks if need be :)

Introduction and background

@J-Jamet , first, let me say I've been revisiting this problem (matter, or particularity, perhaps) for well over a year now, and the further I travel down this proverbial rabbit hole the more confused I become. I'm inspired by the simplicity with which pass provides (pass, for UNIX - https://www.passwordstore.org, Password store for Android with OpenKeychain - both at F-Droid, and pass-winmenu for Windows - https://github.com/geluk/pass-winmenu ).

I must say that I really don't understand all of the people here being so insistent upon KeypassDX "because it's FOSS", and then turning right around and talking about monolithic silo cloud services like OneDrive, gdrive, Dropbox, Box, or iCloud (to be fair, I haven't seen those last two mentioned here).

If people are so enamored of KeypassDX because their philosophy is that it should be used because it is FOSS (a wonderful thing), then why are they interested in using the corporate cloud providers I just mentioned above at all? That's a rhetorical question, and outside the scope of this conversation, but it does bother me, and I think it should bother them too.

kdbx file sync solutions using git

So moving along... I've tried implementing the equivalent of what 'pass' does by setting up manual sync scripts on Android, Linux, and Windows where KeybassXC and KeepassDX are concerned. Basically, every time I make any change to a .kdbx on one platform I sync, and whenever I move to another platform I also sync before beginning to use the Keepass client for that machine.

I've found little joy there. I just can't seem to get it working correctly. I'll publicly share my (redacted) notes from my private git repo on one of my Gitea servers here: https://bhh.sh/61r and I've attached a QR code as well. The password for that paste is: jamet-kdbx. I think the expiration date of a year should suffice for the purposes of this issue's conversation.

Okay before I go any further, I would like to state that I think it would be really nice if you could implement some sort of *Plugin or something, for KeepassDX that could automatically facilitate synchronization through a private git repo. Such accounts with private repos are free at the following providers, if one does not wish to use a public repo (it's a kdbx file, so in theory it is secure anyway): https://Gitlab.org, https://sr.ht, https://Codeberg.org, https://Framagit.org, and others you can do a web search for (to use Tildegit you must be a member of a Tilde, which is free, all you need is to send them your ed25519 pub key). Alternatively, you can always just install git on any forward facing server on the Internet (you can use your home server and allow access through your ISP provided cable modem/router) or run your own Gitea server (which is familiar to most, because it looks and behaves pretty much just like GitHub).

If you want, Jérémy, I would be elated to assist you in performing testing or donate/dedicate server resources for such an endeavor, if you would be willing and interested in pursuing this. I believe it is an elegant solution and one that would potentially explode the userbase of KeepassDX.

kdbx file sync solutions using FOSS based hosted Cloud Sync solutions (NextCloud / Syncthing)

Next, I'd like to get back to the disdain that I expressed above for people's tendencies to use proprietary, closed source, monolithic silo cloud providers for attempting to sync (ANYTHING, really) their kdbx files. So I'll continue...

On that note, I keep wondering why no one here has even mentioned (that I've observed) NextCloud, which to me is the logical choice for a cloud sync. It's wildly popular, it's FOSS, it is easy to self-host, and it is completely cross-platform (Android, BSD, iPhone, Linux, Mac, Windows) so it works with everything.

From https://teddit.net/r/KeePass/comments/hu17rh/what_is_the_best_way_to_sync_a_keepass_database/g1vlsrh?utm_source=share&utm_medium=web2x&context=3

No, it's a sync issue. Keepass will open the database and keep it in memory. If you add a new password on another device and sync it, then the cloud provider will overwrite the original file. So far, so good.

But! If you also make a modification on your PC, then Keepass will blindly overwrite the changed file with the original from memory plus the modification and you will effectively lose the password you made on the other device.

This is potentially catastrophic, and to be certain, is something that you simply cannot explain to a non-technical user in terms that they will understand, and even if they do, they'll forgot and botch the integrity of their password stores, losing one, ten, or some other number of new passwords without ever realizing why (then they'll blame me or Keepass## if they're my customer).

I know we've emailed each other in the past about this, and I haven't actually tried using NextCloud for this because on Android, I wasn't actually sure whether I should test with the NexCloud app or where NextCloud actually puts the kdbx file in the file system itself. That's potentially two different locations from the standpoint of the user, and as it stands, doesn't look like either will make any difference in citing the Reddit thread's post above.

The decision as to how to access the kdbx file when using something like owncloud being a confusing one relates to what you said in your Wiki:

Important note: in many cloud applications, you have to select your database files from the desired cloud application and not from KeePassDX because intent actions are not managed by these third-party applications.

i.e., going into the user's information store directly for NextCloud and placing a file in there on a UNIX based machine does nothing - NextCloud doesn't even know it's there and it will not be sync'd, even though you can get to it (where NextCloud keeps all of your other files) directly though the shell (or a file manager like Thunar, etc.)

At least I think that's what your saying in the above quote from your Wiki.

Then, from that same thread is the following, from this link: https://teddit.net/r/KeePass/comments/hu17rh/what_is_the_best_way_to_sync_a_keepass_database/fykdv2y?utm_source=share&utm_medium=web2x&context=3

https://syncthing.net/downloads/

Synctrayzor if you have Windows and install the Android app. SyncThing is peer to peer so if your pc isn't on and you modify it on your Android it'll sync once you turn your Pc back on and vice versa. Just put your KeePass file in a folder than is synced and you should be good. Enable version history (eg 5) for peace of mind!

The last mention I'd like to highlight in that thread is about NextCloud here: https://teddit.net/r/KeePass/comments/hu17rh/what_is_the_best_way_to_sync_a_keepass_database/fyk9oem?utm_source=share&utm_medium=web2x&context=3

I'm doing it with Nextcloud, on android I have keepassdx installed and it works flawless!

Two people responded to that saying that it works flawlessly, and then this comment:

Sorry maybe I didn't say that much... 😕

I mean I set a folder with my keepass database and pointed my keepass2 to this exact folder and given credentials now it syncs automatically also on keepassdx

I'm not exactly sure if the person posting that last comment was referring to Windows, NextCloud, or the actual place on the Android file system that he pointed his KeepassDX client to access the kdbx file from. For that, I'll need to test. Nor can I confirm this isn't still plagued by the overwrite of the sync'd kdbx file when someone changes devices and updates their local kdbx file with a new entry (because the kdbx file is kept in memory on say, the desktop machine running KeepassXC?).

I've never used Syncthing, but it appears to be a possible solution, while the proprietary, closed source Box, Dropbox, gdrive, iCloud, and OneDrive alternatives hosted by monolithic silo providers is not (they are not FOSS).

Whereas I haven't tried out Syncthing, I've heard great great things about it for many years, but always used ownCloud instead, until NextCloud forked it and provided an in place upgrade path. I host a lot of NextCloud servers for customers, and would love to just go back to telling everyone to use KeepassDX and KeepassXC in conjunction with NextCloud, (or even more preferably, a viable, easy peasy git sync'ing solution, like 'pass' uses), but I'm not opposed to deploying Syncthing on those customer's servers just for their kdbx files if I have to, if it works.

I did come across this post too, where Syncthing is concerned. It looks promising, and I'll test this out: https://peterbabic.dev/blog/sync-keepass-passwords-between-computer-phone/

The current state of kdbx file sync capabilities for KeepassDX (My personal observations)

Here's the thing. This issue, or rather, series of related issues, has been languishing in KeepassDX's issue tracker for well over a year now, and I think that KeepassDX is The Solution that folks should be using for the safekeeping of their password stores, but the reliability and capabilities for syncing the kdbx file for use by KeepassDX is ambiguous at best, and so for the past year I've found myself reluctantly deferring to a self-hosted offering of BitWarden for my customers, while I slug it out all alone with KeepassDX on my personal Androids. BitWarden is a great solution, it's just not the one that I think is the best solution, notwithstanding the issue of reliably and especially conveniently syncing a simple kdbx file.

If you offer a roadmap toward a solid solution that supports the incorporation of FOSS (I have no interest in things like gdrive and Dropbox or OneDrive, my business model is strictly in providing self-hosted FOSS solutions to my customers), I'll throw whatever resources you need or time that you ask of me to facilitate your development toward such a solution.

But I'm not a dev. I'm a network engineer and systems administrator, so the best I think I can do to help here, aside from issuing pull requests for KeepassDX documentation is to offer my cloud infrastructure in my data centers, and my time as well in unit testing for you.

Final thoughts and the state of current FOSS based developmental support elsewhere:

For those who seek to use the proprietary, closed sourced monolithic silo solutions hosted by Google, Microsoft, etc., all I can say is, 'it's all good', but their business models are mostly incongruent with the goals and spirit of FOSS. You're not going to see any serious interest provided in support of kdbx based FOSS solutions beyond that which they already offer (unless it enables their goals of the further appropriation of your privacy and/or the ownership of your personal data.

On the other hand, core members of the NextCloud team are directly addressing these issues with providing kdbx support natively within NextCloud: https://github.com/jhass/nextcloud-keeweb

This means that a reliable method for the synchronization of kdbx data between devices that ensures there will be no corruption in the form of lost or missing entries in a kdbx file is even more imperative moving forward. Again, I personally prefer a solution involving Git, in conjunction with something like NextCloud's cloud sync functions, and the existince of this project by the NextCloud team is a pertinent reason why I prefer to see a solution for kdbx file sync as it relates to KeepassDX using NextCloud over that of Syncthing.

Well, I know that was a long read, and apologies for that, but this has been brewing for a while and I'm a real believer in KeepassDX itself, not to mention the distribution across devices in synchronization for kdbx files in general. Yes, I understand there is Keepass2Android which people say works really well (I have not tried it), but the generic, simplistic approach of having a Keepass client that just does what one is supposed to do, like KeepassDX, is really where my interest lies, and it's also what I use daily for my own stuffs.

I don't see anyone writing such file managers like the ones that were mentioned earlier in this and other threads, and we've had this discussion over email as long as a year ago (I use personally use Simple File Manager Pro by Tibor Kaputa from https://www.simplemobiletools.com/ as wel as several other tools that he's authored, since on some phones, I'm completely de-googled).

You had suggested that someone could integrate the type of file manager support that might enable the kind of kdbx file synchronization that KeepassDX needs the most, so perhaps reaching out to Tibor might yield some fruit in that regard - he writes some amazingly awesome apps that are both unobtrusive and privacy respecting, without any permissions that most all of the other app publishers require of their users.

I hope that helps, and that nothing I wrote above was found to be offensive to anyone, as no offense was intended, and I know that I can indeed be a bit passionate about the projects I care about.

If anyone is interested in reaching out, the simplest ways to get a hold of me 24/7 are:

Matrix: @tallship:matrix.org

XMPP: tallship@jabber.org (Please use OMEMO, I do).

I wish all the very best and look forward to following this issue closely. any suggestions or comments.... I'm very interested in hearing and/or helping, where it concerns reliable FOSS based kdbx file sync over multiple devices, and especially where it pertains to KeepassDX.

[J-Jamet]

It's a great message, but don't hesitate to synthesize next time! :D

There are several concepts that are mixed up in your article, I am simply making a short summary so that we understand each other well :

• When we talk about synchronization, it can be interpreted in several ways.
  1. If we look at the terms of the original KeePass app, it is the merging of two database files when there is a difference between the local data and the recovered data. This feature is not yet implemented as it is difficult to develop but is planned (#840). Reloading the complete data still allows to recover the last changes even if it overwrites local data, we just have to be careful.
  2. The recovery of the file from an external location (network, cloud, git, etc...). This part is outside the direct scope of KeePassDX which will remain an editor, without any internet connection.. To manage this, it is necessary to create a separate file manager that will connect to what we want, just provide the file to KeePassDX with the file provider of the created application. So with this method, there is no need for a plugin. Just create an application that satisfies your need to transfer your file where you want.

Whether we're talking about OneDrive, gdrive, Dropbox, Box, iCloud, OwnCloud or NextCloud, etc., the problem (in technical terms) is the same here. It is another thing to talk about ethics for each external synchronization tool. Basically, I will try to remain as ethical as possible but using an other tool is not incompatible with the symbiosis of proprietary products. But they must not be dependencies, we should always have the choice.

The goal of KeePass is to manage a database in a single file that we then manipulate as we want. No matter if users send it to a Dropbox that is not free, each user can send it where he want because it is a file like any other that can be sent anywhere. Personally, I agree, it would be better to use an open source repo, but the most important thing is to keep the concepts well separated and KeePassDX only edits a file that another application provides.

kdbx file sync solutions using git

If you want to create a Git-compatible file manager, that's a good thing. But keep in mind that versioning can only be done at the file level and not for each entry in the database. You would have to transcribe your scripts in an Android application made for that. Git would be more appropriate for text files, but we're getting away from the subject.

If you want, Jérémy, I would be elated to assist you in performing testing or donate/dedicate server resources for such an endeavor, if you would be willing and interested in pursuing this. I believe it is an elegant solution and one that would potentially explode the userbase of KeepassDX.

I thought of creating this second app that could connect to remote servers. For the moment, I'm focusing on the editor, this second network part will come later (sorry if it's long). In that case, I will open another project and we will open another dedicated thread.

kdbx file sync solutions using FOSS based hosted Cloud Sync solutions (NextCloud / Syncthing)

The synchronization problem that is described is a file recovery and merge problem. I haven't studied the code for this part in KeePass yet, but the merge is already there in desktop. As I said before, I plan to implement it in KeePassDX, but I have to study the algorithm of the Desktop version to have the same behavior. Issue #840 You can read this thread for more cache information. #897

Concretely, I have not yet developed merge so I have not yet tested the recovery of files on the different Cloud and on Syncthing. The wiki table represents user feedback and what I found at first glance, but I was planning to make a wiki page for each tool to explain the pros/cons with a user tutorial (it's a big job, so I clearly didn't have time yet). I just added the link to Syncthing's tutorial to the wiki.

The current state of kdbx file sync capabilities for KeepassDX (My personal observations)

I understand that the implementation takes a long time and that some users get impatient. It wasn't a priority because, like you said, other applications integrate all the synchronizations directly into the code, so you're not without a solution.

I personally don't have a real business model on KeePassDX, I work mainly on my spare time. But I'm thinking of making it my main activity. As I plan to create a joint application that will allow to retrieve and send remote files, I will set up a plugin model for each proprietary synchronization solution on this new app. (I'll open another project to discuss it).

Final thoughts and the state of current FOSS based developmental support elsewhere:

I don't think that proprietary and open source solutions are incompatible, on the contrary. I just think that the tools used are too dependent on each other, that's why I created KeePassDX in the beginning, to separate these concepts.

I totally agree, it is necessary to put forward solutions that promote privacy. The main problem here is the simplicity of use, I'm aware of that, I just haven't had the time to implement all my ideas despite my years of work.

On the other hand, core members of the NextCloud team are directly addressing these issues with providing kdbx support natively within NextCloud: https://github.com/jhass/nextcloud-keeweb

I didn't even know it existed. I will look in detail

Well, I know that was a long read, and apologies for that, but this has been brewing for a while and I'm a real believer in KeepassDX itself, not to mention the distribution across devices in synchronization for kdbx files in general.

No problem, I learned several things so it's good. We need to encourage discussion in all cases. The separation of concepts in KeePassDX is very important to me, as well as a good software architecture and the implementation of reusable structured code. But it takes a long time to learn it. Few people know it, but there is almost no KeePassDroid code left in KeePassDX (it was a fork in the beginning but completely reworked). It's common that I do a complete refactoring of a part to have a better integration, better performance and better security, but it's very expensive in terms of design time.

Ideally, another developer should conceive this file tool. As I conceive of creating another application, this is an alternative. But it's also a good thing to contact Tibor. We should open a question on his project page.

I hope that helps, and that nothing I wrote above was found to be offensive to anyone, as no offense was intended, and I know that I can indeed be a bit passionate about the projects I care about.

No offense, I prefer to stay on the github personally to centralize messages and have asynchronous discussions.

[godSaysHODL]

I've been using a synology NAS with the Drive app to synchronize my db between devices. Self hosted "cloud", and works like a charm because it has compability built into file manager.

A specific setting inside the app allows you to "enable offline access for a file", which mean it keeps a syncronized state when it has connection, but also keeps a local state on the device

[J-Jamet]

For those who are interested in synchronization, I propose technical solutions in the issue #840. Do not hesitate to give me your opinion.

[kraoli]

Just read this discussion. I fully understand the need of sync, but I fully support the arguments from J-Jamet. Security related software needs to keep it simple and encapsulation is a big plus. That's also why I don't think that supporting many different protocols is a good idea, all potential opportunities for bugs due to complexity.

I feel much better without any network permissions.

The inconvenience created by a possible breach is much much higher than a bit of daily overhead for me.

Said said. When build in sync is a must, I like the approach of an additional offline version were the network related package is not part of the code.

[zilti]

Why would built-in sync be a must? Just use an app for synchronizing... I am using Syncthing and it works perfectly fine.

[nataloko]

I think DAVx5 gets quite close to helping with webdav?

I've tried it and KeepassDX manages to actually create a new file on the remote folder... But then it throws some IO error.

https://www.davx5.com/manual/webdav_mounts.html

[peterbabic]

Author of the linked guide for Syncthing + KeePassDX here. I am using it together for a year now and I had no problems whatsoever. Synchronization is almost instant, all apps can handle that the file change on the fly. Also syncing with a laptop for KeePassXC as a daily driver and syncing .kdbx to a local Pi as a backup.

I can only recommend. It is a little bit more technical to set up, but it is definitely set it and forget.

[Marucins]

Has anything changed these days with integration with a service like Dropbox? Does KeePassDX allow to sync database with this cloud service?

[J-Jamet]

@Marucins Please read the threads properly before asking the same questions.

840 https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync

[Derpitron]

Hey, I have had Dropbox installed on my phone as well as KeePassDX for more than a year, and i've been able to use dropbox just fine. When I choose the database to read and write in the app home screen, I scroll to the bottom of the left side bar in the file manager, and dropbox appears for me, from there I choose the kdbx file.

[Marucins]

[...] and i've been able to use dropbox just fine. [...]

It's not about whether it works - it's about synchronization and the lack of synchronization of changed files from different sources.

[tallship]

If there's a lack of synchronization when the .kdbx file is changed on one source while you're using the other then that's really the definition of, "doesn't work".

[zilti]

It's not about whether it works - it's about synchronization and the lack of synchronization of changed files from different sources.

Synchronization is your job, not the job of KeePassDX. I am sure you possess the very basic tech literacy needed to open KeePassDX and select the database file that has been synchronized by OneDrive, Dropbox, or what-have-you in the file manager. Try it, it's not hard at all.

[octomike]

Synchronization is your job, not the job of KeePassDX. I am sure you possess the very basic tech literacy needed to open KeePassDX and select the database file that has been synchronized by OneDrive, Dropbox, or what-have-you in the file manager. Try it, it's not hard at all.

I agree with your general sentiment (different tools for different jobs), but I just had KeepassDX in combination with Onedrive destroy my database files. I tested this with 2 different phones and 2 different databases.

KeepassXC now says: Error while reading the database: Invalid inner header id size

KeepassDX says: IOException: Invalid HMAC

So for me, the question is not really wether or not there is in-built onedrive support (which it really shouldn't have imho), but more importantly, if the interaction with onedrive works at all. Can anyone shed some light here?

[J-Jamet]

There's an explanation for that : The stream of the file provider is interrupted (for some reason, depending of the app) during a file save. Obviously if the stream is interrupted, not all data is saved and the file becomes corrupted. It's like if you upload a file to a server and the server that provides the connection breaks it during the upload (here the application breaks the stream of the URI). I can do all the efforts I want in KeePassDX, I can't prevent this break of the provider. It is up to the app provider that provides the file to manage a cache to avoid this kind of case and not break a link while data is in transit.

Clouds and applications want us to integrate their API because their application doesn't handle this kind of case. My point of view for the creation of a workaround file manager/provider app is here : https://github.com/Kunzisoft/KeePassDX/issues/840#issuecomment-955169250

Otherwise in the meantime, you can save your file locally and upload it manually to your favorite Cloud application to avoid a link break. It is of course recommended to always make regular backups. https://github.com/Kunzisoft/KeePassDX/wiki/Backup

[octomike]

Thanks for taking the time to explanation, I really appreciate it and I'm beginning to understand a little..

To get this straight, you chose to use the ContentProvider API instead of "regular" file operations, presumably to simplify your code and still be compatible to ContentProvider-only storage apps? Is that also why KeePassDX does not require the READ_EXTERNAL_STORAGE permission?

However, for some reason the OneDrive provider is broken on file updates? Wouldn't that mean it's broken for every client that wants to update a file like KeepassDX? Is there no IOException or similar that can be handled (maybe with a rollback?). I'm struggling to understand that point still.

[J-Jamet]

SAF and Content Provider way is the regular way in Android ecosystem : https://developer.android.com/training/secure-file-sharing https://developer.android.com/guide/topics/providers/document-provider

Access to the system file tree is very restricted and requires special permissions. In most cases, the methods provided by Android are symbolic or emulated links, only dedicated applications like file managers have access to a part of the tree (and in a restricted way). And yes, using the normal methods of accessing files in the Android documentation does not require additional permissions or rights I understand that it is disturbing when you are used to computer ecosystems that are much more permissive. But accessing the actual files tree requires a lot of work and access validations, which is clearly not necessary and not recommended for a file editor.

However, for some reason the OneDrive provider is broken on file updates? Wouldn't that mean it's broken for every client that wants to update a file like KeepassDX?

Theoretically yes, but in reality I do not know I do not use this app. I advise you to simply test One Drive with other client apps that use SAF and you will see the result. The thing I know is that many users have already reported to me that the same URI is sometimes used to open another file in the system. This means that the file provider of One Drive is pointing the URI reference to another file at some point. Which is extremely dangerous so I have no illusions about the rest of their code. #1118 (After that it would be better to look at their source code, you can always ask, haha)

Is there no IOException or similar that can be handled (maybe with a rollback?). I'm struggling to understand that point still.

If there are any, I already capture them and an error is displayed indicating an error in saving the file in KeePassDX. If there is no error displayed, it means that there is no exception, so theoretically there is no error in saving the provider's URI stream. (This is if you trust the content provider, which is implicitly the case for the user if he has installed the file manager application he wants.) There is no reason to do a rollback if no errors are reported. The data in the temporary memory of an open database always remains intact during the save so if the data is sent to the stream without error, it is OK for KeePassDX.

This is just a theory, but I think there is a sync or cache problem in One Drive for whatever reason, the URI stream is break and the errors are not thrown. KeePassDX and the user thinks the save went well, tries to reopen the file that is corrupted and blames KeePassDX (I get a lot of emails and I waste my time explaining each time, that really tires me out).

I make sure that the save code always runs smoothly and without problems, and everyone can see how it works. I am human and I am of course open to improvements. Anyone can check the code and propose technically and in detail improvements to the open code in KeePassDX. ;)

[J-Jamet]

Now that the merge is fully implemented, I close this issue. The synchronization (file transfer and file conflict management) must be done from an external app, if you want to talk about a specific protocol or drive, you can do so from the links below for building the FileSync application.

Google Drive : https://github.com/Kunzisoft/FileSync/issues/4 OneDrive : https://github.com/Kunzisoft/FileSync/issues/3 Dropbox : https://github.com/Kunzisoft/FileSync/issues/5

[melroyvandenberg]

All tickets are "closed", but the issues are still there and not resolved. Incl. the Nextcloud one.

Yes, I can sync the file using Nextcloud and open the file using KeePassDX. However, the file link seems to get broken every often causing "Permission denied" because the file is getting revoked.

See indeed the wiki page: https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync#file-access-revocation

KeePassDX can fix this if they allow integration of those Cloud apps (using their APIs) within KeePassDX, creating a native solution.

[J-Jamet]

KeePassDX can fix this if they allow integration of those Cloud apps (using their APIs) within KeePassDX, creating a native solution.

https://github.com/Kunzisoft/KeePassDX/issues/342#issuecomment-533993154 The API integration solution will be done in the FileSync application.

[tallship]

KeePassDX can fix this if they allow integration of those Cloud apps (using their APIs) within KeePassDX, creating a native solution.

#342 (comment) The API integration solution will be done in the FileSync application.

But you even closed the NextCloud issue and that hasn't been resolved, and I think that's the point.

Most of the people commenting here never even cared about dropbox or onecloud or Box or gdrive - we chose KeePassDX and most also KeePassXC and we use and trust FOSS - not those privacy disrespecting, data mining, legacy monolithic silos.

I haven't had problems with SyncThing but want to use NextCloud or Peergos and want absolutely nothing do to with google or Microsoft or any other privacy mining company.

So after all this time, you've got a file syncing app (presumably at F-Droid) that syncs KeePassDX with corporate silos that I gather very few people using KeePassDX (Because it's FOSS) are even remotely interested in, while all the FOSSies here that chose KeePassDX still, after more than three years going round and round here, still do not have any viable solution involving a privacy respecting FOSS Solution like NextCloud or ownCloud?

Oh man, I feel like we've been looking for a very simple solution that is FOSS and trustworthy that will never come, and that maybe that whole concept of using privacy respecting FOSS only has been completely ignored all this time!

I don't mean to come off as sounding disrespectful, and I've donated in three past. I appreciate your efforts and commitment to open source, but people have been telling you over and over - many of us use degoogled phones, have no Microsoft accounts, will not consider them as legitimate solutions since they violate the public trust by deliberate design and then you make those silos the priority after almost 4 years of folks asking over and over and over again for a NextCloud sync...

And then you close the issue because we can now sync with Microsoft or Google. As if that even counts to many people that have commented on these issues over there years. No thank you.

I really don't care HOW you choose to implement a NextCloud sync. I care that nothing has been achieved in well over three years - there is no syncing solution at this time - dropbox and gdrive and onecloud or Box don't even count - they don't even exist in many people's universe.

We have no sync solution for KeePassDX.

[J-Jamet]

The Nextcloud issue is here : https://github.com/Kunzisoft/FileSync/issues/11

I didn't close the issue because there are other closed source solutions, I just closed it because NO synchronization code will be included in KeePassDX because the application IS and WILL BE only a KeePass file editor without internet permission. I've written about it all the time, I've always been clear on the subject and how the application uses the content provider of the synchronization applications.

Here is the NextCloud synchronization application, on F-Droid! : https://f-droid.org/en/packages/com.nextcloud.client/

A workaround for link loss and file conflicts will be provided in the FileSync app but this project is only conceptualized and not yet coded. Again, I prioritize projects and work on my own time and I don't have four arms.

https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync

I wrote a very detailed wiki on the subject.

Note : Thank you for the donations, but where did you hear these rumors? My priority is to provide well-made, secure and open applications based on open philosophy so that as many people as possible can use digital tools in respect of privacy. So I don't know where you read or saw that my priorities were "thos silos", you just told me, I didn't even know about it myself. :D

[tallship]

Oh okay, great!

You had talked about it a year or two back because you said there wasn't anyone else that had made such a file manger to replace the Google one that won't work with anything but the Google infra.

I'll go and download your fille sync manager and start testing on NextCloud with KeePassDX and KeePassXC. If everything works out I'll be able to start switching some folks over from VaultWarden in a couple of weeks, so they can use it with their existing NextCloud systems.

Thanks so much! I thought you were saying that your filesync manager only worked with Google, Microsoft, and other proprietary silos, and since the regular NextCloud file sync when tested caused data loss in the kdbx files it would never work.

Thanks again!

[J-Jamet]

Thanks so much! I thought you were saying that your filesync manager only worked with Google, Microsoft, and other proprietary silos, and since the regular NextCloud file sync when tested caused data loss in the kdbx files it would never work.

I absolutely never said that, any program can basically be updated so of course any app can work over time. :face_with_spiral_eyes: