Files get renamed according to mimetype when this shouldn't be done.

[SwirlyStone5877]

Describe the bug
When sending files from Matrix to protocols that don't support attachments (e.g. IRC, XMPP, or in our case sshchat), the file that gets downloaded to MediaDownloadPath is renamed to have an extension that matches the mimetype. However, on some files this shouldn't be done, e.g. .fur files (Furnace Tracker) or .vgm files

To Reproduce
Steps to reproduce the behavior:

• Send a file with a bridge linked to a protocol with no attachment support
• Watch it be renamed when downloaded to MediaDownloadPath

Expected behavior
It not being renamed.

Screenshots/debug logs
Screenshot from nheko (Matrix client):
https://fs.swirly.architectenterprises.net/screenshot_z060OvuDHn94wEDk.png
Screenshot from sshchat (provided by third party on MINGW):
https://fs.swirly.architectenterprises.net/clipboard.png

Environment (please complete the following information):

• OS: Linux on my end, Windows on file sender's end and bridge hoster's end
• Matterbridge version: 1.26.1-dev 6d468ad (GitHub actions)

Additional context
Configuration file: https://fs.swirly.architectenterprises.net/matterbridgeobfuscated.toml

[SwirlyStone5877]

Ah... Second issue, uploading .wav or .toml files crash the bridge... Encountered this when third party attempted to send config to me...

[SwirlyStone5877]

Decided to run through GitHub actions builds, seems like both issues I mentioned here don't apply to commit 0c6c021 (the second-latest build GitHub ran, more likely the issue just starts at the latest commit as that's the only one to tamper with Matrix between that and the other commit mentioned).

https://fs.swirly.architectenterprises.net/screenshot_uORQeb3RBnYV4gYd.png

[selfhoster1312]

Hello, thanks for the report!

That is indeed a new bug i just introduced in here: #169

To be clear it's not exactly a bug it's meant as a defense-in-depth mechanism because mimetype/extension confusion attacks are very common in the wild to exploit parsers and obtain remote code execution.

However, it's a bug that matterbridge is no longer doing what you want! Matterbridge is actually only renaming extensions when the declared mimetype doesn't match the provided extension, see here.

We can probably add configuration options to either disable that behavior entirely or manually configure a mapping of extensions/mimetypes. However, to really fix that problem, we should add the mime/extension mapping to upstream libraries in your matrix client and matterbridge. Not sure which but i'm guessing at least one of those uses the system-wide mime mapping.

Could you please provide debug logs (matterbridge -debug) for that incident so we know on which side the issue needs to be fixed?

As for the TOML and WAV crashes, that's an entirely unrelated issue, but i appreciate the report. Could you please open another issue with debug logs?

Thanks for the reports, and sorry for breaking your workflow with the latest PR! <3

[selfhoster1312]

Could you try either building #179 or running the build artifacts from there?

[SwirlyStone5877]

Hey, thanks for getting back to me! I can't do any of this quite yet but I'll get back to you when I can.

[SwirlyStone5877]

Got the debug logs for file renaming.
https://fs.swirly.architectenterprises.net/kill.txt

Will make an issue for .wav/.toml crash. Issue is solved in latest commit, along with renaming.

[SwirlyStone5877]

Latest PR solved everything, thanks.

EDIT: Unsure as to whether I should keep this open...

[poVoq]

I think we can close this.

[selfhoster1312]

Will make an issue for .wav/.toml crash. Issue is solved in latest commit, along with renaming.

Please try to reproduce with the debug logs so we understand what's happening. File handling error should not crash the bridge. TOML/WAV should not produce a mimetype error or any file error. This is a definitely a bug worth investigating :)

[SwirlyStone5877]

Oops, never saw this. Will report in a bit.

[SwirlyStone5877]

https://fs.swirly.architectenterprises.net/c.txt
Debug logs for .wav crash.

[selfhoster1312]

Hi, thank you for this quick and detailed report. It is very useful and Today I learned that a goroutine crash crashes the entire runtime! This will be useful to inform future architectural decisions of matterbridge.

However, the origin of the problem is unclear. It looks like the system running matterbridge does not recognize .wav as a valid file extension for audio/x-wav mimetype. According to go docs, we use system databases for this purpose so you could check in paths given there. You can for example use this script:

#!/usr/bin/env bash

mime="$1"

for f in /usr/local/share/mime/globs2 /usr/share/mime/globs2 /etc/mime.types /etc/apache2/mime.types /etc/apache/mime.types /etc/httpd/conf/mime.types; do
        if [ -f "$f" ]; then
                echo "$f"
                grep "$mime" "$f" || echo "  -> not found"
        fi
done

You can run it like ./mime.sh "audio/x-wav" and report the output here. It will not work if the bridge is running windows, but that in itself would be an indicator of what went wrong. Because the funny thing is your matterbridge system seemed to know about the mimetype (no error returned), but not about the file extension (empty list returned)…