The neat part about the first solution is that it works with other built in falsy objects too, so you can do it with Number and use NaN or 0, or with Boolean and make x just false.
They have it on repo level (as go to file, separate search box) and the search bar supports `path:` filter which I think can use globs.
IIRC they do implement Web Key Directory, so if the recipient had WKD set up proton would find the key and allow you to encrypt the message without setup.
But there are very few (the second largest one after Proton being mailbox.org, and I don't think it's enabled by default there) who support it.
(I'll need to look into MLS more, but from a cursory understanding it should be fairly easy to "break" its forward secrecy for this kind of purpose by saving the initial epoch secrets, but I may be wrong about how resilient forward secrecy within epochs is there. I've not found any attempts though)
(because as mentioned you can recover future messages from early state and each client stores the earliest room keys they know...)
So e.g. if Matrix adopts some other encryption scheme, like most likely MLS, if they want to still have this kind of history sharing mechanism they'll have to weaken it
It has... pretty much no backward secrecy (the only way to prevent a device from reading future messages is rotating your session key and sharing it with everyone, which doesn't happen often by design), limited forward secrecy (stopping session compromise from reading past messages)
So in theory once it's implemented (it is already in element web and element x apparently) you should just have all the keys to old messages just after joining a room
Also, notably, this is only possible because Matrix's group E2EE is a lot more limited compared to Signal or even the 1-to-1 version
After reading the newer solution (MSC4268) it seems like it should work better - since it basically frontloads all the work, by having inviter create a full bundle of shared keys they know and essentially send it as an encrypted attachment to each of invitee's verified devices
(so a malicious homeserver could add a device to your account and because the spec didn't even require device verification it could get all these shared keys)
And also, it meant the user who invited you had to be online to send you the keys when you browsed the history or no decryption for you...
And then after joining when you device saw a message it couldn't decrypt it would ask the user who invited them for the older session keys and if they knew them they'd share.
It's honestly a problematic solution because actually each device needs to ask for keys and it turns out user != device
(and each session is not used indefinitely, but replaced on several events - e.g. someone leaving a room)
So from my understanding the old solution (that I apparently missed was entirely withdrawn and that's why it doesn't work) was to add a marking to session keys in rooms with shared history
Pretty much, in Megolm there isn't a global room key, but rather each user creates a session which has a room key that's used to derive per-message keys (and it's a ratchet, so knowing it's current value you can derive future keys but not past ones), and shares that with each device in the group
Hmm... Apologies to Matrix people, I thought I had enabled this toggle but it turns out I can't (I moved homeservers so maybe the new one doesn't support it?), so... Maybe it works if you're able to turn it on (and thinking about this again, people inviting you probably need it turned on too).
Does this work well in practice though? Well... I'm not sure if I haven't seen a correctly configured room or what, but I don't think I've experienced joining an encrypted room and seeing its history yet.
Maybe the WIP MSC4268 will fix this, but I'll believe it when I see it.
No, it's not impossible: Matrix in theory support* having old messages visible and sharing historical keys with newly joined users, so in theory it has everything to make e2ee rooms with history from before joining...
*or at least: a few clients support it, it's not a finished part of the protocol
There's even a lot of stuff that could be found by just running existing non-llm-based tools in ways that produce non-practical levels of false-positives and filtering them The big thing IMO is verifiability - which is something that is very much getting easier with improving abilities to use tools
I have seen a few bugs that I could say required a lot of creativity and luck to get to and I doubt existing LLMs would be able to get them even with a great test setup (iirc one was for example caused by a subtle compiler bug, so the tested code was actually correct!) but these are *extremely* rare
But like, even if we were at the wall when it comes to models, you can already automate finding so much low hanging fruit, and, well, even outside of the simplest options a lot of security issues are just about persistently exploring for common issues.
Similarly there's a lot of software that's just damn annoying to automate for different reasons and is somewhat detached from mainstream software engineering for one reason or another, so even though LLMs do get better at it it's not at the same level or pace as more general cases.
I think a big issue with the claims of "LLMs won't work for X" is that it's often stated about fairly wide fields. Will LLMs automate *all* vulnerability research? I'd bet on "no" and we'll be seeing "artisan vulns" even in the wild for a long time still.
Tenstorrent downgrades Blackhole p150 PCIe cards specs from 140 to 120 cores
To cancel you need to go to kimi.com/settings (not the code dashboard) and then go to subscription, or directly to www.kimi.com/membership/s...
But yeah, I've not tested it much with code but from quick testing with more research-like tasks it seems more sycopathic than K2 unfortunately.
A screenshot of the profile of the official Bluesky account seen on the Mastodon Android client.
god is dead and we killed him https://tangled.org/leap.nekoweb.org/MastodonAT
Yeah, but it is a territory of a member state and an oversea territory of European Union, so primary EU law still applies there. So I think they *should* fall under that, but I guess it's not nearly as clear as for an EU member, so it could be used to wriggle out of this, at least publicly?
So like, I've seen people say that "this is end of NATO" as if there was some world where NATO is destroyed, EU ignores the aggression just now by themselves and with sour relations with the US...
But that scenario would also break *the* EU treaty. It could very well become existential to the EU.
Also, everyone is talking about this triggering NATO Article 5, but it would also trigger Treaty on European Union article 42(7) which, unlike NATO treaty does not say to do what members "deem necessary" to restore security, but to aid with "all the means in their power".
I'll have to test it again once I'm back because I remember having a similar issue with Orange making some package downloads crawl (ghcr I think?) that just "resolved itself" /after a few days.
*and I did want yo try it out I guess, so it's not like it was a terrible option, but I'm angry at the time I spent fighting NixOS just because of Orange.
I've had the same issue and went to 39C3 with atomic Fedora instead of NixOS on a laptop because of this*
A VPN is a stupid workaround that I unfortunately only though about when it turned out FlatHub had the same Fastly issue (and it was too late to reinstall again).
That makes sense at least, and I assume they're used for the same reason here, but we just have fewer one-way streets here (I've been very surprised by how much of SF is one-way...), and cities seem to use less conditional signaling, so I assume that's why I've not seen a left one.
