> In response, Xiao pointed out that the package description can be read by any user who chooses to install the software, and it does mention the scan feature.
Wouldn't be the first (or last) time a Debian maintainer has pulled the "you should read the descriptions of all (hundreds) of your packages (most installed as dependencies)" card in response to a bug report.
If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them.
“the plans and the demolition orders have been on display at the local planning office on Alpha Centauri for fifty of your Earth years. If you can't be bothered to take an interest in local affairs...”
There are probably a non-zero amount of people who are older than 20 who have not read the hitchhikers guide, or don't recall some parts of it. For example, me
For me it’s been about 25, but since this is the opening premise, and a throwback to the opening scene I think it’s probably one of the most memorable.
Ha, you might have better memory than me.
From the opening of the books - I remember more vividly Arthur meeting Ford Prefect and his house being demolished. And vaguely something about a pub?
So I think I remember the gist of the first chapter, but not the actual quotes :)
Plus, there's no reason to assume no one here is under 20. We should be _encouraging_ young people who are interested in tech and privacy, not discouraging people from posting explanations about tangential pop culture references because we think they aren't relevant for people who are older.
It aired on BBC World Service a long time ago. Apparently some guy wrote in from India to complain that robots (ie Marvin) shouldn't be employed in place of human actors. I wonder if he is still around to see how _that_ turned out.
Hitch hikers is by no means a universal cultural reference, and by the way it is 2025. The movie adaptation came out in 2005, 20 years ago. It's entirely possible for lots of people older than 20 to not get that reference.
Also, I know it, it has been translated in my language (French), the movie made out to the theaters, and we even have a well known school named after it (42). So it is known even to non-English speakers.
We're not going to agree on that. The response is clearly there to point to a fig leaf instead of saying 'oh, oops, we will make this more obvious in the UI', the software is working as intended: as a way to gain access to more data.
Note that clipboard data can be just about anything and is a valuable dataset, more so if the source of the data isn't aware of being a source, besides, there is no history so you won't even know what you've lost.
Select to translate is almost a standard feature for translation software. Not sure if the situation gets better now, but back then the software was written, using clipboard as temporary storage is a very robust and maybe the only way to implement such feature.
Trivia: It's likely sending Ctrl+C and reading clipboard to get the selected text. No easy cross-platform API for this lol.
Also note that the software is very old and poorly maintained.
No they could still be just incompetent/negligent rather than malicious. You also forget that they aren't running the translation services, they don't get any data, that's a separate third party you'd have to believe are in on it too. The more important question is if debian is gonna gkick them for it (they should).
That's a separate third party, with which they can be in cahoots, in fact it may not be that they are 'in on it too', it could well be that they are in fact the originators and sponsors of the way this works. Anyway, regardless of who is the culprit it is clear that the response spells 'wont fix' and that translates (in my book at least, pun intended) into 'works as intended'.
It's clearly a defensive excuse, as it is extremely unrealistic to expect final users to read all the docs of all the dependencies of a Linux distro. It's the responsibility of the maintainer to read the subset of docs relevant to the package(s) they're contributing, not the user's.
It could be that they were caught with their pants down and posted an ill-thought response, but I'd lean strongly towards malice with such a poor defense, it borders on confession. Clipboards are one of the most critical privacy/security features, you don't ever want to leak them unintentionally.
Did we already forget about the XZ Utils backdoor? There have to be multiple efforts to infiltrate backdoors in Linux going right now.
> It's the responsibility of the maintainer to read the subset of docs relevant to the package(s) they're contributing, not the user's.
I agree a lot with this. You're supposed to trust your distributions packages. If you can't trust your distro, who can you trust? If you don't, find one you do trust, as that's a viable alternative. If none are trustworthy to you, then the only real option is to become your own package maintainer and have fun with Linux From Scratch.
I disagree; it's basically lawyerspeak for "sucks to be you".
If one is expected to go through all the documentation of both the main package and all dependency packages, and also through whatever specific configuration details to your case, just to be able to catch a specific IMPORTANT detail that's not clearly spelled out in the main package, that's malicious.
"A dependency we use captures your clipboard data and sends it to remote servers"
That sentence right there would kill their userbase, so they omit warning you about it. And on top of the "...user should have read the description..." non-apology, "just split the packages, bro".
Finally, a rational argument from the torch and pitchfork crowd. Xiao is not taking security sensitivities to heart : HTTP?? To China‽ and a dismissive BS answer.
Hanlon's razor applies here, I think. It's just ignorance, not malice. I doubt the maintainer has connection, or was pressured by these two random dictionary websites to include this - nor do I think that they gain any advantage of it.
People need to be on the lookout though, the xz incident showed that FOSS is indeed vulnerable.
Not only is it outdated, the Nolnah's razor (reverse form of Hanlon) is more likely to be true nowadays: "Never attribute to incompetence that which is adequately explained by malice".
Wholesale violations of legal and social norms as the secret sauce that will give your company a leg up? Sure if we get caught the stockholders will have to pay to keep our asses out of jail. But we'll get to keep our share of the loot.
use TLS enabled dictionary service. if there is none, you dont want this feature. at all. make sure they click through something or explicitly enable is even hard as you cannot assume a user understands the impact. they might not understand what it means to send their data over plaintext, or what someone can do with it.
I don't want this feature with TLS either. Sometimes I copy passwords from my password manager to paste into the intended app. I don't want everything that enters my clipboard sent to a third party.
Will the existence or lack thereof excuse the absolute lack of security and privacy this package exhibits? And the lack of interest from the developer?
I think that in today's polarized world, it's very much needed. I think we need to look at each other's fallibilities and failures, and not hate each other for it. But the issue needs to be taken care of, especially since it's known since 2009. It's ridiculous that everyone let if fly for so long.
Yes, but it is a tricky situation when a common tactic is to pretend to be ignorant. For example by "just asking questions". We need more patience and respect in this polarized world but at the same time there are a minority of malicious actors who intentionally abuse any assumption of good faith given
The federal government "exercise[s] exclusive Legislation in all Cases whatsoever, over such District (not exceeding ten Miles square) as may, by Cession of particular States, and the Acceptance of Congress, become the Seat of the Government of the United States."
I definitely consider it a security breach. But I do still think it's ignorance. Debian maintainers let it slide since 2009, so for at least 16 years now (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534731) - are they also malicious? I just think that not enough fucks were given.
Debian maintainers in 2009 did not let it slide, they did fix it in 2009 ... but it came back, twice! (and it seems not many cared about StarDict in 2015 to fix it promptly that time)
> the same kind of problem was reported by Pavel Machek in 2009 and again by "niekt0" in 2015. The 2009 bug was solved by patching the application's default configuration to disable networked dictionaries. That appears to have worked for a time, but the YouDao plugin, which was added in 2016, does not respect the configuration option. The 2015 problem was not fixed until August 6 of this year (although the package was removed from Debian for unrelated reasons for a few months from 2020 to 2021). That fix just removed the stardict_dictdotcn.so plugin, which also sent translation requests to dict.cn and was later subsumed by the YouDao plugin, from the package.
It isn't rare at all for bugs to surface many years later and that doesn't mean whoever was responsible for maintenance to be malicious, it is if the bug was planted on purpose, and there are some examples of that (the xz library saga, for instance). Of course, you could argue that that too was incompetence but that's not how this works: lack of oversight by others does not imply malice on the part of those others for failure to catch the issue.
Stuff like this can fly under the radar for a long time because lots of people will assume how it works without actually verifying that it really works like that.
I completely agree. Also, these people have a lot of other assignment, as I imagine. I, for one, have certainly let things slide in the past that ended up biting me, for whatever reason, malice not included.
I guess the companies receiving all this clipboard traffic are absorbing operational costs to humbly provide this surreptitious service to the world for free, and the package maintainer only wants to help them realize their mission.
Why can't reasonable people disagree here? Surely if the utility of some features might outweigh the security concerns for some people. Making features opt-in instead of opt-out significantly changes their discoverability and usage metrics. On the whole, a translation system that has a feature to translate selected text seems hardly surprising. Similarly, using an online service to improve translation quality and reduce local resource usage also seems reasonable.
Fundamentally, always-online, home-phoning features are the norm, and it should be up to OS distributions to manage security postures such as allowlists for network access. Think something along the lines of "StarDict wants to connect to dict.cn. Allow/Deny?".
They can, but framing this as a mere disagreement is disingenuous: One approach might slightly inconvenience someone, while the other (as was taken here) inflicts irreparable damage.
> Fundamentally, always-online, home-phoning features are the norm,
No. Although common on certain platforms, they are not a fundamental norm in software, nor should they be.
There are dozens of chrome extensions that translate (read: submit to untrusted server) on hover / highlight / context menu / textarea edit / etc. It is implied, that user acknowledges this functionality and accepts the risk. This includes untrusted server (because that's how they proxy requests to Google/Bing/Yandex Translate without exposing API keys).
A moderately popular Chrome extension is frequently bought for tens of thousands of dollars for various purposes, frequently malware injection. They contact extension makers.
I think the bar for trust in terms of evil intent is on the floor.
Illiterate is "inability to read and write" by definition. I know people who submitted bug reports requesting: "hi, I want to use your API, please add wildcard origin header", after getting explanation they propose "ok, JUST add my domain, I'm an opensource contributor, trust me". They ask to remove security features, recognizing them as security features, but only caring about their convenience (like "don't enforce 2fa", "don't warn about untrusted links"). They don't know about defense in depth and even if you explain them, they will skip your explanation, because they can't read.
Such a response is not considered a valid defence under GDPR. You cannot sign away your right to privacy any more than you can sign away your right to life.
I'm not going to fault you for that, but no, you really can not sign away your right-to-life even with assisted death. The process is explicitly tooled around this to ensure that people's rights are not violated. I am not saying that there will never be a mistake made here or even that that has not possibly already happened but in principle your right-to-life is not violated by this procedure, and I realize that I will not be able to convince you otherwise.
That requires a complete re-thinking of your moral framework if you are not familiar with the concept.
Just like for some people gay marriage is inconceivable and results in them being ready to man the barricades and for others it doesn't even move the needle. And then there is abortion and bodily autonomy. Large swathes of humanity are not going to be able to understand the remainder when it comes to those subjects, they all arrive at their own conclusions through a mixture of tradition, religion, philosophy and cultural exposure (media, mostly) as well as peer pressure.
I've long ago decided that the only party that will hopefully be able to get all of those right using an objective frame of reference will be born a few thousand years from now, assuming humanity will make it that far.
> you really can not sign away your right-to-life even with assisted death. The process is explicitly tooled around this to ensure that people's rights are not violated
I’m saying that on a practical level the difference is unobservable. Part of your right to life, in this formulation, is your right to sign it away.
The terminality of a right to life makes it a poor comparison to privacy, which has no comparably-irreversible end state like death.
Please stop this sophistry. Assisted dying is in no way comparable to "signing away your right to life". Even if you want to reduce it to such black and white phrasing (which, quite frankly, makes you come across as an asshole), it's actually asserting ultimate control over your own life. At no point in that process are other people allowed to perform acts not specifically authorized by you.
i agree. if in 2025 ppl dont understand plaintext of user data to places on the net is bad, they should not write code nor be maintainers of oss software -_-.
how many times does everyone need to be totally compromised by some shitty software before people start to care?
innocent individuals each days are suffering hacks and malicious interactions. people are losing their livelihoods. companies are getting shutdown... what more need to happen?? :S
> i agree. if in 2025 ppl dont understand plaintext of user data to places on the net is bad, they should not write code nor be maintainers of oss software -_-.
LLMs are only going to make this worse. We're going to see a plethora of vibe coded slop everywhere.
Malicious intent written in the package description? I would think that really unlikely.
I think it's just a cultural difference. Sogou, a super popular Chinese input program for Windows iOS and Android does the same with everything you type and nobody cares.
I'd say that having terms of service that document your shady behavior whilst at the same time not making this obvious in the UI in any way is a tried and true (corporate) malware pattern.
Just because Microsoft did it that doesn't make it a valid defense, in fact it shows the opposite (after all, they too did not have the best interests of their users at heart). The fact that the recipient of the data sits on the other side of the GFW and that clipboards can contain very interesting data you really should wonder about the intentions of the author, they do not get the benefit of the doubt. In fact, open source software that to all intents and purposes looks like it runs locally but pumps your (private) data out without your consent is a very large red flag to me: it gains access to data that otherwise likely would never be found in the wild. At a minimum this is a fairly serious GDPR violation.
I think so too. It's cultural difference, and ignorance at most. I doubt the maintainer has control over that two random dictionary websites, or was tasked by them to do this or anything like that. They are just a different person, and they didn't give a fuck.
Yes, I do feel strongly about attributing malice to someone who I think didn't warrant it. Especially do I think that they are not malicious, because of the fact that they don't admit to their doing as a security hole, but as functionality. And I do care about security a lot - if this was on my software repository, I'd frankly pull the package until it's fixed.
>why it's not malicious to write and distribute a program that sends passwords and other sensitive information over unencrypted http in 2025
One of the reasons is that it has been like that since at least 2009, so for 16 years.
I'm not defending the bug. It's a glaringly stupid thing to do, and distribute, and it questions the competency of everyone involved. I do maintain that it's not malicious intent.
That doesn’t even address the problem! The package description does mention the scan feature, but not the automatically-send-it-to-a-server-in-plain-text feature.
Sure, if you read the description and the list of plugins and correctly guess how this plugin is implemented, then you can deduce some of it.
I install stuff from Debian's repos for 2 reasons. Convience & trust. And while people do complain when maintainers modify packages behavior, I think people would rather have the send my clipboard contents to someone else to be opt-in. Instead of violating their trust!
I do agree with your point, specially when it is not the first time a package maintained by that guy does non-expected behavior like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010165 (Inappropriate package, modifies other package's (conf) files, should be removed from archive).
I disagree that "modifying other packages' conf files" is a problem. Conf files in general are there for the user to modify, and as the maintainer points out, it shouldn't matter if the user uses vi, joe, emacs or this specific tool to modify them.
The problem in this case is that the package modifies generated files belonging to another package. Making it about conffiles is bad phrasing by the bug submitter.
> If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them.
That used to be viable back in the late 1990s and early 2000s when I first used Debian. It would take an afternoon of going through all the packages in dselect (does anyone here still remember dselect?) and marking the ones you wanted to install, and around the same amount of time going through every option on the kernel's menuconfig to precisely tailor the kernel to your specific hardware configuration (things were much less dynamic back then).
Nowadays, there are simply too many packages and kernel configuration options to go through (also, does anyone still use dselect?).
"If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them."
Another option might be to reduce the amount of software one is "blindly"^1 using and relying upon
For example, I have been making own Linux distribution, not following Linux from Scratch (although that is a useful reference)
This is for both learning but also reliability and robustness purposes (where "robustness" includes ability to recover quickly from losing everything)
IME starting from scratch gives a better appreciation for the "inconveniences" that maintainers must endure
"Inconvenience" may be putting it mildly
Certainly, the inconvenience varies depending on the software
Some software builds even on the most deficient/broken installations
Other software is absurdly difficult to compile, often due to minor oversights, sometimes due to obivous carelessness
The wild inconsistencies from one project to another is itself part of the inconvenience
The ease with which software can be compiled by me, and presumably anyone else, on any computer, including underpowered ones, with minimal dependencies, is among the factors I consider when choosing whether to rely on any particular software
1. Here "blindly" means the user has zero curiosity about where it comes from or how it works
No comment on this particular software or the Debian maintainer
I have up on X11 many years ago
I never liked that Debian maintainers make subjective, opinionated changes to other peoples' software, especially since it seems like the majority of Debian users do not compile from source
"RTFM!" comments comes in flavors and bears nuances. In this case, as another commenter has pointed out, the answer smells fishy.
I have been told to "RTFM!" countless times in many places. Some of them were legitimately the correct answer in that context, in hindsight. Some were knee-jerk reactions like this.
Debian's discussion culture might be a little edgy sometimes, but this has nothing to do with Debian.
Wouldn't be the first (or last) time a Debian maintainer has pulled the "you should read the descriptions of all (hundreds) of your packages (most installed as dependencies)" card in response to a bug report.
If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them.