> If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.
I want secure messaging, not encrypted SMS.
I want my messages to sync properly between arbitrary number of devices.
I want my messaging history to not be lost when I lose a device.
I want not losing my messaging history to not be a paid feature.
I want to not depend on a shady crypto company to send a message.
I seriously don't care what messenger you use, as long as it isn't email, which can't be made secure. Pick something open source. It'll be less secure than Signal, but way more secure than email.
Then your next best bet is Matrix.org. Not to the same security standard as Signal, but if you don't have a specific threat against you then it's fine.
Pros of Matrix: it actually has a consistent history (in theory); no vendor lock-in.
Cons of Matrix: encryption breaks constantly. Right now I’m stuck in a fun loop of endlessly changing recovery keys: https://github.com/element-hq/element-web/issues/31392
I’m facing it on Element Desktop, but I’ll try to reproduce it on Element Web. I’ve tried to submit logs from Element Desktop, but it says that `/rageshake` (which I was told to do) is not a command. I’m happy to help with debugging this, but I’m not sure how to submit logs from Desktop.
Something like this happens basically every time I try to use Matrix though. Messages are not decrypting, or not being delivered, or devices can’t be authenticated for some cryptic reason. The reason I even tried to use Element Desktop is because my nheko is seemingly now incapable of sending direct messages (the recepient just gets infinite “waiting for message”).
Weird. Encryption these days (in Element Web/Desktop and Element X at least) should be pretty robust - although this whole identity reset thing is a known bug on Element Web/Desktop. You can submit debug logs from Settings: Help & About: Submit Debug Logs, and hopefully that might give a hint on what's going wrong.
"If you do decide to opt in to secure backups, you’ll be able to securely back up all of your text messages and the last 45 days’ worth of media for free."
If you have a metric fuckton of messages, that does cost money, sure, but as they say:
"If you want to back up your media history beyond 45 days, as well as your message history, we also offer a paid subscription plan for US$1.99 per month."
"This is the first time we’ve offered a paid feature. The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive. As a nonprofit that refuses to collect or sell your data, Signal needs to cover those costs differently than other tech organizations that offer similar products but support themselves by selling ads and monetizing data."
If you want Signal to host the encrypted storage, that costs money. If you don't want to pay Signal money, they provide 45 days of backup for free.
If you want to self-host your own backups (at your own cost), that's easy to do.
> You don't have to use it like "encrypted SMS"! You're free.
Using it as something more than encrypted SMS requires persistent message history between devices.
> metric fuckton of messages
“More than 45 days” is a metric fuckton? Seriously?
> If you want Signal to host the encrypted storage, that costs money. If you don't want to pay Signal money, they provide 45 days of backup for free.
I don’t want Signal to store my messages. I want Signal to not lock in my messages on their servers, so I can sync them between my devices and back them up into my own backups.
> If you want to self-host your own backups (at your own cost), that's easy to do.
Except there’s no way to move it between platforms. I have more than one device.
> Are you referring to MobileCoin? That feature isn't in the pipeline for sending messages.
I don’t want shady crypto company to hold my data hostage, and there’s no way to store it on my hardware and then move it between platforms. That’s my problem with signal.
> A Synchronized Start for Linked Devices
It only properly transfers 45 days. You can’t have more than one phone. Phones are special “primary devices” and AFAIK you can’t restore your messages if you lose your phone even if you have logged-in Signal Desktop.
Yes, if your only device is a single Android phone you can do that. You can’t, however, use that backup to populate your message history on other platforms.
I’ve already lost message history consistency because one of my devices was offline for too long. The messages are there on my other device, but Signal refuses to let me copy my data from one of my devices to another. Signal is, quite literally, worse at syncing message history than IRC — at least with IRC I can set up a bouncer and have a consistent view of history on all of my devices, but there’re no Signal bouncers.
Look, if defending "message history consistency" is a reason you're choosing some other secure messenger rather than Signal, then I don't think this argument is very productive; use some other secure messenger then. But if "message history consistency" is a reason you're endorsing encrypted email over Signal, you're committing malpractice.
The point is that whatever secure messenger you use, it must plausibly be secure. Email cannot plausibly be made secure. Whatever other benefits you might get from using it --- federation, open source, UX improvements, universality --- come at the cost of grave security flaws.
Most people who use encrypted email are doing so in part because it does not matter if any of their messages are decrypted. They simply aren't interesting or valuable. But in endorsing a secure messenger of any sort, you're influencing the decisions of people whose messages are extremely sensitive, even life-or-death sensitive. For those people, federation or cross-platform support can't trump security, and as practitioners we are obligated to be clear about that.
I’m definitely not “commiting malpractice” on account of not being a security practicioner. I’m talking from a perspective of a user.
It’s important to me — as a user — that a communication tool doesn’t lose my data, and Signal already did. Actual practicioners keep recommending Signal and sure, I believe that in a weird scenario where my encryption keys are somehow compromised without also compromising my local message history, Signal’s double-ratchet will do wonders — but it doesn’t actually work as a serious communication tool.
It’s also kinda curious that while the “email cannot be made secure” mantra is constantly repeated online, basically every organization that needs secure communication uses email. Openwall are certainly practicioners, and they use PGP-over-email: are they commiting malpractice?
> but it doesn’t actually work as a serious communication tool.
Say more. Plenty of people use Signal as a serious communication tool.
> Openwall are certainly practicioners, and they use PGP-over-email: are they commiting malpractice?
They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them.
It’s not malpractice to LARP: plenty of people love getting out their physical or digital toys and playing pretend. But if you’re telling other people that your foam shield can protect them from real threats, you are lying.
> Say more. Plenty of people use Signal as a serious communication tool.
I did say more already. Maybe you believe in serious communication tools that can’t synchronize searchable history between devices, but I don’t.
> They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them.
Are we talking about the same Openwall? Are you aware what Openwall’s oss-security mailing list is? Please, do elaborate how nobody cares about getting access to an unlimited stream of zerodays for basically every Unix-like system.
At this point you're just repeating the argument you made upthread without responding to any of its rebuttals. That's fine; I too am comfortable with the arguments on this thread as they stand. Let's save each other some time and call it here.
I’m very familiar with oss-security, a public mailing list that doesn’t really have anything to do with GPG-encrypted emails. Encrypting emails to a public mailing list, with GPG or otherwise, wouldn’t really make sense.
> Only use these lists to report security issues that are not yet public
> To report a non-public medium or high severity 2) security issue to one of these lists, send e-mail to distros [at] vs [dot] openwall [dot] org or linux [dash] distros [at] vs [dot] openwall [dot] org (choose one of these lists depending on who you want to inform), preferably PGP-encrypted to the key below.
Yes, that would be an example of LARPing security. The obviously indicator is that encrypting your message is entirely optional, per their own instructions. The less obvious bit is that even if you encrypt your message, anyone without GPG configured who replies has stripped any attempt at encryption from the contents.
Very few organizations need security from state level or similar threats and the infrastructure provider. Most organizations that want secure email don't use any kind of e2ee at all, they just trust Google or Microsoft or whomever.
The few jobs that actually care about this stuff, like journalists, do use signal.
Openwall doesn't get security via pgp, it gets a spam filter.
> some Element users are still stuck on the Classic app, unaware that Element X exists
This sounds really arrogant. Element X _still_ lacks a lot of features, saying that the only reason to use classic Element is that you must be unaware of Element X completely ignores that. I wish “Element Creations Ltd” was as aggressive in creating Element X as they are in pushing it.
At least a while ago Element X broke bridging in a pretty annoying way, since all chats with more than 2 members were classified as groups, even if they were marked as DMs.
> Also, for OP: Do you mean "access to the system it runs on"? Because I'm pretty sure it doesn't run with "SYSTEM" access (as in privileged user).
Yeah, I mean “access to the system”. It’s not the same as using headless chrome, because it gives you ActiveX and you can shell out to an arbitrary command.
Is this LLM-generated? The style is somewhat off (long lists repeating the same thing over and over, calling random meta statements “theorems”), and the link to the repo is completely broken.
Hi! Could you elaborate on the first attack scenario?
> Target: Python package managers using tokio-tar (e.g., uv). An attacker uploads a malicious package to PyPI. The package's outer TAR contains a legitimate pyproject.toml, but the hidden inner TAR contains a malicious one that hijacks the build backend. During package installation, the malicious config overwrites the legitimate one, leading to RCE on developer machines and CI systems.
It seems to imply that you’re already installing a package uploaded by a malicious entity. Is the vulnerable workflow something like “you manually download the package archive, unpack it with system tar, audit all the files and then run uv install, which will see different files”?
Someone could release a malicious package that looks okay to a scanner tool, but when installed using uv can behave differently, allowing attackers to masquerade executable code.
In addition, for OCI images, it is possible to produce an OCI image that can overwrite layers in the tar file, or modify the index. This could be done in a way that is undetectable by the processor of the OCI image. Similar attacks can be done for tools that download libraries, binaries, or source code using the vulnerable parser, making a tar file that when inspected looks fine but when processed by a vulnerable tool, behaves differently.
It is possible to exploit this bug by crafting a file that has tar contents without a header, thus making it hard to detect even with recursive archives.
I’m still not sure how do you even compromise a key without also compromising message history. The keys are stored on-device, along with associated history. If attacker has access to the keys, they also have access to all the previous messages stored on the same device. Unless you’re using auto-delete with short period on all your messaging, which I would think is not common, it would seem that you gain nothing by ratcheting.
I want secure messaging, not encrypted SMS. I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device. I want not losing my messaging history to not be a paid feature. I want to not depend on a shady crypto company to send a message.
reply