muwire issueshttps://i2pgit.org/zlatinb/muwire/-/issues2022-08-28T14:23:14Zhttps://i2pgit.org/zlatinb/muwire/-/issues/55Expand All and Collapse All options for tree view2022-08-28T14:23:14ZmortenseExpand All and Collapse All options for tree viewCurrently in the tree view of directory and file listings the user has the option to expand or collapse an individual directory by clicking on the + or- icon or double clicking on the directory name in the tree. I think it would be wort...Currently in the tree view of directory and file listings the user has the option to expand or collapse an individual directory by clicking on the + or- icon or double clicking on the directory name in the tree. I think it would be worthwhile to have a the option to be able to expand all or collapse all the sub-directories as well. This would quickly lessen the visual clutter that happens when, for example, a search returns a large number of hits in multiple directories and sub-directories. The state should probably only persist until the search is re-run.https://i2pgit.org/zlatinb/muwire/-/issues/54Infinite automatic download retry doesn't work2021-03-04T17:46:16ZElde EtnorInfinite automatic download retry doesn't workMuWire 0.8.6-b0 via I2P plugin
Settings:
- `Download retry frequency (seconds)`: `5`
- `Give up on sources after this many failures (-1 means never)`: `-1`
From what I understand, with the above settings MW should be retrying failed d...MuWire 0.8.6-b0 via I2P plugin
Settings:
- `Download retry frequency (seconds)`: `5`
- `Give up on sources after this many failures (-1 means never)`: `-1`
From what I understand, with the above settings MW should be retrying failed downloads every 5s until it succeeds.
## Observed behaviour
MW doesn't retry failed downloads every 5s. Downloads enter "Failed" state, and remain like that until user manually clicks on "Retry".
## Expected behaviour
MW should keep retrying to download until it succeeds.
## Workaround
~~I've set `Give up on sources after this many failures (-1 means never)` to `666666`, seems to do the trick.~~
Edit: Scratch that, workaround also doesn't work.
~bughttps://i2pgit.org/zlatinb/muwire/-/issues/53MW fails to download anything with non-local directory for incomplete files2021-03-03T17:16:39ZElde EtnorMW fails to download anything with non-local directory for incomplete filesMuWire 0.8.6-b0 via I2P plugin
# Description
When the directory for incomplete download files is located on a network filesystem, MW fails to download anything.
Furthermore, when it fails it eventually marks the failure as a network ...MuWire 0.8.6-b0 via I2P plugin
# Description
When the directory for incomplete download files is located on a network filesystem, MW fails to download anything.
Furthermore, when it fails it eventually marks the failure as a network error, consequently erroneously marking peer as unreliable.
Additionally, to add to the confusion only the `Incompletes` directory makes downloading fail, while the directory for completed downloads works just fine being on a network filesystem.
# Details
The network filesystem in question is 9P.
Should be easy to reproduce with QEMU.https://i2pgit.org/zlatinb/muwire/-/issues/52Plugin - files are still listed from previous search when switching to a sear...2020-11-22T22:53:38Zyellow bearPlugin - files are still listed from previous search when switching to a search with no results.When switching active searches to a search that has no results, the files from the previous view search are still listed, but the users list is properly cleared.
To replicate, perform two searches - one that has results and one that doe...When switching active searches to a search that has no results, the files from the previous view search are still listed, but the users list is properly cleared.
To replicate, perform two searches - one that has results and one that does not. Click on a user in the search that has results to view their search results. Next, switch to a search that has no results. You will see the files from the previous search still listed.https://i2pgit.org/zlatinb/muwire/-/issues/51Downloaded files with duplicate names are overwriting each other2020-10-30T10:51:42ZmortenseDownloaded files with duplicate names are overwriting each otherTry to replicate this bug only. Do not try to fix. I suspect that it is a part of a larger problem.
With music files for example the directory will often contain the name 'cover.jpg' or 'booklet.jpg' for scans of print material that wa...Try to replicate this bug only. Do not try to fix. I suspect that it is a part of a larger problem.
With music files for example the directory will often contain the name 'cover.jpg' or 'booklet.jpg' for scans of print material that was included in the original album. MuWire does not seem to handle this well. What I am seeing is when MuWire tries to download multiple files with identical names into the Download directory it seems to overwrite any existing file with the same names.
The simple fix of renaming by a number to the end of the filename is what file managers tend to do when trying to copy the files of the same name into the same location. This will corrupt the users collection and break up the swarm by corrupting files so that identical files from different users do not hash to the same value. Consequently they will no longer be able to both act as sources for what was originally the same file.
The solution as I see it will be to come up with a mechanism for recreating not just the file but also the original owners directory that contained the file.
For example the uploader had a directory of an album. That directory contained several audio files and a subdirectory called scans. The scans directory had files called 'cover.jpg', 'back.jpg' and 'cover.jpg'. That same uploader or some other uploader had a directory of a different album with the same subdirectory and containing files of the same names. When the downloader downloads the second set of files they are overwritten in his MuWire 'Download' folder. The solution would be to recreate the directories nested as they were on the uploaders file system so that files of the same name ended up in unique locations.
The fix would be more complicated than that but for now we just need to verify that this occurs and can be replicated.https://i2pgit.org/zlatinb/muwire/-/issues/50External router -> exit confirmation2020-10-23T14:24:51ZqtmExternal router -> exit confirmationWhen the gui client looses connection to an external i2p router the user has to manually confirm the exit and termination of MW.
Please provide a configurable option in MuWire.properties to exit without confirmation ( makes it easier to ...When the gui client looses connection to an external i2p router the user has to manually confirm the exit and termination of MW.
Please provide a configurable option in MuWire.properties to exit without confirmation ( makes it easier to automate testing of the gui client).
CheersZlatin BalevskyZlatin Balevskyhttps://i2pgit.org/zlatinb/muwire/-/issues/47MW internal i2p router profiling based on Markov Model2020-10-22T11:26:29ZqtmMW internal i2p router profiling based on Markov ModelThe internal i2p router profiling is an ideal candidate for Markov state transitioning to pick peers for various tasks.
What comes to mind is a 2 or 3 state MC UP/DOWN BAD/NORMAL/GOOD for classification.
The same MC logic of MW's MC for ...The internal i2p router profiling is an ideal candidate for Markov state transitioning to pick peers for various tasks.
What comes to mind is a 2 or 3 state MC UP/DOWN BAD/NORMAL/GOOD for classification.
The same MC logic of MW's MC for connections could be applied.
Cheershttps://i2pgit.org/zlatinb/muwire/-/issues/45Remove all innerHTML in js2020-05-11T13:01:07ZzzzRemove all innerHTML in jsref: #44
ref: https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML
innerHTML is insecure and requires the insecure CSP script-src unsafe-inline.
Used appx. 150 times in the js.
Step 1:
Where the "HTML" is really just plai...ref: #44
ref: https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML
innerHTML is insecure and requires the insecure CSP script-src unsafe-inline.
Used appx. 150 times in the js.
Step 1:
Where the "HTML" is really just plain text, use textContent instead.
Step 2:
Where we're really inserting HTML, that's harder. To be researched.https://i2pgit.org/zlatinb/muwire/-/issues/44Plugin form security2020-05-11T12:49:10ZzzzPlugin form securityAll plugin pages and js/XHR POST targets need a full review and hardening.
Need nonces, CSP headers, and other checks and protections.All plugin pages and js/XHR POST targets need a full review and hardening.
Need nonces, CSP headers, and other checks and protections.https://i2pgit.org/zlatinb/muwire/-/issues/43Sign Tool security2020-05-12T20:03:07ZzzzSign Tool securityThe current SignTool together with mucats CRA is a nice proof of concept,
but it's a security risk for Alice to have a tool for others to
trick her into signing arbitrary data.
This could be used to humiliate Alice by getting her to sig...The current SignTool together with mucats CRA is a nice proof of concept,
but it's a security risk for Alice to have a tool for others to
trick her into signing arbitrary data.
This could be used to humiliate Alice by getting her to sign
"I hate cats", or the base64 or hash of that, or a bank transfer, for example.
(aka chosen plaintext attack)
The current scheme is that mucat Bob generates 64 byte nonce a1,
and sends challenge=b64(a1) to muwire Alice. Alice does no validity or length
checks, and returns b64(sig(challenge)).
Replay attacks are prevented by Bob ensuring that a1 is never reused.
Slightly better is if Alice validates that challenge=b64(a1) is valid b64
and that the length of a1 is correct by base64.decode(challenge).
Then, Alice generates nonce a2, and returns b64(a2 + sig(h(a2 + h(challenge)))).
This is somewhat inspired from HTTP Digest auth, RFC 2617.
This still ignores other security issues such as MITM (possibly minor for I2P),
lack of timestamps, etc. I will soon be investigating "real" public key challenge/response
using modern standards and putting destination keys on Yubikeys.
I'll make recommendations as I learn more.https://i2pgit.org/zlatinb/muwire/-/issues/42Issue with MuWire after an i2p service restart.2020-03-30T12:32:06ZZlatin BalevskyIssue with MuWire after an i2p service restart.When manually stopping and starting the service (on Windows: sc stop i2p / sc start i2p) everything get reconnected perfectly. All tunnels are working, MuWire/status page shows connections and uploads are resumed. But... "Status" on the ...When manually stopping and starting the service (on Windows: sc stop i2p / sc start i2p) everything get reconnected perfectly. All tunnels are working, MuWire/status page shows connections and uploads are resumed. But... "Status" on the main page shows "Connections: Down" so doing a "Search" is not possible. ("Not initialized" error message).
Need to manually stop the plugin from the i2p console, wait about 20 seconds, and start it again. Only then it starts to show connections, making "Search" work again.https://i2pgit.org/zlatinb/muwire/-/issues/41Virtual home directory structure involuntarily shared2020-03-07T09:12:59ZZlatin BalevskyVirtual home directory structure involuntarily shared*Created by: Yanestra*
This is a security issue. I have not checked if I can reproduce because I considered the security impact a fundamental risk.
I have used muwire under a Linux system. An emulated Windows environment (Wine 4) was...*Created by: Yanestra*
This is a security issue. I have not checked if I can reproduce because I considered the security impact a fundamental risk.
I have used muwire under a Linux system. An emulated Windows environment (Wine 4) was present but set up in a way that it should not be commonly usable if WINEPREFIX is not properly set in advance.
After sharing some less sensitive directories with muwire for two weeks or so I found that somebody tried to download some photos from my muwire host. I wondered where these photos came from and found that the Wine virtual home directory was now included in the list of shared directories. This specific directory is only used for Wine and downloading files from it meant no actual harm.
But to me, it was an alarm bell and I immediately shut muwire down.
Can you please check how a complete user home directory structure can be involuntarily included in the sharing? It shouldn't make much sense under usual system setups, while being a major security risk at the same time.https://i2pgit.org/zlatinb/muwire/-/issues/40Q: Trusts by category2020-03-06T06:53:00ZZlatin BalevskyQ: Trusts by category*Created by: ArsenShnurkov*
Is it possible to trust a person in questions about chess, but don't trust him about political topics?*Created by: ArsenShnurkov*
Is it possible to trust a person in questions about chess, but don't trust him about political topics?https://i2pgit.org/zlatinb/muwire/-/issues/38Logs at log-level INFO are too verbose2020-01-25T11:06:07ZZlatin BalevskyLogs at log-level INFO are too verbose*Created by: LoveIsGrief*
com.muwire.core.util.JULLog spams the logs and makes debugging pretty difficult and unnecessarily fills up the logs.*Created by: LoveIsGrief*
com.muwire.core.util.JULLog spams the logs and makes debugging pretty difficult and unnecessarily fills up the logs.https://i2pgit.org/zlatinb/muwire/-/issues/29[Feature Request] Sharing private files2019-12-22T15:14:11ZZlatin Balevsky[Feature Request] Sharing private files*Created by: cypherbits*
Hello, I would like to see if it is possible to add a feature to make some files "private" and sharing them at the same time with some kind of password or URL.
I mean, only Muwire users who knows the URL/pass...*Created by: cypherbits*
Hello, I would like to see if it is possible to add a feature to make some files "private" and sharing them at the same time with some kind of password or URL.
I mean, only Muwire users who knows the URL/password can download and share the file.https://i2pgit.org/zlatinb/muwire/-/issues/19[Feature Request] MuWire version detection2019-10-05T13:02:49ZZlatin Balevsky[Feature Request] MuWire version detection*Created by: ScriptTiger*
As vulnerabilities are found in previous versions, be it MuWire-specific vulnerabilities or vulnerabilities found to be in the I2P components themselves which are merged with this project, it would be important...*Created by: ScriptTiger*
As vulnerabilities are found in previous versions, be it MuWire-specific vulnerabilities or vulnerabilities found to be in the I2P components themselves which are merged with this project, it would be important to have a means of knowing a given sender's MuWire version when considering trust status.
As this project is mostly Java and for the most part identical across platforms, OS detection may not be needed. However, there might also be a case for OS detection if large portions of the code are found to be OS-specific, as the possibility for OS-specific vulnerabilities would also arise. The OS would not actually directly need to be detected by MuWire, but extended client versioning could be used and reported by each MuWire client to each other to delineate the "flavor" of a given version, i.e. .4.14w might designate that client as having been designed for Windows, and so on.https://i2pgit.org/zlatinb/muwire/-/issues/7Use XDG Base Dir Standard2021-06-13T15:48:40ZZlatin BalevskyUse XDG Base Dir Standard*Created by: zetok*
When looking at the README of the project one can easily notice the following:
> (…) create a file `$HOME/.MuWire/i2p.properties` (…)
Creating a new application that doesn't follow standards for config files in...*Created by: zetok*
When looking at the README of the project one can easily notice the following:
> (…) create a file `$HOME/.MuWire/i2p.properties` (…)
Creating a new application that doesn't follow standards for config files intensifies the problem with users' home directory being polluted by wrongly placed directories. It gets to the point where people are desperate enough to write a whole [FUSE filesystem just to get dotfiles cleaned up](https://github.com/sloonz/rewritefs).
It doesn't have to be like this.
[XDG Base Dir spec](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)
Instead of placing config files in `~/.MuWire` place them in `$XDG_HOME_CONFIG/MuWire` (note the absence of the dot), or `~/.config/MuWire` if `$XDG_HOME_CONFIG` is not set.https://i2pgit.org/zlatinb/muwire/-/issues/2Please make this project so it can be ran portably2019-06-03T00:42:20ZZlatin BalevskyPlease make this project so it can be ran portably*Created by: IITFA*
This is a feature request.
It would be a good idea to make it so that this project can be run in a portable manner using command line options to point to things like the configuration folder, download folder, and ...*Created by: IITFA*
This is a feature request.
It would be a good idea to make it so that this project can be run in a portable manner using command line options to point to things like the configuration folder, download folder, and so forth.
Thank you.