HN user
Email: hello at germano.dev
[ my public key: https://keybase.io/tyrion; my proof: https://keybase.io/tyrion/sigs/Eo63KyrhVb5QpfiBnVMlsuDirgA7kKYlBOXdg8WV5_o ]
Some years ago I thought it would be interesting to develop a tool to make a python script automatically install its own dependencies (like uvx in the article), but without requiring any other external tool, except python itself, to be installed.
The downside is that there are a bunch of seemingly weird lines you have to paste at the begging of the script :D
If anyone is curios it's on pypi (pysolate).
Helping improve the spec and all is great, but being 100% honest, as a user, I would rather have a type checker I can bend to my needs. As you said, some code patterns in a dynamic language like Python are difficult, or even impossible, to type-check without custom code. Type checkers are becoming more popular than ever, and this implicitly means that these code patterns are are going to be discouraged. On one hand, I believe the dynamism of Python is core to the language. On the other, I would never want to write any collaborative piece of software without a type checker anymore. Therefore, to get the benefits of a type checker, I am occasionally forced to write worse code just to please it.
Considering how fast uv and ruff took off, I am sure you are aware of the impact your project could have. I understand that supporting plugins is hard. However, if you are considering adding support for some popular libraries, IMHO, it would be really beneficial for the community if you could evaluate the feasibility of implementing things in a somewhat generic way, which could be then maybe leveraged by third-party authors.
In any case, thanks for all the amazing work.
This was brought up in one of the previous discussion on HN [1], and people found out that indeed this project seem to have copied the original coreutils. There were some name of variables/constants taken from the original code [2]. Also, I am not implying that they are violating copyright (as someone else said, not doing a clean-room implementation does not necessarily imply violating the original license). However, I find it very sad that they replaced the license and are effectively damaging the GNU project. (It is also a bit sad to see your comment, which expresses a perfectly valid concern, down-voted).
I wonder what is the official position of the GNU project about this though.
More than the limit, what seems absurd to me is that businesses seem to be allowed to refuse cash as a form of payment. I am reading the translated version of the article, and it says:
A seller can decide not to accept cash above a certain amount. Or not accepting cash at all.
Why would not accepting cash at all be allowed? What is the other alternative? Mastercard, visa etc? If for example, a super market chain stops accepting cash and starts accepting only Visa, and for whatever reason I do not have a visa credit card, or worse I am banned by Visa,then I cannot buy groceries anymore? Also, I am not exactly sure everybody has access to a credit card. Maybe I am missing something here, but this seems a bit stupid/crazy to me.
there's never place to discuss the elephant in the room, that the whole game is rigged. The backdoor massive, right in front of us, and nobody's doing anything to fix it
I am tempted to take the bait, and ask you what would be this massive backdoor, which nobody has time to discuss. If I am guessing right, you are still referring to "no default E2EE". In that regard, I would encourage you to consider that not everybody has the same security requirements, and many people are fine trusting Telegram and with the security it provides.
Personally, I cannot wait for Matrix to become more widely adopted, and to see the UI/UX of their clients to become remotely comparable with the one of Telegram.
Anyway, since it doesn't seem our discussion is going anywhere, maybe it's time to stop.
Thank you for the chat, I liked how we managed to stay polite even though we completely disagree :)
Given that you wrote your article before Signal had even desktop clients, I don't think it's even remotely up to date to vouch for any kind of fruitful discussion
Yeah, I intentionally did not want to compare it to Signal (because the article was already too long that way).
Let's recap what is happening here, because we are going a bit off-track with this discussion.
My original post was about the fact that I am tired of media outlets making borderline denigratory titles all the time about Telegram.
You replied, stating that I claimed that "Telegram is secure", which I did not do. Then, I tried to clarify my original post.
Then you claim that these vulnerabilities show that "Telegram authors don't have the know-how on how to implement secure protocols". I asked you to back your claim, because I don't see how the discovery of a bunch of "almost impossible to carry out in practice" vulnerabilities might imply that Telegram's engineers are incompetent.
To which you reply that "Telegram isn't end-to-end encrypted by default". Now, unless I am missing something obvious here, you just stated a fact that has no relevance whatsoever with your former claim. The claim to prove was "Trivial vulnerabilities discovered --> Telegram authors are incompetent". Now, if you changed your mind, and want instead to argue that they are incompetent because they did not implement e2ee by default, it's a totally different discussion and has no relation at all with my original post, nor with the article we are commenting (imo).
Finally, I'm a bit puzzled, you seem to be "open minded" yet your post didn't even touch on this massive issue of failure to provide E2EE for groups, desktop clients, or anything by default. Were you unaware of it?
I am aware of how Telegram works. But why do you suggest I should have talked about this? It is totally unrelated to my original point.
Or would you argue the endless list of competition that actually does E2EE properly (Signal, Wire, Threema, Element...), over-do security?
I never stated such a thing.
You're also not even remotely interested in agreeing with the academic community
It's not that I am not interested in agreeing with them. I am openly criticizing the behaviour of some of its members. It's a different thing. But also this is a different discussion, and I should not have included that comment, maybe.
"no breaches have been made public, therefore it must be secure".
I did not claim this.
How familiar are you with the field of computer security, do you know how security is quantified?
Please do not patronize me.
Finally, I am not interested in having a discussion that is unrelated with the topic of the article, or my original comment about it (because it would be too long and tiring). However, if you want to know my opinion on all this related issues that you brought up, you can read what I wrote about it here: https://germano.dev/whatsapp-vs-telegram/ (even though this does not talk about Signal or other open source e2ee messengers).
But it is living proof Telegram authors don't have the know-how on how to implement secure protocols
I strongly disagree with this claim. Can you back your claim with some evidence? The vulnerabilities shown here are mostly purely theoretical, I don't see how this goes to show that Telegram engineers are incompetent.
What I see is that Telegram engineers chose to ignore what the Computer Security academic community regards as best practices, and this has led to an infinite amount of criticism (including by the authors of the vulnerabilities we are discussing). Despite this, in ~8 years since launch, the only serious vulnerability which I am aware of, has been discovered and immediately patched right after Telegram was first launched.
I did not claim Telegram to be secure. It has nothing to do with what I said. Moreover, saying that something "is secure" does not make too much sense, without specifying secure against what.
Assuming you are in good faith, I will try to explain better: The title of the article states there are vulnerabilities in the encryption protocol.
According to RFC 4949 a vulnerability is:
A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy.
Clearly stating that there are vulnerabilities in Telegram's encryption protocol raises concerns, a lot of confirmation bias among Telegram haters, and leaves people who only read the titles with the feeling that Telegram encryption is vulnerable to attacks.
However, among the 4 flaws reported by the researchers, 3 are not exploitable ("This attack is mostly of theoretical interest", "Luckily, it is almost impossible to carry out in practice", "Luckily, this attack is also quite difficult to carry out, as it requires sending billions of messages to a Telegram server within minutes") and the other one is about reordering encrypted messages.
Therefore, a more fair headline which would undoubtedly raise less interest could be "Researchers found a way to change the order of your Telegram messages, even if they still cannot read them", or "Researchers found some purely theoretical or almost impossible to carry out vulnerabilities in Telegram's encryption protocol".
And don't even get me started about the fact that literally everybody, including expert security researchers, feel entitled to bash Telegram for having rolled their own crypto at every chance they get.
It is tiring that this keeps happening. These media outlet publish misleading titles and abstracts implying that Telegram is not secure, knowing very well that most people don't even read the articles. I assumed good faith for the first ~100 times, but it is always the same :D
Anyway, wouldn't it be better to link to the academic source ( https://mtpsym.github.io/ ), or at least to remove click bait titles?
It may seem an advantage to use the latest cutting edge features of a single platform, instead of using well established standards which are compatible with every browser. Sure, you are going to leave out some small minority of users, but you gain access to many new features.
However, you are helping push the web become an increasingly centralized place, controlled by just a few entities, with interests which are very different from yours.
You may think that there is no harm in doing so. Most people use Chrome anyway. And what difference can one more web app make?
However, it is exactly this laziness by skilled developers, who are the only that understand the problem, which brought us to the current situation. There is no way to fix this problem, if the people that understand it do not take a stand.
Next time that your manager asks you if you can have that sweet feature, instead of saying "sure, we just need to drop support for Firefox", please consider trying to explain what are the consequences in the long term.
I know this isn't easy for many people, which do not feel comfortable questioning orders or plans. However, this is our responsibility. Nobody else is going to care, if we do not care.
You praise HN because we can have "meaningful" discussions, yet in the next sentence you ask people not to upvote an article just because the author is not great at communicating his thoughts, and makes some grammar mistakes, completely ignoring the "meaning" of the article.
You feel the need to "urge the people" not to upvote it. However, wouldn't it be more "meaningful" to explain why you do (or do not) agree with what is said, instead of just complaining about grammar?
I personally found the article interesting, even though it's poorly written. Instead of ordering others around, what about urging yourself to refrain from commenting unless you have something meaningful to add to the discussion ;)
Meanwhile, in Italy they started rolling out 10 Gb fiber ... https://www.totaltele.com/509173/Open-Fiber-launches-10-Gbps...
The goal of modernizing coreutils is great, and doing it in rust is even better. However, it makes me very sad that this is licensed under the MIT licence.
Being licensed under the GPL is an essential part of the GNU project and their philosophy. Of course everyone is free to do as they please. However, IMHO, if one appreciates the GNU project and the ideals it stands for, then, maybe, it could be preferable not to rewrite parts of it under weaker licences that go directly against their mission!
Thanks for this clarification. I guess I had a wrong assumption about Signal then!
What happened to me is that I lost my phone, so I did not have an Android device to re-install Signal. I later managed to get back the SIM card and I assumed that I could use the Desktop client, but if I remember correctly it did not work. However, I will check again all of this
Hi, thank you!
I'm willing to forgo cloud backups and some usability to have default encryption for all my conversations, which I think is something Signal provides.
Indeed, it does.
None of these apps are perfect, it comes down to what combination of trade-offs works best for you.
That is exactly the take-home message :)
Anyway, I mentioned that Telegram does not support e2ee for group chats here:
WhatsApp nowadays has end-to-end encryption enabled by default for all chats, while Telegram has not enabled it by default and does not support it on group chats.
Note however that group chats are even more difficult to handle securely, because in theory you are supposed to verify the identity of every participant.
Why do you think it is ignored? Feel free to suggest a way to improve the article, if you want :)
In my opinion this is partially addresses in the threat modelling section, where I mention the need to trust "The companies running the servers needed by the app to work".
Anyway I believe the threat you mention is a very difficult one to defend against, because probably even metadata alone is sufficient to construct a graph of relations. So, I maybe wrong, but if you do not want to trust any company at all, then even Signal may not be enough for you in this scenario. Regarding the choice of WhatsApp vs Telegram for this scenario, you simply have to decide if you trust more Facebook (which we already know supplies this kind of mass data to the US government) or the Telegram team. Or you can trust neither.
Yeah, I thought the post was already too long to also talk about Signal!
My opinion on Signal is it should definitely be preferred if one cares about security more than usability. I really cannot wait for it to have a "standalone" client (that is, that does not require the phone to be online as well).
There are other messaging apps, like Element (and the now defunct Keybase) which try to solve the same problems. So, I decided to keep that discussion for another future article (maybe).
It's a shame that every time that Telegram is mentioned, Signal advocates feels the need to let everybody else know how superior Signal is supposed to be compared to everything else.
I don't have anything against Signal itself, but this aggressiveness and arrogance is really putting me off.
Has this became some kind of religion? Do you people realize that you are not the exclusive bearer of Truth, and that maybe, just maybe people that use Telegram chose to do so for a reason and are not poor clueless persons that need to be indoctrinated?
To be extra clear, my complaint is about whoever insists on spreading the falsehood that Signal is objectively better than anything else [and maybe also adds a bit of compassion on top ("it's a shame") for the rest of us unenlightened].
I would have no problem, and would actually be more inclined to switch to Signal, if you tried something a bit more modest and honest. Dunno, for example something along the lines of "If you would like an alternative to Telegram that has E2E enabled by default and on all chats, you could maybe be interested in Signal!". But what kind of discussion can we have if the argument is always "Signal is so much better, it's a shame that you people don't realize it" ?
However they cannot use data that allows to identify an user (such as an IP address) in their analytics, unless the user has granted them explicit consent to use that data for the purpose of analytics.
So my understanding is that there is a big difference between this and "they just don't use third-party analytics".
It would be super nice if they clarified this in the blog post. Maybe by adding something like "We do not use personal data in our analytics".
Not sure about raspberry, but I use Kodi to watch Netflix all the time and it works well :)
This seems really cool!
I am wondering if it can host private repository as well, or is it just meant to host public repositories?
Now I am tempted to set the default branch to "offensive" or "inappropriate" :D
On a more serious note, I can agree that the master/slave terminology is not the best choice of words, but how is the usage of the word "master" in git deemed offensive?
It's not as hard or expensive as you say to find two characters domains on two characters TLDs. You may want to do some better research. Hint: search on hn.algolia for "short domain names" :)
Wouldn't it be a good idea to "fix" the AGPL in order to make it clearer?
It seems to me that every time there is a discussion around GNU licenses many people have no idea how to interpret them and then decide not to use them out of fear. It does not seem to me that this is in the interest of the GNU project. Why not fix this?
The fact that Microsoft keeps saying it wants to move away from C/C++ is great IMHO.
Microsoft c++ continues to be written and will continue to be written for a while
I interpret this as saying that they cannot instantaneously convert all their existing code to Rust, and it seems fair enough. However, it seems a little odd to start new projects in C/C++ when you are publicly saying it's the wrong thing to do.
Infact, just a little over a month ago they announced a new QUIC implementation written in C/C++ (MsQuic)
Is this to be expected since Microsoft is such a big company? Or maybe that lib is not important and is not going to be used in, say, Edge?
Moreover, isn't networking code the worst kind of code to write in C/C++ (I am thinking of heartbleed for example)? I would really love some explanation.
I wonder if the OP could address this point and also give some more context on why he "lost commit access to the main repository". I think it could be useful to make a more informed opinion on the two projects (other than the different goals).
It philosophically makes no sense to call something immoral because a subset of entities are happy to pay for it to achieve their goals.
Paying or not paying has nothing to do with the immorality of proprietary software.
You can pay for software even if it is not proprietary.
I suggest you to watch any talk by Richard Stallman, if you want to understand why some people think proprietary software to be immoral. You might not agree, but for sure it is not something that "philosophically makes no sense".
How is this something that can happen? I mean, the only responsibility of an "authentication" endpoint is to release a JWT authenticating the current user.
At least from the writeup, the bug seems so simple that it is unbelievable that it could have passes a code review and testing.
I suspect things were maybe not as simple as explained here, otherwise this is at the same incompetence level as storing passwords in plaintext :O.
I completely agree. I have no idea why many people seem to be fan of this `curl x | bash` approach.
For pyenv all is needed is to clone their git repository and add a couple of lines to your .bashrc.
Could you explain why it is such a deal-breaker in your opinion?
It is a single `apt-get install` (which probably downloads less MBs than our typical `npm/yarn` install).
Consider that if pyenv came pre-packaged for ubuntu/debian, those packages would be runtime dependencies and then you would just need to `apt-get install pyenv`.