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
PBKDF2 is currently used only for ephemeral LAN file-sharing sessions, not for long-term secret storage. For backups and at-rest encryption, Argon2id is already used.
In the LAN sharing case, the session is short-lived, keys are not stored, and the threat model is limited to local, real-time attacks, where PBKDF2 remains acceptable. That said, I'm open to revisiting this if a stronger KEX-only design makes sense.
It's Spyware
just look at the number of connections (1st opening)
Tabby as example only connect to one ip and easy to block this connection with a Firewall
"Marix" was deleted in few min after installation, it's better not use such spying apps.
i haven't check packets, only direct connections, with deep inspection it might look even more dangerous.
If only there's a way to use it without electron bundle, but as a website - would be great. nonetheless, i appreciate the existence of the program.
When you say "we", does that mean you and your LLM subscription? 🙄
Wait, you're using password-based encryption for ephemeral transfers? Without any key agreement algorithm whatsoever?
And you're seriously limiting your threat model to real-time attacks?
This is why it is so irresponsible for you to be advertising this.
This conclusion is incorrect and based on a misunderstanding of how modern desktop apps work.
Multiple outbound TLS (443) connections on startup do NOT indicate spyware.
Electron/Node applications commonly open parallel connections for:
You explicitly stated you did not inspect packets, did not MITM traffic, and did not review the source code.
Calling an app “spyware” without analyzing payloads or behavior is not a security finding.
The entire codebase is open-source.
Marix does not run background services, does not auto-start with the OS, and does not transmit user secrets.
Anyone is free to inspect, build from source, or block any outbound endpoint via firewall.
Comparing it to Tabby is not meaningful: Marix has a different feature set and threat model.
If you have concrete packet captures, stack traces, or code-level findings, I’m happy to review them.
Otherwise, this is speculation, not analysis.
“We” refers to the project author and reviewers involved in design decisions.
If you have technical concerns with the threat model or implementation, feel free to raise them.
Thanks for the detailed feedback.
To clarify, the current LAN sharing design intentionally limits scope:
That said, you are correct that a KEX-based design (e.g. X25519 + AEAD) would be a more robust and future-proof approach, even for local transfers. I agree this is a cleaner model than password-derived keys alone.
The current implementation is documented with its threat model and not intended to provide SSH-grade guarantees. I’ll revisit the design and either:
Appreciate the technical critique — this is useful input.
Hold up... you don't even use AE??
Every single one of those is a potential attack vector that basically invalidates any previous attempt to validate your app as secure.
It's an SSH client. It's only job is to connect a single SSH connection to the target. Anything else is a potential security risk.
Only in the opinion of your LLM. Real people disagree.
Yes, AEAD is used.
All encrypted payloads use authenticated encryption (AES-256-GCM), so integrity and authenticity are verified in addition to confidentiality.
There is no encrypt-only mode.
I agree that minimizing attack surface is important.
Marix is intentionally positioned as a desktop SSH manager with additional features, not as a minimal replacement for /usr/bin/ssh.
For users who prefer a zero-feature, single-purpose tool, standard OpenSSH remains the best option.
The main additional feature seems to be providing multiple vectors that can be exploited by an attacker to run arbitrary code, while gathering your SSH keys together in one easy-to-exfiltrate place.
If you believe there is a concrete vector that allows arbitrary code execution,
please point to the specific component or code path.
General statements about attack surface are not the same as a demonstrated vulnerability.
private app which is named as "☁️ No servers, no backend 📊 No telemetry, no tracking"
should not make even single connection without user push that button manually for update or whatever, as alternative - to have a separate version without any outgoing automated connections
do you know why people use ungoogled chromium as a main browser these days, cause it do not make not any single outgoing connection to anywhere from installation point.
what i see is: you never been paranoid about your privacy for real, how can you know what people feel when app is connecting anywhere, when they expect: APP CONNECT NOWHERE - NEVER< EVER.
“No servers / no telemetry” means Marix does not operate a backend,
does not collect usage data, and does not transmit user information.
It does not mean the application is entirely network-isolated.
Like most modern desktop apps, Marix may open outbound TLS connections
for certificate validation, version checks, or optional API integrations.
A fully offline / zero-network build is a different threat model.
Some users prefer that, but it is not the baseline assumption for this project.
that's the thing, call me when a new fully private ssh client are finished.
Marix is designed for a different threat model and audience.
A fully offline SSH client is outside the scope of this project.
ignored
OK
This is a concrete attack vector.
This is a concrete attack vector.
Sure, but why does that need to make a connection anywhere? Everything you need is in the certificate itself.
At best, this is leaking information to a 3rd party. If I want DNS-over-HTTPS, I'll configure my resolver to do that.
This is a concrete attack vector.
The problem is that you're trying to get people who are security conscious enough to want to use ssh, and then your baseline assumption is that they don't care about security.
You are describing potential attack surfaces, not demonstrated exploits.
An attack surface only becomes a vulnerability when there is a concrete
exploitation path (input → sink → code execution).
If you believe there is an RCE, please point to a specific code path,
parser, or execution sink. Otherwise, this remains a theoretical concern,
not a security finding.
You have absolutely no business doing anything at all related to security.
Understood. I’ll assume there is no concrete exploit path to discuss at this time.
OK, sure. I'd like to know exactly what these outbound connections that occur on startup are about 👇
You responded with generics about what they might be for, but I'd like you to explain them in detail...and please don't tell me to review the code, (which you "wrote" and therefore should be familiar with), I'm asking for a specific breakdown of what they are and why they occur.
If there are concrete vulnerabilities with reproducible steps, I’m happy to address them. Personal judgments aren’t actionable.
Thanks for the question — here’s a concrete breakdown.
Marix does not transmit user data, credentials, or SSH traffic to any third-party service.
The outbound TLS connections observed at startup fall into the following categories:
1) OS / Chromium-level certificate validation (OCSP / CRL checks).
These are performed by the underlying Chromium and Windows trust store,
not by application-level code, and occur in many Electron apps.
2) DNS resolution and TLS handshakes initiated by the embedded Chromium engine.
These may result in multiple short-lived connections to common infrastructure
providers (e.g. Google, Cloudflare) without any application payload.
3) Optional metadata access (e.g. version/changelog links) triggered by UI initialization.
No auto-update mechanism or remote code execution path exists.
Marix does not include:
All outbound traffic can be blocked via firewall without breaking core SSH functionality.
A fully offline mode is being considered for users with stricter threat models.
If you believe a specific connection results in data exfiltration or arbitrary code execution,
please point to the exact code path — I’m happy to address concrete findings.
Might not waste my time here.
Evidences are clear! (AI generated / Spyware).
Reguards
Please can YOU explain these connections rather than asking an LLM to do it?
Security claims require concrete technical evidence.
If you have a specific finding (code path, exploit, or PoC),
feel free to share it. Otherwise, there’s nothing to respond to.