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
You’re right that being open source alone does not automatically make software trustworthy, and I agree that community review is not the same as a formal third-party audit.
At the current stage, Marix does not claim to have undergone an independent security audit, and I’m careful not to present it as such. The project is open source to allow transparency and scrutiny, not as a guarantee of correctness. A proper audit would indeed be more credible, but that is not always realistic for an early-stage, free, open-source project.
Regarding implementation: I avoid making claims of “perfect” or “unbreakable” security. The threat model and scope are intentionally limited and documented, and users are expected to evaluate whether that fits their risk tolerance.
I also understand that for some users, only long-established, heavily audited tools are acceptable. That’s a valid position, and Marix is not trying to replace those tools.
Thanks for sharing your perspective.
It doesn't even matter what you claim (or don't), you're announcing an ssh client and some poor dummy is going to assume "ssh client" is equal to "safe" or "secure" because duh. You're a danger to society, get out.
This is slop, and getting sloppier.
"🎯 Who is Marix for?"
That's what people are complaining about. Your Github repo claims it is fit to use, yet you're spending your time in here saying you aren't making those exact claims.
No no said that. How did you get "open source alone does not automatically make software trustworthy" from "claiming an entire codebase is open source doesn't add much trust"?
How can you claim transparency and scrutiny when you yourself haven't even written the code? And you're right, a proper audit is not realistic for an early-stage project (wait, I thought you said it was finished in the OP, why are you now saying it's in its early stages?), and that is precisely why it's grossly irresponsible to be releasing this and recommending users use it. And why do you throw "free" and "open source" in there as if that has any relevancy whatsoever to the importance of auditing? I mean, I know why: It's LLM fluff, but that doesn't make it stand out any less.
You do not list a proper threat model, you list what an LLM thinks a threat model is.
It's not "some users". All users expect SSH, the Secure SHell protocol, to be secure. When basic, trivial mistakes are made over and over, inductive reasoning tells us that there are more basic, trivial mistakes lurking in this codebase that literally no one, not even you, understand.
But you aren't taking in our perspective. You're regurgitating LLM slop that consistently misses the point while using cloyingly non-confrontational corporate speak. You will keep repeating that you've "carefully laid out a threat model to let users make their own choice" when what you wrote is neither a threat model nor gives users an understanding of the true scope of the issues.
If you can't write secure code, you shouldn't be writing code (but everyone does anyway, which is why I still have a job). And if you can't write secure code, then you definitely should not write security-critical code!
If you put big, fat warnings saying that your client is highly likely vulnerable to replay attacks, downgrade attacks, pre-auth RCE, host spoofing, remote DoS, and information disclosure and that it should only be used on carefully-sandboxed systems connecting to other carefully-sandboxed systems, I would be copacetic.
It's crazy how LLMs boost people's confidence so much that they become so dangerous to themselves and others. I miss the days when only pathological narcissism and Dunning-Kruger led to this kind of crap.
Thanks for the extended feedback — I appreciate people taking the time to think about these topics.
To be clear, Marix is not presented as a drop-in replacement for highly audited tools like OpenSSH or PuTTY. When I described the threat model, the intention was to be transparent about what is and isn’t covered, not to suggest perfection or invulnerability. An SSH client handles sensitive data by definition, and I fully agree that a misimplementation can create a false sense of security — that’s why detailed, transparent documentation and clearly stated threat boundaries are important.
If there were evidence of a specific flaw, I would welcome a focused issue pointing it out so it could be addressed. General statements like “it is insecure” without specifics do not help improve the code.
For users who require only the most battle-tested, heavily audited tools, established native clients remain appropriate. Marix is intended for users who value control, transparency, and certain UX workflows, not for environments with ultra-strict compliance requirements.
Regarding threat modelling: if it would be helpful, I can add a dedicated section in the README/Documentation that outlines precise threat assumptions, limitations, and user responsibilities.
Callouts to LLM usage in documentation should not be interpreted as the source of security logic — they are part of background context, not a replacement for explicit design choices.
Thanks again for engaging with the project.
My god, it got stuck in a loop repeating the same irrelevant things that were already addressed.
Please stop using LLM to answer every single message.
Addresses a concern no one had.
As mentioned before, what was added is not a threat model.
Addresses a concern no one had.
Agrees with a statement no one made.
Non-sequitur that does not address the previous statement.
Misses the entire point.
Misses the entire point
Addresses a concern no one had.
Look, let me be clear. Without understanding your own code, it is impossible to produce a formal threat model. This has been explained a number of times, but then again, I'm literally arguing with a bot.
Addresses a concern no one had.
I think I'm done responding directly.
Everyone using ssh. Kindly fuck off.
Thanks for the discussion. To clarify for anyone reading:
1) Marix is NOT intended as a drop-in replacement for highly audited tools like OpenSSH, PuTTY, or enterprise clients. The README and documentation should reflect that it is targeted at users who value transparent workflows and control, not ultra-strict compliance.
2) I acknowledge comments about threat modeling. I will add a dedicated section in the documentation that clearly outlines:
- the threat model considered
- what is deliberately out of scope
- what security assumptions are made
- what risks users should be aware of
3) Open source visibility and community review are not guarantees of correctness, but they provide transparency. Independent audits are valuable and welcome if funded or sponsored.
Personal insults or random claims about implementation quality do not help improve the project. If specific issues or vulnerabilities are found, I encourage focused issue reports on the repository so they can be addressed.
Thanks to everyone who engaged constructively.
It saddens me that "even 2 minutes spent ensuring no preauth RCE" and "having a non-zero number of eyes on the code" counts as "ultra-strict compliance". And please, for the love of god, use Google Translate and not ChatGPT for your replies.
Personal insults sure, I don't think anyone has personally insulted you.
As for the "random claims about implementation quality", they are entirely warranted. For a security product like this, the onus is on you to prove it is secure. If nobody ever looks at your repo, it doesn't mean your project is secure.
For most people it just isn't worth their time to scour somebody else's code base, on a project they've only just heard of, from a developer they've never heard of, looking for bugs, running the risk of not noticing something serious, when instead they can just run ssh and be worry free. Your project needs to be really compelling for someone to make that effort to do your work for you.
The number of forks that have already been made of this repo scares me. Junior devs in major corps are going to be stealing bits of the code, and no one is going to know about it until something major gets holed and sinks the ship.
This thread is a great demonstration of why generative AI is so dangerous at this stage. The code is all AI generated, the posts are all AI generated, and no thought or actual relevant knowledge has gone into creating any of it.
That’s fair — I’m not asking anyone to audit the code for me.
The project is open-source so it can be reviewed by those who are interested.
Others are free to use standard ssh tooling instead, which is perfectly reasonable.
I’ll continue improving the project based on concrete feedback and reported issues.
If you have specific technical issues to report, feel free to open an issue on GitHub.
General accusations without evidence aren’t actionable.
I’m not claiming basic security hygiene equals strong guarantees.
I’ve tried to be explicit about the project’s scope and limitations, and I’m continuing to improve it based on concrete issues rather than abstract accusations.
At this point, I think further back-and-forth isn’t productive, so I’ll focus on improving the code and documentation.
I was about to say "no you won't, your LLM will. You don't even read your own code" but then I remembered I've been talking to an LLM this entire time, so... godspeed, I guess?
There are so many other types of software you could have experimented with vibe coding, why on earth would you pick an ssh client?
He doesn't understand rudimentary security, so I suppose it's natural that he doesn't realize what a major mistake he's making and why it's so dangerous.
I have to admit my gut reaction was malicious intent, but .. it would be too obvious I suppose.
Because this is a real problem I personally have when managing many hosts, and the scope is clearly documented. Users who prefer standard ssh tools are not the target audience.
after testing Marix in a vm, i saw it used around 190-240MB of ram on idle. Seriously. I moved over to Termix and that uses less then 80MB of ram usage. the UI is cool n all but Marix with Electron + React + Tailwind CSS all eating near 200MB is not good imo. I'll just stick to Termix from now on since it works on desktop and mobile...
Are users who prefer not to allow the remote host to remotely exploit them the target audience?
Thanks for actually testing it and sharing concrete numbers.
You’re absolutely right — Electron-based apps do have a higher idle memory footprint compared to native terminal-focused tools like Termix, and that’s a conscious trade-off here.
Marix is aimed at users managing many hosts and workflows in one place, where UI, state, and integrations matter more than minimal RAM usage. For users who value ultra-low resource usage and a pure terminal experience, tools like Termix are a great fit.
Appreciate the honest feedback.
Marix does not expose additional network services, does not accept inbound connections from remote hosts, and does not alter the SSH trust model.
Users who require a minimal, battle-tested surface should continue using standard SSH clients — that’s explicitly stated. Marix targets workflow convenience for users who understand and accept the trade-offs.
I don’t think further back-and-forth here is productive.
Why on 64GB personal pc should matter 200MB or 80MB?
If you think accepting inbound connections or opening network services is required for a server to exploit the client, that is exactly why you should stay far away from trying to write secure code.
He is not charging for the software. No one forces you to install it. Heck, he even does pretty terrible job to promote it. Calm down, it will fade out as fast as it emerged. Those, who install such software knows what they do.
Bashing someones hobby is pointless work, as person loves what he create (with LLM or without it). Let it go.
As others have said, what he is doing is dangerous. I've already found some severe vulnerabilities in that software which would, with a little effort, allow me to remotely exploit the client if they connect to my server. This is the issue with trying to write secure code without understanding security. The people who try to use it are unlikely to understand the quality of the codebase and will judge it based on the UI.
Asking an LLM to write slop for you is fine, even insecure slop, but then promoting it as a secure, finished project? That's irresponsible as both I and others have pointed out.