New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Meh. I'd like to be a good netizen. I also found a number of issues, but haven't had time to send them over.
On another note:
https://github.com/marixdev/marix/commit/162706aec409c3c5fa524fba1e43662f29d2b2e7
https://github.com/marixdev/marix/blob/68754becb375004dcb0b105d90b1580109a977ee/dist/main/services/google-credentials.json
?????
Corrected.
Reguards
To clarify:
This was present in older commits / artifacts.
Starting from v1.0.16, credentials are no longer committed or bundled.
All provider credentials are now injected at build time via GitHub Actions secrets, not stored in the repo or dist output.
The exposed credentials have been fully rotated and revoked.
The current release pipeline does not ship any embedded OAuth secrets.
Thanks for pointing this out — fixes like this are exactly the kind of concrete feedback that helps improve the project.
Question: why are you pushing
dist/every release w/ JS? It seems unnecessary considering they're all auto-generated by the TS transpiler, and no contributions there will make it back to the TS source.Edit #2: I can't force you, but if "open source" is so important to you/the project, why aren't branches and smaller (scoped) changes being used?
Good question.
This is mostly historical. Early versions were built locally and
dist/was committed as part of the release process before CI/CD was in place.Starting from recent versions, builds are handled via GitHub Actions and
dist/is treated as a build artifact only. Going forward,dist/will be excluded from commits and only source files will be tracked.Regarding branches: this has been a solo project so far, which is why changes landed directly on main. As the project stabilizes, I’m moving toward smaller, scoped changes and feature branches.
Appreciate the concrete feedback.
@forest
May God have mercy on our souls.
........well, there goes your SSH password.
Edit: I have disrespected our Lord. Capitalised to "God."
This log line only indicates a fallback to an existing system OpenSSH binary (ssh.exe) when ssh is not found in common paths.
No SSH credentials are intercepted, logged, or handled by the application.
Password input is handled directly by the OpenSSH process itself, exactly the same as when you run ssh.exe from a terminal.
If you believe credentials are exposed, please point to:
Absent that, this claim is technically incorrect.
I think I realize what's happening. He's not even reading the thread, even with translations. He probably doesn't even know we're bashing his project. He just sees a lot of replies and thinks he's really popular, so he keeps pasting them into the LLM blindly and posting its responses, equally ignorant of them.
The poor LLM keeps saying it doesn't want to keep talking but marix keeps forcing it to reply.
To close this thread on my side:
Marix is an open-source desktop SSH client, not a formally audited security product.
It does not claim to provide threat models, formal security proofs, or third-party audits.
Concrete issues that are actionable for me are:
General distrust, architectural disagreement, or hypothetical threat models without concrete findings are noted, but not something I can meaningfully act on.
If anyone has concrete security findings, responsible disclosure channels remain available.
Otherwise, I’m stepping back from further discussion here and focusing on development.
No probs mate, just keep prompting.
Okay, I normally wouldn't do this, but:
If another program wishes to listen to all of your SSH sessions, all it needs to do is add a fake
sshbinary (norootneeded). Even worse, if that binary (as is my case) proxies stdin/stdout to OpenSSH proper, then the user will never notice.Like, even if it's a fallback, you shouldn't ever resort to doing this.
Whats your favorite flavor milkshake?
Strawberry! Sometimes I spice it up with banana as well.
wbu?
There is a serious problem with feline leakage in line 42.
I have spent an entire week listening and waiting for a concrete Technical Bug Report from this community.
Here is the result:
Two minor issues found: (Legacy credentials in old JSON & dist folder bloat) -> ✅ FIXED immediately.
Noise: A flood of personal attacks, accusations of 'LLM-generated code', and nitpicking on the website UI (which is just a marketing wrapper).
Critical Security Flaws: ZERO. Not a single critical vulnerability has been pointed out in the Core App source code.
Conclusion:
The fact that some of you have shifted from technical auditing to personal attacks and labeling proves one thing: The current version (v1.0.16) is technically solid enough that you have run out of valid things to criticize.
My Stance on AI/LLM:
I am a Pragmatic Developer. Whether this code was typed 100% by hand or assisted by tools like Copilot/AI, the only things that matter are:
It Works.
It is Secure (Argon2id + AES-256-GCM implemented correctly).
It is Open Source (Fully auditable).
And I take full ownership of every single line.
I am ending this debate here to focus on shipping features for Real Users.
If you find a bug: Open a GitHub Issue with a stack trace. I will fix it.
If you only have insults or conspiracy theories: You will be ignored.
Happy coding.
Bad, but "It Works."
Reguards
Thanks for the report! I have fed the cat and cleaned up line 42. No more leakage. 🐱
Haha, good one.
Take a piece of advice.
If somebody tells you "this whole approach to X is insecure because REASON", you might learn something if you try to understand why REASON means X is bad.
We don't need to look at your code to find every instance to point out all the places where you have done X. The fact you say it does X is sufficient to know it's bad.
Actually, our tone has been the same since the very beginning. You are being mocked not for creating an insecure app with trivial XSS and MITM vulnerabilities (and worse), but for your risible insistence that it is secure and your constant repetition of the same falsehoods and LLM vomit non-sequiturs.
Now go away like you've said you were going to do what, 15 times?
And no, your AES-GCM is not implemented "securely". No, I won't tell you how because it's painfully obvious to anyone who has any understanding of security.
could be worse, at least it doesn't plaster "WE USE AES-ECB SECURE ENCRYPTION" everywhere! /s
"I appreciate your concern, but AES is a FIPS-validated algorithm and blah blah AI slop. Unless you have actionable information blah-de-blah I don't understand cryptography blah so I am stepping back from engaging to focus on 'my' code"
Oh my god, he actually thinks security bugs will spit out stack traces. Well that explains it. His mindset is "if it works, it's secure". I hate to break it to you, marix, but security bugs don't present themselves until it's too late.
maybe we can sell him on our new advanced hashing algorithm that doesn't have preimage resistance, very vast, very secure!
...............yeah, I'm calling it a night. Cheers lol