malformed commit breaks swarm

I have two accounts, one logged in on my computer and the other on my phone. After logging in to my computer for more than a period of time, my phone starts the software, and then my computer cannot receive messages sent by my phone.

Mobile version: 379 (376)

Equipment model: Samsung s20+5g

Android 12

Computer version: 202307111203

Win 10 (22H2)

I think I have reproduced this error. On September 16th, when I was in version 376, I encountered this error and it reappeared tonight. I give these two examples because I have the Jami logs on my phone during these two errors.

In the previous time, I encountered this error at least ten times, but it was all between computers, and the computer's records were not complete. I hoped to - d start, but this error will not reappear after restarting.

The important thing is that this error may not occur until the computer's client is started for an hour (if that happens, the log will be large, so I did not attempt to record the log on the computer)

Actual result: My computer cannot receive any messages.

Expected results: Message transmission should be normal.

Public network dynamic ipv6 is working normally.

Yesterday, I thought it might be an issue with the Android version being too low, so I didn't provide any feedback on this issue because I heard from a friend that Jami seemed to have fixed an error that could cause abnormal messages.

However, today I encountered this problem again.

And I have two days of logs, so I decided to upload it.

log0.log

log1.log

In the two logs, there is a description of "message sent successfully", but in reality it is not.

In the second log paragraph, it was not until my account received a message from the computer that both parties' information reception and transmission resumed normal.

The reason for returning to normal is that I performed the "close account and then re enable account" operation on my computer.

During this period, the abnormal state of the message lasted for 20 minutes.

I can't find how to upload the file, so if there is any sensitive information, could you please help me cover it up.

Thank you. I admire your hard work.

@h151814 You should remove your ID(s) of your Jami user account(s) from the logs. Else other users can find you.

Simply use the settings of Word "find and replace":

https://support.microsoft.com/en-gb/office/video-find-and-replace-text-6f0f7d58-9b49-4a14-aba8-1de2195c0ab6

so all people can only see something like "UserID1", "UserID2",etc.

Thank you very much. Is this the only sensitive information? I seem to have seen the IP address, but there are too many, which makes me feel confused. I am very unfamiliar with these codes

It depends on your provider but I think your IP adresse will be automatically changed after some time?

https://whatismyipaddress.com/keeps-changing

It won't change so frequently and the time is not fixed. But I'm not sure because my phone has just started and my computer always has problems after about an hour.

I have uploaded the log on this computer and hope it can provide assistance.

Although just restarting can solve this problem, it can still be frustrating because if you don't realize that you are no longer able to receive messages, it may cause some messages to be delayed.

In August, my friend and I chatted on Jami, we greeted each other, and then I was working.

About two hours later, I saw that he was still online and I sent him a message, but it failed.

Then I restarted my account, successfully sent the message, and received his read receipt.

It seems to be a problem with my computer client here, because even after restarting my phone, it still cannot send messages normally. Only by restarting Jami on my computer can it be effective.

Before Jami374 on Android, I also encountered the same problems as on my computer.

My friend is using a Linux system

jami.txt

I tried to drag and drop the file directly, and it was successful. Tonight, I imported the logs from the Jami client on my computer into the file, and the operation was the same as the previous two days. I reproduced this error.

The programmers are too busy, I don't want to trouble them, but I still have one small problem.

When we open a conversation window on our computer, we no longer receive message prompts, and I often miss messages because of this, but it's just a small inconvenience.

added BacklogHigh bug labels

Hi, thanks for the bug report. We are busy at the moment but we will look into this ASAP

Malformed text/plain commit 408c177079a1cea8c4ec3a2b9b70288bdc375ee2. Please check you use the latest version of Jami, or that your contact is not doing unwanted stuff.
[1694887182.633|6060|conversation.cpp        :1222] Could not validate history with 4666b8144887a1b91bed481e33f04fb7eb4109a3a3762dcff009de6e0085e1da

The validation doesn't pass. And I see 3 possibilities:

1. Your peer is not up-to-date (not likely, we didn't do any big changes recently regarding to this) and doing things he shouldn't.
2. He modified a commit in a invalid way (not likely)
3. The conversation is in a bugguy state. For this, I'd need a conversation to dig. But I guess this one is confidential. If the sender is a "power user", we can:
   • Go to the conversation directory (~/.local/share/jami/*/conversations/56ede91c786646bf09fb6d929629616e8e216056 on device 4666b8144887a1b91bed481e33f04fb7eb4109a3a3762dcff009de6e0085e1da (the one sending))
   • Do a git diff 408c177079a1cea8c4ec3a2b9b70288bdc375ee2..0e04830c36d3ac87d4d1e5be5a119268ab43c8ac and send me this (408c177079a1cea8c4ec3a2b9b70288bdc375ee2 is the malformed commit, 0e04830c36d3ac87d4d1e5be5a119268ab4 seems to be the parent)
   • This will show me if there is incorrect data inside the commit

Because an invalid message is detected, the sync is not done anymore, as it can result in bad data sent.

A "solution" would be to restart a new conversation with this contact (aka both remove contact and restart)

We are using the latest official client without making any modifications. It is not just a problem with one contact, but after running the computer for a period of time (about an hour or more), we are no longer able to receive messages. There are already at least 5 contacts who are like this.

I have found the files and there are many folders in this directory. Should I send them directly here or use another contact method?

I checked the folder and found that some of the files inside are damaged. The hook, info, logs, and ref files are missing.

But the folder was damaged on October 15th, after my feedback

But the file damage occurred after I reported this issue, and I don't think it seems to have any impact. Now I only have a hidden folder called '. git', which is only 1.3mb in size

This doesn't change my answer. a git diff will help me

removed BacklogHigh label

added wait-for-answer label

changed the description

removed bug label

added BacklogLow label

added swarm label

moved from jami-client-android#1378 (moved)

removed wait-for-answer label

assigned to @sblin

Ok, so to avoid any future failure, I did https://review.jami.net/c/jami-daemon/+/25195

My theory is that a invite failed or a merge failed while committing a new message, so the file was added in the wrong commit.

The patch avoid concurrent transaction and force to start from a clean index before committing, that would avoid this.

The patch will not fix the sync, because the conversation is malformed. So there is two solutions:

• Restart a new conv when the patch will be merged and released
• Or, compile your own Jami and disable the commit verification to force this conv to sync.

For now I don't have a better way, cause the validation must fail if an incorrect file is detected. Removing this could lead to bad files sent automatically

mentioned in commit 54f149fc

I'm doing a nightly with the patch to avoid any future regression like this

I guess we can close as it should not be reproducible in future

closed

changed title from Message cannot be sent to Commit error causes multiplayer swarm failure

reopened

changed title from Commit error causes multiplayer swarm failure to Commit error causes multi-user swarm failure

changed title from Commit error causes multi-user swarm failure to malformed commit breaks swarm

I encountered a malformed commit again.

Malformed text/plain commit 50913ab9ed3ffaa33d9cabab4c992f0739535119. Please check you use the latest version of Jami, or that your contact is not doing unwanted stuff.

malformed_commit.diff_edited.txt

I replaced all IDs.

@AmarOk1412

@Lanius-collaris Thanks for the diff, I'll try to figure out what might have caused the error. (Just FYI, Sébastien left Savoir-faire Linux last year and is unlikely to keep working on debugging this issue.)

@ffauteux-chapleau My theory is that some paths contain ":" (Every Jami URI contains a colon), so ConversationRepository::Impl::resetHard() failed on windows (git config get core.protectNTFS)

@Lanius-collaris Thanks. Normally, the names of the files in the invited folder should only consist of hexadecimal digits, so the presence of the "jami:" prefix is a bug. I found two commits from last year that were supposed to prevent this kind of thing from happening:

• https://review.jami.net/c/jami-daemon/+/28337
• https://review.jami.net/c/jami-daemon/+/28638

They were merged in May and July respectively.

Could you check in the repo when the three invalid files were created? Was it before or after the July patch?

@ffauteux-chapleau I found a commit like this.

commit 7e1a8d0fd2b63bb122bb3f110efd0672520ce5be
Author: replaced <id replaced>
Date:   Sun Jan 12 13:10:59 2025 +0000

    {"action":"add","type":"member","uri":"jami:id replaced"}

diff --git a/invited/jami:replaced b/invited/jami:replaced
new file mode 100644
index 00000000..e69de29b

Another member in that swarm said, <id replaced> used a version released in 2023.

I guess this means that older versions of Jami can be implemented to attack newer versions, or at least this glitch provides such a potential attack mechanism

Perhaps Jami should devise a mechanism to fix buggy submissions, because as a chat software, having to change groups due to a single bug can result in a lot of information being lost, including familiar contacts in the group. As a chat software this would be a major drawback. I think it could be done this way: each device in Jami could verify the legitimacy of a message, and if it is not legitimate, it could be overwritten locally or frozen without affecting anyone else's messages, and there is an option to notify the other devices of this error message, but whether such a mechanism would cause any other problems, I can't imagine.

@Lanius-collaris Thanks. Even in 2023, I don't think the "jami:" prefix was supposed to be included in the commits like this, but presumably there was a bug that caused this to happen at least occasionally. In any case, we need to fix the commit validation code so that this doesn't happen again.

@h151814 You also encountered malformed commits recently, right? Would it be possible for you to send me the content of a bad commit like @Lanius-collaris did? The cause of the problem may not be the same in both cases.

We were exploring this together, and my record is included in this record.

Ok, thanks for the clarification.

assigned to @ffauteux-chapleau and unassigned @sblin

added severitycritical sprintin progress typebug labels and removed severitylow label

@h151814 Answering your last two messages here to avoid cluttering the other thread:

I guess this means that older versions of Jami can be implemented to attack newer versions, or at least this glitch provides such a potential attack mechanism

Yes, this is a potential attack mechanism. In general, there's nothing preventing malicious users from sending invalid data, so Jami should never assume that what it receives from the network is correct without checking. If it does, then it's a bug.

[...] having to change groups due to a single bug can result in a lot of information being lost, including familiar contacts in the group. As a chat software this would be a major drawback.

I agree that users should never have to do this. Jami checks every message it receives before committing it in a conversation's repository, which is supposed to prevent the conversation from getting in a corrupted state, even if there are malicious users (or buggy older versions of Jami) in the group sending invalid messages. However, it's obviously still possible for a conversation to become corrupted if there's a bug in the message validation logic itself, which seems to be the case here. Unfortunately, I'm not sure there's a good solution in general for "fixing" conversations that have gotten into a bad state.

[...] each device in Jami could verify the legitimacy of a message, [...]

As I mentioned above, we already do this.

[...] and if it is not legitimate, it could be overwritten locally or frozen without affecting anyone else's messages, [...]

What do you mean by "overwritten locally"? Right now we simply reject invalid messages, and I don't think we really have any other options if we want the swarm to keep syncing properly between all members.

What do you mean by "overwritten locally"? Right now we simply reject invalid messages, and I don't think we really have any other options if we want the swarm to keep syncing properly between all members.

I think so, after learning about git.

One of my pie-in-the-sky ideas to override or note the issue locally on the device without affecting other devices or other users.

Best if it's inspiring, if it's a childish idea, please laugh it off.