This is an ugly workaround. For some reason a sync is called when an
account is removed. Since the main account is removed, we get an invalid
account exception when trying to fetch it.
Need to find out why a sync is even triggered and just remove it there.
Android allows only having one address book per account, so until now
users of EteSync were only able to have one address book. This was
always an annoying limitation, but even more so now that journal sharing
is implemented.
Luckily, DAVdroid recently implemented multiple account support by
creating sub-accounts for address books.
This patch is an import of the DAVdroid changes, with adjustments to
work with EteSync, and a few changes that did not make sense for
EteSync. The original commits' split didn't provide any value over this
squash, and the amount of adjustments and addition needed to be done to
apply them, made me decide to squash this change together.
This commit is mostly based on:
dfec72ce6b8ff5e0780e9ac4418c81d080f4b60b
9817594da14ad8dffae18de386e14aeaf41312b9
Thanks to @dschuermann for the suggestion. This makes it easier for
people of non-latin speaking cultures to compare the fingerprints.
Code is based off of Signal's fingerprint generation.
This change only works for calendars at the moment, because we don't have shared
address books anyway.
This is currently only implemented in the client, and only as a read-only attribute,
you can't make a journal read-only yet. This requires server support that is not yet
there, but it's better to be ready for this sooner rather than later.
Some of the information is now saved there, and more will be transferred
soon. CollectionInfo includes the encrypted part, and journalentity the
non-encrypted part of the journal info, so both are needed.
The reason for that is that before version 2, all the journals of a
particular user shared the same encryption key, which means, sharing a
journal of version one, would essentially give away the encryption key
of all of its journals, even the private ones.
This is thus blocked for security reasons.
This currently just adds the journal back, but doesn't re-apply the
journal, so the calendar for example would be empty, but the journal
itself would be listed and visible.
At the moment we only support one address book per user, and sharing
address books will interfere with this model. Hopefully, we'll add
multiple address book support in the next release, and then we'll
re-enable this.
We were not detecting the version correctly, but always just assumed
latest version, which is obviously wrong.
In addition, before this commit we used to automatically verify on
fetch, which wasn't flexible enough for some use cases. This fixes that
too.
We need the keypair to access shared journals, so we need to make sure
to fetch it at the moment we create the local account, which is what
this commit does.
This is used to create a keypair and put it on the server if one doesn't
exist, and fetch it and save it locally if one does.
It's currently called from the account activity.
If a journal has a key set to it (usually used for shared journals), use
it instead of the symmetric key. The key of the journal is asymmetrically
encrypted using our keypair.
Requery doesn't automatically update column constraints, and there was
an issue with it applying indexes before adding the new columns which
was also causing troubles. This commit, while ugly, just manually
updates the database using raw SQL to what we expect it to be.
Having it in raw sql was slowing down development, and was error-prone.
It's much cleaner now, easier to handle, and enables us to develop
faster.
In this change I also fixed the fetching of journals to be by service
and id, not just id, because just id is not guaranteed to be unique.
Before this change, uid was unique on its own, this was wrong, because
due to shared journals, we can have the same journal in two accounts,
and we can thus have both journal and entry UIDs more than once.
This fixes the constraint to be unique for journal, uid, and service,
uid combinations.
This is currently disabled for journals because of a bug in requery.
The server was changed so the owner of the journal, and the encrypted
key (if a shared journal) would be exposed. This change fetches it, and
saves it.
Unfortunately this requery version introduced a regression. When adding
a new account, it takes syncign a few times until it works. It looks
like requery is not loading the recently saved instances.
This reverts commit f0f70ff1c61996d0e45d8f72d24654c739c325f7.
Prior to this version of requery there was an issue that prevented
afterLoad to be called in some cases. This issue forced us to add an
explicit call to afterLoad. It's now fixed, so the workaround is no
longer required.
Reference issue: https://github.com/requery/requery/issues/487
We were storing the ctag separately although the data was already
present in the journal. The last entry's ID is always the CTAG.
This could cause issues if sync is aborted exactly at the right time.
I managed to trigger this issue on rare cases.
It's only used for migrations, and has been considered deprecated for a
while. Mark it as deprecated to make it extra obvious that this should
not be used.
* move file name/UID generation from SyncManager to LocalContact, LocalEvent, LocalTask
* rename updateFileNameAndUID() to prepareForUpload()
* use random UUID for contacts, UidGenerator with Android device ID for events/tasks
* LocalEvent.prepareForUpload(): use existing UID_2445 if available
This also adds an icon (that will soon be replaced with the icon of the
relevant account), and shares the design between the calendar and the
contacts.
This set of commits add import from local accounts.
It's a bit rough around the edges, but it's good enough to go in, so work can continue
collaboratively.
The crypto class now behaves differently depending on the version of the
journal.
The current difference is in the key derivation, and that the new
version of the crypto also hmacs the version automatically whenever it
hmacs anything.
The versioning was added for better future-proofing of the code.
The derivation change was done because before we were creating the same
password for all of the journals, now we do it per-journal. This means
that we can, if needed in the future use this password as the journal
password when sharing journals without compromising the security of the
rest of the journals.
The app update broadcast receiver is only called on the first update,
not install, which was causing EteSync to think it was updating from
version 1 on the first update, doesn't matter which version one was
updating from.
This fixes it by saving the version on the first run.
Before this change we were adding them to cache before they were
processed, potentially persisting malformed entries, or entries we
haven't yet processed causing issues if sync was aborted before an entry
was fully processed.
Commit 5d1c90dcba fixed a bug where
entries added from the server were marked as "local only" (null etag)
which was causing issues. That commit fixes it for newly added resources,
but existing resources remained broken.
This commit goes through the database and fixes all of the existing
broken resources. It skips dirty entries because figuring out if they
were just created or updated is complex, and the chances of doing an
update at exactly the same time there are dirty entries is quite low,
so the complexity involved is just not worth it.
Before this commit we would create new entries from the server without
an etag, essentially marking them as "local only". While the actual
value of the eTag is not currently used, null or not matters.
Because the resources were "local only", we would get weird behaviours
like having an "ADD" action when changing a resource.
Before this change we would only add "deletes" to the server when the
resource has been previously uploaded. This means that if a resource has
been created and then deleted before a sync, it would not be saved,
which is essentially data-loss.
This commit fixes it, so we always upload a delete entry.
It's really annoying that it doesn't do it automatically as it should,
in the meanwhile, add this workaround.
I reported it to upstream:
https://github.com/requery/requery/issues/487
Clearing the cache is a good idea regardless, though because of the
unique constraints in the cache on the journal name, this was causing
issues when deleting an account and then adding it back.
