Fundamentally, doesn't the security depend entirely on whether https is working properly? Even the standard package repos are relying on https right?
Like, I don't see how it's different than going to their website, copying their recommended command to install via a standard repo, then pasting that command into your shell. Either way, you are depending entirely on the legitimacy of their domain right?
It is sometimes possible to detect server-side whether the script is being run immediately with `| sh` or not. The reason is that `sh` only reads from its input as far as it got in the script, so it takes longer to get to the end than if you'd curl show the result in the terminal directly (or pipe it to a file).
A server can use this to maliciously give you malware only if you're not looking at the code.
`curl URL | sudo sh` doesn't have a means of verification of what the contents of the URL points to.
Sure a binary can be swapped in other places, but they generally can be verified with hashes and signatures. Also, a plaintext install script often has this problem in another layer of recursion (where the script usually pulls from URLs that the runner of the script cannot verify with this method)
> Fundamentally, doesn't the security depend entirely on whether https is working properly? Even the standard package repos are relying on https right?
They should only need http. You don't need https at all if your package is signed. The package/installer/app/etc could come from anywhere, modified by anyone, at any level. But if it's not signed by the dev's private key (which only exists on their laptop [or hardware token], protected by a password/key manager), it's invalid. This avoids the hundred different exploits between the dev and the user.
What's actually crazy about this is, if you're already making the user do a copy and paste, it doesn't have to be one line. Compare that line above, to:
All you have to do is copy and paste that snippet, and the same thing will happen as the one-liner, except it will only work if the sha256sum is valid. Now this isn't perfect of course, we should be using artifacts signed by a private key. But it's better than just praying.
> Like, I don't see how it's different than going to their website, copying their recommended command to install via a standard repo, then pasting that command into your shell.
Suppose the site got compromised. If you separately explicitly download the install script first, in principle you can review it before running it.
Same deal with installing Python source packages (sdists). Arbitrary code included in the package runs at installation time (with the legitimate purpose of orchestrating any needed build steps, especially for non-Python code, which could be arbitrarily complex). This is worse than importing the installed code and letting it run whatever top-level code, because the entire installation is normally automated and there's no point where you review the code before proceeding. We do generally accept this risk in the Python ecosystem, but demanding to install only from pre-built wheels is safer (it just isn't always possible).
(Pip has the problem that this still happens even if you use its "download" command — because it wants to verify that building the project would produce a package with a name and version that match what it says in the file name and/or other metadata, and because it wants to know what the dependencies are — and in the general case it's permitted to depend on the build process to tell you this, because the system for conditional-on-platform dependencies isn't powerful enough for everyone's use case. See also: https://zahlman.github.io/posts/2025/02/28/python-packaging-...)
Current incident confirms that we can't trust to authors of DuckDB, because they can't evade a trivial phishing attack.
Tomorrow they will do it again, and attackers will replace binary files that users download with this random script. Or this script will steal crypto/etc.
To make attack vector difficult for hackers, it's preferable to download any software as packages. On linux it looks like `apt install python3`.
The benefits is
1. Repositories are immutable, so attacker can't replace binary for specific version, even if they will hack all infrastructure of DuckDB. Remote script may be replaced anytime to run any code
2. Some repositories have strict review process, so there are external reviewers who will require to pass security processes to upload new version
for MacOS they have it in brew, which is also you can use on linux, also it is available in nix.
I think the problem is that there are so many linux distros with their own package repositories, that it is very untrivial task to include package into most of them if maintainers are not proactively interested.
I also don’t know why using a unix pipe instead of saving in the file system and executing the file is a significant security risk. Perhaps an antivirus could scan the file without the pipe.
Do you know about other security issues? If it's only about curl | sh it really isn't a problem, if the same website showed you a hash to check the file then the hash would be compromised at the same time as the file, and with a package manager you still end up executing code from the author that is free to download and execute anything else. Most package managers don't add security.
Recently I've tried Baldur's Gate 3, gameplay looks nice, but options in dialogues written by 12 y.o. kid. It would be nice to talk via LLM that would have the described character personality.
I would like to see it. It's a huge problem with "interactive fiction" in particular that dialogue is all pre-written. What I think of when I think of that paper is how the characters in Overlord use spells like "Charm" and "Dominate" to get NPCs to tell their secrets.
No, thanks. I already spent time to write tests while implementing a features, now I have a lot of tests that proof the feature is works fine, and I no more fear to make changes, because tests keep me safe of regression bugs.
The typical problems of any code base with no tests is a regression bugs, rigid team (because they must keep in mind all cases when code may destroy everything), fear driven development (because even team with zero rotation factor don't actually remember all problems they've fixed).
What is your answer to the points the author makes around flaky tests/changing business requirements/too many tests confirming the same functionality and taking too long to run?
Flaky tests: tests should be deterministic. If your tests are flakey in a 100% controlled environment, probably your real system is unreliable too.
Changing business requirements: business logic should be tested separately. It is expected to change, so if all of your tests include it, then yes of course it will be hard to maintain.
Too many tests for the same thing: yeah then maybe delete some of the duplicates?
Taking too long: mock stuff out. Also, maybe reconsider some architectural decisions you made, if your tests take too long it's probably going to bother your customers with slow behaviour too.
that and, i would argue that npm in particular is filled with lots of small projects and only very few large ones simply by the nature of the ecosystem. it is the wrong place to look. something better would probably be to eg count the contributors on github, or, on npm, analyze project dependencies and distinguish projects that are directly downloaded vs those that are loaded as a dependency. arguably, dependencies can be replaced by the developers of the project using it, so a developer of a dependency disappearing is less dramatic than if you use that project directly.
technically speaking, if you have a large project with many contributors, every contributor is often still only responsible for one small part of the project. linux kernel drivers and subsystems most have their dedicated developers. and very few of them each.
leftpad was a minuscule project that could have been created by anyone. Yet its deletion caused chaos. There are certainly load bearing projects of moderate complexity that are still single person efforts.
right, but the problem here was the deletion of the module, not the disappearance of the maintainer. in the later case the module would have remained, and if it would stop to work because of some incompatibility in a future js, people would replace it
You could also imagine leftpad was using some security compromised library (eg log4j). If the project is of moderate complexity and there is nobody behind the wheel to maintain it, what happens to the ecosystem?
basically, my rule of thumb is that i have to be prepared to take over and maintain any dependency that i use. it's all part of my code. if i am not prepared to do that then i better avoid pulling in the dependency in the first place.
the leftpad example, as it happened, was not a maintainer issue. had the maintainer just stopped working on it, replacing leftpad would have been a no brainer for anyone taking their project seriously. deleting leftpad was deliberate sabotage by the maintainer, even if he may not have predicted the consequences.
i dare say that the leftpad incident would not have affected me because i never deploy live depending on remote resources. everything needed to deploy is cached, and the only time leftpad disappearance would have affected me is when setting up a new project, at which point the failure to build would be an oops, there is a bug, we need to fix it kind of situation.
i don't rely on others such that if they don't do their work my house would come crashing down. if that happens, then that's on me. i rely on things that have been proven to be stable. a maintainer disappearing does not affect the current stability of any of my systems. it only affects future upgrades, and i can deal with those.
even security issues don't necessarily depend on the maintainer such that only the maintainer could fix them. that's the whole point of FOSS, that anyone can fix issues if necessary. in the worst case someone out there would work on a patch to fix the log4j issue, or, remove it as a dependency. if the issue is critical enough for me, then that someone might even be myself.
I have couple open source NPM packages I develop together with other developers. In some of this packages I have less than 50% contributions in code. But I listed as contributor on NPM, just because I found this packages and did not update contributors list a long time.
So definitions does not matter when stats that author refers, does not include a developers who own over 50% code in repo, but includes me as contributor.
That's widely known problem of programmers to believe that world is perfect and all data are always actual. Actually it won't.
It looks like whisper + google translate + google TTS. Typical "quality" for that stack, bad latency, no any privacy.
I'm developer of "Linguist", a browser extension for translation in browser, and I say you that nowadays it is possible to translate text locally in device. Linguist have embedded offline translator. The same with TTS and voice recognition.
All this features may run locally in-device, even in browser extension, but not in macOS application?
This product looks rather like a malware that will spy on users and then blackmail us or sell our conversations to email scammers for better targeting or anything.
Additionally it is interesting that Chinese and Korean languages is not supported. You just use cloud services, they are all support these languages, why you don't? Is it to fake something?
"12 hours translation per month" for $29. 12 hours it's about 6-12 meetings? Who is your audience then?
> The old URL redirects to the new one, so in theory existing posts/backlinks keep working.
We also agreed the original creator wouldn’t reuse the “unity-mcp” repo name under his GitHub profile, which could break redirects.
Why?
A lot of times I faced with page 404 when clicked GitHub links that have been moved.
Isn't it good idea to do it like that
- Move repo to new org (to move stats and activity)
- Create repo with the same name that are fork of a target repo
- Update readme to explain repo was moved
- Archive the repo to place a warning on top of the repo
This way make users have to click link in original github repo, to go on your repo.
So it would be a problem if you need to show a numbers and you need to fake activity. But if you don't need fake activity, it is not a problem, because a real people who really looking for solution will be able to click one more link.
On the other hand, this way ensure that whole content will be available by indexed links.
How to prevent 404 and why people still faces with it on GitHub?
I've always seen the redirect when the repo is moved. The GitHub docs mention the redirect as well. Are you sure you're not seeing another scenario like a fork and the original repo is deleted?
I think those who believe a companies will pay to you for a random OSS is just a kids. Ask people who can use a sheets, they explain you why your product will die with this approach.
No one owes anything to any particular project or developer.
The thing to understand about discussions around funding FOSS projects is that it should be clear that society as a whole would benefit immensely from a strategic investment in commons-based software infrastructure.
A society would owe something to person picking up trash in their free time. But I am pretty sure society will never end up paying even minimum wage for that labour...
It is similar to open source... Something has value and is good for society, but society neither has willingness or ways to reward it.
Where I live in Seattle we fund keeping the streets in good condition. I see city staff roaming around during the day from time to time wearing hi-vis, doing stuff like picking up trash or removing graffiti.
If trash is lying around only getting picked up by generous citizens in their spare time, what that implies is that the city/county have chosen not to invest in maintaining the streets, and the citizens have elected to throw trash everywhere. I don't think we should take either of those conditions as a given. Better things are possible.
Quite interesting that I didn't mention money, but that seems to be the only language many people speak. Anyway, maybe go ask the Blender folks (and I'm quite sure others can provide some more examples)
Also, please read the HN guidelines [0]
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
You don't know anything about me, including my age, nor my motivations or history.
sure. But companies believe that open source developers owe everything to the them (i.e. fixing bugs, contributing to feature requests, critical security releases ...).
Matrix Protocol is overcomplicated and ridiculous. As I understood, the reason of mentioned problem with lack of "online status" feature is a high network load that yields by presence status feature, so server owners just disable this feature.
It is ridiculous that messenger who state it is "privacy focused" - can't handle encryption for bots and sell us idea that it's fine to log-in in my account on random site on internet. Because any site where i enter my password and secret key, may steal my password.
The same thing with applications. "Reference implementation" of app is an Electron app that loads javascript from internet and may inject malware anytime.
My impression is that Matrix is a scam to spy over people who blindly believe in security, like a Telegram does.
The last statement is totally uncalled for. Yes, matrix is not convenient and given it's far from ideal chat experience but that doesn't mean you are allowed to spread FUD. Matrix spec, clients, homeservers, etc are fully open source. No one is "scamming" anyone
No horses in this race for or against the Matrix group, but convenience, adoptability is a fair factor to look at in software, especially collaboration and interaction based software.
Matrix community scam everyone when claim a matrix is a privacy-focused. And you are part of this community who deceive people. The fact that anything is open source is not make it "privacy focused".
Literally everything in Matrix is designed against privacy and security.
Check issue I mention above. The product that is "privacy focused" would never have such type of problems that will force developers to say that lack of encryption for chats is a minor problem that will not be fixed.
your issue is complaining that matrix-bot-sdk can’t exfiltrate encryption keys which predate it joining a room? this feels like a pretty reasonable limitation. if you really need this, use matrix-rust-sdk with MSC4268 enabled.
No, as i wrote in issue title and explained twice in this thread, the problem is bot SDK does not support encryption. It must work by default, for "privacy focused" application. Chat with no encryption must be an option, not default.
Matrix protocol is over-complicated, as consequence any SDK and even clients are over-complicated too, that eventually makes any interaction with Matrix is difficult, unpleasant, and error-prone.
Matrix design is error-prone by its nature:
Keys exchange confuses many users, I had many questions of people who are not programmer.
Matrix encourage login at random sites who up their web client, that is critical security problem.
But a Matrix fans are blind to a problems. This is why I don't believe Matrix will transform from marginal chat for freaks to a mainstream chat where people talk. So eventually, Matrix is a platform where Matrix fans talks about Matrix and send porn to each other.
