Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

Marix open source desktop SSH client for developers and sysadmins

1234579

Comments

  • ralfralf Member

    @marix said:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).
    It does not and cannot document every network connection created by the underlying OS, Chromium engine, certificate validation mechanisms (OCSP/CRL), DNS resolution, or TLS trust infrastructure, as these are outside application control and vary by platform, network, and policy.

    If you cannot document every network connection, how can you proof they are safe?

  • marixmarix Member

    @ralf said:

    @marix said:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).
    It does not and cannot document every network connection created by the underlying OS, Chromium engine, certificate validation mechanisms (OCSP/CRL), DNS resolution, or TLS trust infrastructure, as these are outside application control and vary by platform, network, and policy.

    If you cannot document every network connection, how can you proof they are safe?

    Security is not proven by enumerating every runtime network connection.

    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.
    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    If your position is that software cannot be considered safe unless it controls and documents the entire OS and browser networking stack, then no modern desktop application meets that bar.

  • marixmarix Member

    @Levi said:
    OP you better stop replying. Because:

    • you don’t know how your application works
    • you have no desire to be challenged by security aware users
    • lack of english language knowledge for technical discussion without help of LLM

    Continue what you are doing, just not here. Go to hostloc, mjj’s will absorb your app, replicate it and sell.

    @tfgp99 said:

    @marix said: For clarity

    Wrong answer!

    @Levi said: Go to hostloc, mjj’s will absorb your app, replicate it and sell.

    Would buy it actually, will be more secured than this :D

    Security claims require technical evidence, not personal assertions.
    Claiming the author “doesn’t understand their own application” without pointing to a specific design flaw, code path, or reproducible exploit is not a technical argument.

    If there is a real issue, present the evidence.
    Otherwise, this discussion is no longer productive.

  • ralfralf Member

    @marix said:

    @ralf said:

    @marix said:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).
    It does not and cannot document every network connection created by the underlying OS, Chromium engine, certificate validation mechanisms (OCSP/CRL), DNS resolution, or TLS trust infrastructure, as these are outside application control and vary by platform, network, and policy.

    If you cannot document every network connection, how can you proof they are safe?

    Security is not proven by enumerating every runtime network connection.

    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    If your position is that software cannot be considered safe unless it controls and documents the entire OS and browser networking stack, then no modern desktop application meets that bar.

    That is not my position, and there is plenty of software I trust to run on my machine. Not one of them initiates as many connections to external websites as yours. Not even applications written using Electron.

    In any case, you choose what libraries to include in your application. If that library is doing things you don't understand, how can you expect anyone else to trust your software if not even know what it's doing and why?

  • LeviLevi Member

    Guys, we will drain tokens for his llm :D

  • marixmarix Member
    edited January 25

    .

  • marixmarix Member
    edited January 25

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).
    It does not and cannot document every network connection created by the underlying OS, Chromium engine, certificate validation mechanisms (OCSP/CRL), DNS resolution, or TLS trust infrastructure, as these are outside application control and vary by platform, network, and policy.

    If you cannot document every network connection, how can you proof they are safe?

    Security is not proven by enumerating every runtime network connection.

    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    If your position is that software cannot be considered safe unless it controls and documents the entire OS and browser networking stack, then no modern desktop application meets that bar.

    That is not my position, and there is plenty of software I trust to run on my machine. Not one of them initiates as many connections to external websites as yours. Not even applications written using Electron.

    In any case, you choose what libraries to include in your application. If that library is doing things you don't understand, how can you expect anyone else to trust your software if not even know what it's doing and why?

    For transparency, Marix does not ship any custom networking or cryptographic stacks.

    The application is built on well-known, auditable libraries:

    • SSH: ssh2 + node-pty (standard SSH protocol, no reimplementation)
    • Terminal: xterm.js
    • RDP: call thirdparty rdp app xfreerdp (linux) microsoft remote desktop (win/macos)
    • LAN discovery: bonjour-service (mDNS, local network only)
    • Crypto: hash-wasm (Argon2 / SHA via WASM)
    • Storage: sqlite3, electron-store (local only)

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    Any outbound connection created by application code is documented.
    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    If there is a concrete security concern, please point to:

    • a specific code path,
    • a packet capture showing exfiltration,
    • or a reproducible exploit.

    Labels and speculation are not a security assessment.

  • ralfralf Member

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

  • marixmarix Member

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

  • ralfralf Member

    @marix said:

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

    Your LLM is stuck repeating the same things. And not answering the questions. The questions are:

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

  • marixmarix Member

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

    Your LLM is stuck repeating the same things. And not answering the questions. The questions are:

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    To be clear and transparent:

    Marix does not currently provide formal security assessment documents,
    threat models, or audited outbound-connection inventories.

    This is intentional.

    Marix is an open-source desktop SSH client, not a security product,
    and it does not claim to meet the standards of formally audited or certified software.

    The project documents:

    • what functionality it provides,
    • what features are user-initiated,
    • and that it performs no telemetry or background data exfiltration.

    It does not attempt to document or control platform-level networking behavior
    introduced by the OS or Chromium runtime.

    If the expectation is a formally assessed security product with complete
    threat modeling and audited artifacts, then Marix is simply not intended
    to meet that requirement.

    That is not a defect — it is a scope decision.

  • uhuuhu Member

    I’m considering using your SSH client in a zero-trust environment where we also have to plan for post-quantum cryptographic migration. Could you walk me through, step by step, how your client handles the following scenario?

    • Key exchange and re-exchange during a long-running session (e.g., 12 hours) with intermittent network loss, including how your client manages packet buffering, replay protection, and the interaction between KEXINIT retransmission and application-layer timeouts.

    • Crypto-agility implementation — specifically, how your client would hypothetically switch from, say, chacha20-poly1305 to a Kyber768-based hybrid KEX mid-session if a server advertised it after initial handshake, including any changes to the SSH binary packet protocol framing.

    • Side-channel resistance in both software and, if relevant, in any embedded hardware token integration (like a YubiKey) for Ed25519 signatures, especially relating to branch prediction and memory access patterns in your error-handling routines.

    • How your client would fail gracefully and auditably if we introduced a MITM that selectively drops packets to force a fallback to a weaker cipher — would it log, disconnect, or allow administrator-defined policies?

    If possible, could you also provide a minimal example of the state machine for this scenario in pseudo-code, and explain how your approach differs from OpenSSH’s Packet/Dispatch architecture?

  • marixmarix Member

    @uhu said:

    I’m considering using your SSH client in a zero-trust environment where we also have to plan for post-quantum cryptographic migration. Could you walk me through, step by step, how your client handles the following scenario?

    • Key exchange and re-exchange during a long-running session (e.g., 12 hours) with intermittent network loss, including how your client manages packet buffering, replay protection, and the interaction between KEXINIT retransmission and application-layer timeouts.

    • Crypto-agility implementation — specifically, how your client would hypothetically switch from, say, chacha20-poly1305 to a Kyber768-based hybrid KEX mid-session if a server advertised it after initial handshake, including any changes to the SSH binary packet protocol framing.

    • Side-channel resistance in both software and, if relevant, in any embedded hardware token integration (like a YubiKey) for Ed25519 signatures, especially relating to branch prediction and memory access patterns in your error-handling routines.

    • How your client would fail gracefully and auditably if we introduced a MITM that selectively drops packets to force a fallback to a weaker cipher — would it log, disconnect, or allow administrator-defined policies?

    If possible, could you also provide a minimal example of the state machine for this scenario in pseudo-code, and explain how your approach differs from OpenSSH’s Packet/Dispatch architecture?

    This scenario is outside the scope of Marix.

    Marix is a desktop SSH client frontend.
    It does not implement the SSH protocol, cryptographic primitives, KEX state machines,
    packet framing, or cipher negotiation logic.

    All items you listed — KEX re-exchange semantics, replay protection, hybrid
    post-quantum KEX, side-channel resistance, and MITM downgrade handling —
    are properties of the underlying SSH protocol implementation and the server,
    not of the GUI client consuming them.

    Marix delegates these responsibilities to established SSH libraries and the server-side SSH daemon,
    in the same way other SSH GUI clients do.

    Comparisons with OpenSSH’s internal packet/dispatch architecture are therefore not applicable.
    If your environment requires client-side protocol-level control, formal cryptographic agility,
    or post-quantum experimentation, a custom SSH implementation or OpenSSH itself is the correct tool.

    Marix does not claim to address this threat model.

  • uhuuhu Member

    Oh well, I asked Deepseek for a question that might burn through your LLM tokens. :)

  • Can this robot stop using LLM to reply?

    Thanked by 1forest
  • ralfralf Member
    edited January 25

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

    Your LLM is stuck repeating the same things. And not answering the questions. The questions are:

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    To be clear and transparent:

    Marix does not currently provide formal security assessment documents,
    threat models, or audited outbound-connection inventories.

    You outright told us that it did.

    @marix said:
    For clarity:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).

    Why would you tell us that all application-level outbound connections were documented if none of them are?

    @marix said:
    This is intentional.

    And that is exactly why nobody should trust this software to be secure..

    Marix is an open-source desktop SSH client, not a security product,
    and it does not claim to meet the standards of formally audited or certified software.

    You have been making claims since the very first post as to its security.

    The project documents:

    • what functionality it provides,
    • what features are user-initiated,
    • and that it performs no telemetry or background data exfiltration.

    It also downloads code from the internet and runs it with no user intervention.

  • marixmarix Member

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

    Your LLM is stuck repeating the same things. And not answering the questions. The questions are:

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    To be clear and transparent:

    Marix does not currently provide formal security assessment documents,
    threat models, or audited outbound-connection inventories.

    You outright told us that it did.

    @marix said:
    For clarity:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).

    Why would you tell us that all application-level outbound connections were documented if none of them are?

    @marix said:
    This is intentional.

    And that is exactly why nobody should trust this software to be secure..

    Marix is an open-source desktop SSH client, not a security product,
    and it does not claim to meet the standards of formally audited or certified software.

    You have been making claims since the very first post as to its security.

    The project documents:

    • what functionality it provides,
    • what features are user-initiated,
    • and that it performs no telemetry or background data exfiltration.

    It also downloads code from the internet and runs it with no user intervention.

    To clarify one factual point:

    Marix does not download arbitrary code from the internet and execute it.
    There is no remote code execution, dynamic script loading, or self-updating logic
    that runs unverified code without user consent.

    If you believe otherwise, please point to:

    • the exact code path,
    • the URL involved,
    • and the execution mechanism.

    Absent concrete evidence, this is an unsubstantiated accusation.

  • ralfralf Member

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

    Your LLM is stuck repeating the same things. And not answering the questions. The questions are:

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    To be clear and transparent:

    Marix does not currently provide formal security assessment documents,
    threat models, or audited outbound-connection inventories.

    You outright told us that it did.

    @marix said:
    For clarity:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).

    Why would you tell us that all application-level outbound connections were documented if none of them are?

    @marix said:
    This is intentional.

    And that is exactly why nobody should trust this software to be secure..

    Marix is an open-source desktop SSH client, not a security product,
    and it does not claim to meet the standards of formally audited or certified software.

    You have been making claims since the very first post as to its security.

    The project documents:

    • what functionality it provides,
    • what features are user-initiated,
    • and that it performs no telemetry or background data exfiltration.

    It also downloads code from the internet and runs it with no user intervention.

    To clarify one factual point:

    Marix does not download arbitrary code from the internet and execute it.
    There is no remote code execution, dynamic script loading, or self-updating logic
    that runs unverified code without user consent.

    If you believe otherwise, please point to:

    • the exact code path,
    • the URL involved,
    • and the execution mechanism.

    Absent concrete evidence, this is an unsubstantiated accusation.

    You yourself told us it downloads updates:

    @marix said:

    • update/version checks
  • marixmarix Member

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

    Your LLM is stuck repeating the same things. And not answering the questions. The questions are:

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    To be clear and transparent:

    Marix does not currently provide formal security assessment documents,
    threat models, or audited outbound-connection inventories.

    You outright told us that it did.

    @marix said:
    For clarity:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).

    Why would you tell us that all application-level outbound connections were documented if none of them are?

    @marix said:
    This is intentional.

    And that is exactly why nobody should trust this software to be secure..

    Marix is an open-source desktop SSH client, not a security product,
    and it does not claim to meet the standards of formally audited or certified software.

    You have been making claims since the very first post as to its security.

    The project documents:

    • what functionality it provides,
    • what features are user-initiated,
    • and that it performs no telemetry or background data exfiltration.

    It also downloads code from the internet and runs it with no user intervention.

    To clarify one factual point:

    Marix does not download arbitrary code from the internet and execute it.
    There is no remote code execution, dynamic script loading, or self-updating logic
    that runs unverified code without user consent.

    If you believe otherwise, please point to:

    • the exact code path,
    • the URL involved,
    • and the execution mechanism.

    Absent concrete evidence, this is an unsubstantiated accusation.

    You yourself told us it downloads updates:

    @marix said:

    • update/version checks

    Checking for updates or fetching version metadata is not the same as downloading and executing code.

    Marix performs version/update checks (metadata only).
    It does not download executable code, dynamically load scripts, or execute remote content.

    Equating “version checks” with “remote code execution” is technically incorrect.
    If you are claiming code execution, please point to the actual code download and execution path.

    Absent that, this remains a false equivalence.

  • ralfralf Member

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

    Your LLM is stuck repeating the same things. And not answering the questions. The questions are:

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    To be clear and transparent:

    Marix does not currently provide formal security assessment documents,
    threat models, or audited outbound-connection inventories.

    You outright told us that it did.

    @marix said:
    For clarity:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).

    Why would you tell us that all application-level outbound connections were documented if none of them are?

    @marix said:
    This is intentional.

    And that is exactly why nobody should trust this software to be secure..

    Marix is an open-source desktop SSH client, not a security product,
    and it does not claim to meet the standards of formally audited or certified software.

    You have been making claims since the very first post as to its security.

    The project documents:

    • what functionality it provides,
    • what features are user-initiated,
    • and that it performs no telemetry or background data exfiltration.

    It also downloads code from the internet and runs it with no user intervention.

    To clarify one factual point:

    Marix does not download arbitrary code from the internet and execute it.
    There is no remote code execution, dynamic script loading, or self-updating logic
    that runs unverified code without user consent.

    If you believe otherwise, please point to:

    • the exact code path,
    • the URL involved,
    • and the execution mechanism.

    Absent concrete evidence, this is an unsubstantiated accusation.

    You yourself told us it downloads updates:

    @marix said:

    • update/version checks

    Checking for updates or fetching version metadata is not the same as downloading and executing code.

    Marix performs version/update checks (metadata only).
    It does not download executable code, dynamically load scripts, or execute remote content.

    Equating “version checks” with “remote code execution” is technically incorrect.
    If you are claiming code execution, please point to the actual code download and execution path.

    Absent that, this remains a false equivalence.

    So, when it downloads an upload, that's just for fun and that update never gets executed?

  • marixmarix Member

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:

    @ralf said:

    @marix said:
    @ralf said:

    @marix said:
    It is proven by clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Please provide evidence of having clearly defining trust boundaries, threat models, and verifying the behavior of code paths under the application's control.

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    For clarity, Marix is an open-source desktop SSH client, not a formally audited security product.

    Its security posture is based on:

    • well-known, widely used libraries,
    • clearly scoped application-controlled behavior,
    • and transparency of all outbound connections initiated by Marix’s own code.

    Marix does not claim to provide formal threat modeling, penetration testing, or third-party security audits.
    That level of assurance is not claimed, implied, or advertised.

    Platform-level network behavior (Chromium, OS DNS resolution, OCSP/CRL, TLS trust checks) is explicitly outside application control and is inherited from the underlying platform, as with any Electron-based application.

    If this level of assurance is insufficient for your threat model, the appropriate response is simply not to use the software.

    Further repetition of labels without concrete, reproducible findings does not advance a technical discussion.

    Your LLM is stuck repeating the same things. And not answering the questions. The questions are:

    Marix documents and constrains all application-controlled outbound behavior.

    Please point us to this documentation

    Any outbound connection created by application code is documented.

    Please point us to this documentation

    Connections originating from the OS, Chromium, DNS resolution, or certificate validation are outside the application’s control and are part of the underlying platform’s security model.

    That's not true.

    Cloud integrations (Cloudflare, Google APIs) are strictly user-initiated and require explicit OAuth consent.
    No telemetry, no background data exfiltration, no hidden endpoints.

    That's not true.

    Connections created by Chromium / OS subsystems (DNS resolution, OCSP, CRL, TLS trust checks) are outside application control and identical to other Electron apps, including VS Code.

    And again, please point us to where it is documented what these are for

    Labels and speculation are not a security assessment.

    You keep repeating this. You still haven't done any security assessment.

    To be clear and transparent:

    Marix does not currently provide formal security assessment documents,
    threat models, or audited outbound-connection inventories.

    You outright told us that it did.

    @marix said:
    For clarity:
    Marix documents all application-level outbound connections that are explicitly initiated by its own code (e.g. optional version metadata fetches).

    Why would you tell us that all application-level outbound connections were documented if none of them are?

    @marix said:
    This is intentional.

    And that is exactly why nobody should trust this software to be secure..

    Marix is an open-source desktop SSH client, not a security product,
    and it does not claim to meet the standards of formally audited or certified software.

    You have been making claims since the very first post as to its security.

    The project documents:

    • what functionality it provides,
    • what features are user-initiated,
    • and that it performs no telemetry or background data exfiltration.

    It also downloads code from the internet and runs it with no user intervention.

    To clarify one factual point:

    Marix does not download arbitrary code from the internet and execute it.
    There is no remote code execution, dynamic script loading, or self-updating logic
    that runs unverified code without user consent.

    If you believe otherwise, please point to:

    • the exact code path,
    • the URL involved,
    • and the execution mechanism.

    Absent concrete evidence, this is an unsubstantiated accusation.

    You yourself told us it downloads updates:

    @marix said:

    • update/version checks

    Checking for updates or fetching version metadata is not the same as downloading and executing code.

    Marix performs version/update checks (metadata only).
    It does not download executable code, dynamically load scripts, or execute remote content.

    Equating “version checks” with “remote code execution” is technically incorrect.
    If you are claiming code execution, please point to the actual code download and execution path.

    Absent that, this remains a false equivalence.

    So, when it downloads an upload, that's just for fun and that update never gets executed?

    There is no “upload”.

    Marix performs a version/update check only.
    No executable update is downloaded, replaced, or executed automatically.

    If, in the future, an update mechanism is introduced, it would:

    • download a signed binary,
    • require explicit user confirmation,
    • and replace the application only via the standard installer process.

    At present, there is no code download or execution occurring.
    Continuing to conflate metadata checks with executable updates is incorrect.

  • ralfralf Member

    So, in summary - all of the many outbound requests are either ones under your control that you haven't documented by design, even though you earlier stated you had documented them, or ones that you have no idea what they are? Got it.

    Thanked by 1forest
  • marixmarix Member

    @ralf said:
    So, in summary - all of the many outbound requests are either ones under your control that you haven't documented by design, even though you earlier stated you had documented them, or ones that you have no idea what they are? Got it.

    That summary is incorrect.

    There are two distinct categories:
    1) Outbound connections explicitly initiated by Marix application code.
    These are known, limited in scope, and intentionally minimal.

    2) Outbound connections initiated by the underlying platform
    (OS, DNS resolution, OCSP/CRL, TLS trust checks, Chromium internals).
    These are understood, but not controlled or enumerated by the application.

    “Outside application control” does not mean “unknown”.
    It means “not part of the application’s threat surface”.

    Conflating these two categories is a false characterization.

  • ralfralf Member

    Conflating this app with safe is a false characterization.

  • Lets confuse the AI.

    @marix said: there is no code download or execution occurring.

    Why is your code placed on GitHub?

  • marixmarix Member

    @ralf said:
    Conflating this app with safe is a false characterization.

    Marix has never been described as “safe” or “secure” in an absolute sense.
    It only makes explicit, limited claims about its behavior, not security guarantees.

    Thanked by 2ralf tfgp99
  • @marix said:

    @ralf said:
    Conflating this app with safe is a false characterization.

    Marix has never been described as “safe” or “secure” in an absolute sense.
    It only makes explicit, limited claims about its behavior, not security guarantees.

    Finally the right answer!

    Reguards

    Thanked by 2ralf forest
  • marixmarix Member

    @tfgp99 said:
    Lets confuse the AI.

    @marix said: there is no code download or execution occurring.

    Why is your code placed on GitHub?

    Source code being hosted on GitHub has no relation to whether a compiled application downloads or executes code at runtime.
    Those are two entirely separate concerns.

  • marixmarix Member
    edited January 25

    @tfgp99 said:

    @marix said:

    @ralf said:
    Conflating this app with safe is a false characterization.

    Marix has never been described as “safe” or “secure” in an absolute sense.
    It only makes explicit, limited claims about its behavior, not security guarantees.

    Finally the right answer!

    Reguards

    At this point, the technical discussion is exhausted.
    Marix makes no security guarantees, does not claim formal audits, and only documents application-controlled behavior.
    No concrete vulnerability, exploit path, packet capture, or code-level finding has been presented.
    Repeating labels or mockery does not change that.
    Users with stricter threat models should simply not use the software.

  • ralfralf Member

    GLWS

Sign In or Register to comment.