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
Thanks. Feedback noted.
Reading this thread and it feels like I'm having a brain haemorrhage...
I'm wondering how many tokens he wasted in getting LLM to write the same replies over and over to different questions.
I think we’ve reached the point where there’s nothing new to add.
I’ll stop here. Thanks to everyone who contributed constructively.
Thank you for using the LET helpline.
Please rate your experience from 1-10.
We look forward to helping you again.
@forest important news don't miss!
This conversation really was going in circles.
Looking at it from a developer perspective, I instantly found a vector to do a XSS-Attack. Also why are there exposed Google OAuth credentials? ^^
Hmmm, that sounds like a question for the LLM. Let me give it a quick prompt and see what it says... 😜
Yo @marix, you still have some spare credits to get your Google OAuth credentials removed from Github or are we cool to read your emails?
He doesn't just lack English language knowledge, he straight-up refuses to even use a translator. I believe he's copy-pasting replies here into the LLM and asking it to respond, not asking the LLM to translate his arguments.
This is hilarious. This poor guy has no idea what he's doing. I'd sooner trust a junior software dev to write an entire OS kernel in C than trust this guy to write a wrapper over SSH in a memory-safe language.
Kernel development? There’s a surprising number of websites that don’t even perform server side validation (mediation be like: ??). Even worse, I found an “app” last week that was running a development build. Probed around for 20 minutes and got the app to throw an exception.
I was greeted with LLM code comments dumped in a stack trace lol
Edit: spelling/grammar
A lack of server-side validation is a great way to get "premium" content when the only barrier is a JavaScript check to determine if you have some "premium" account, and all you have to do is something trivial like append "HD.mp4" to the video URL. I suppose it's not a big deal for them, since it would take a critical mass of people knowing how to do that to actually take away their source of income.
I suppose it feels easy given many of us (on LET, or in the niche) have likely implemented similar things in the past.
Definitely. Well, for sites that do allow this, "premium" is a bit questionable, haha.
On the subject of validation, crap like "
GET->POST/PUT(then treating values received by the client as trusted)" make me wonder about the whole state of LLM vibe-coding/assistants. Some apps make it more difficult with GraphQL queries/custom APIs, but once you understand how, it fundamentally boils down to - in one way or another - intercepting requests based on some pattern + mocking response bodies...Anyway, I'll finish off with a small gag:
[...] - Copy (n).[ext](I can imagine Cybersec. consultants ripping individual hairs out seeing this practice)Edit: I just took a look at the OP's SSH client....
If you’ve identified a concrete XSS vector, please provide the exact file, code path, and a reproducible payload so it can be reviewed properly.
Regarding Google OAuth: the repository contains a public OAuth Client ID, not a client secret. Client IDs are intentionally public by design and do not grant access to user data on their own. No OAuth client secrets are exposed.
If you believe otherwise, please point to the specific credential and explain the impact.
I’m going to step away from this thread.
If anyone has a concrete, reproducible security issue, feel free to open a proper report.
DM'ed.
You probably shouldn't be reporting bugs to him. He seems to think that his application is secure unless someone has pointed out a specific bug. I've already found almost half a dozen severe security issues, but if I were to report them, then he'd think his application is secure again and would never learn.
If anyone has concrete security findings, responsible disclosure channels are available.
Claims without disclosure aren’t actionable.
I feel like if we respond with enough detailed ai slop we can make their ai think that we are right and that it's insecure
Claims without disclosure are absolutely actionable. You, being completely new to security (or rather, your dataset being trained by people completely new to security) and thinking that action is nothing more than fixing security bugs, clearly do not know that.
Security concerns are always valid to discuss.
However, code changes require concrete findings: a specific bug, code path, or reproducible issue.
General distrust or speculation is not something I can meaningfully act on.
At this point, I’ll step back from this thread.
You've said you are stepping back from the thread numerous times. Perhaps you need a bigger token window to remember? Anyway, no one is talking about specific code changes but about problems with the entire design paradigm that cannot be solved with a quick patch. And unfortunately, sometimes the only way to meaningfully act on changes is to step back and realize that you are way, way in over your head and instead learn the fundamentals before continuing.
I understand your position.
At this point, it’s clear we have fundamentally different threat models and expectations.
I’ll focus on improving the project rather than continuing a discussion that’s no longer technical.
I'm no security expert or power user, but thanks very much to those here who raised detailed questions about @marix and their project.
They popped up out of nowhere with "fully formed" software to manage our SSH keys.
So I checked how recently @marix registered here and I perused their GitHub. My first non-expert thoughts were, in order, "nation-state actor" and "black hat/wannabe".
Their responses and attitude toward questions and challenges here so far have done nothing to dispel my initial impressions.
Thanks for sharing your perspective.
To be clear, Marix is an open-source desktop SSH client. All source code, build scripts, and dependencies are public and reviewable on GitHub.
Security assessment should be based on concrete, reproducible technical findings:
– specific code paths,
– verifiable behaviors,
– or demonstrated vulnerabilities.
Speculation about motives, background, or “how quickly software appeared” is not a technical security evaluation.
If Marix does not meet your trust model, the correct decision is simply not to use it. Others are free to audit, fork, or inspect the code themselves.
相对而言，上面有的网友的说法是可以接受/容易理解的，比如有人说，这个开源工具发到hostloc等mjj集中的社区比较好。
我认为，mjj集中的部分社区，大家对于功能和特色会比较在意，而在let大家对于稳定性和安全性这些非表面的因素更加在意和执着。
Relatively speaking, some of the above netizens' opinions are acceptable/easier to understand. For instance, someone suggested that this open-source tool would be better suited for communities like hostloc where tech enthusiasts gather.
I believe that in certain communities dominated by tech enthusiasts, users tend to focus more on features and functionality. In contrast, on let, users place greater emphasis on and are more particular about non-surface-level factors like stability and security.
Translated with DeepL.com (free version)
Thanks for the fair observation.
I agree that different communities prioritize different things.
Marix is primarily built for developers who value productivity and convenience, while remaining transparent about its behavior.
For users with extremely strict threat models, traditional tools like OpenSSH may indeed be a better fit.
Except you ignore them all, saying they're not actionable.
Only because you don't have a clue how that code works and you need to be able to give it to the LLM in a prompt to get anything fixed.
Spend some time learning how to code instead of how to ask an LLM to do it, and maybe you'll gain that ability.
I bet you don't.
Thanks for your perspective.
At this point, the discussion has moved away from concrete technical findings and into speculation about intent and authorship, which isn’t productive.
Marix remains open-source, reproducible, and open to responsible disclosure via documented channels.
If specific, reproducible security issues are identified, I’m happy to address them.
Otherwise, I agree it’s best to step back.
You still replying...