dkasak

> (Recently they finally added the ability to require authentication for the media store, although they didn't add support for it to their web client, only their new Android one.)

This is not true. If it were true, it would imply you can't view any newly uploaded media from the web client. Here is the web implementation of MSC3916: https://github.com/element-hq/element-web/pull/27326

The Matrix.org Foundation has been steadily increasing its independence, with the recent introduction of the Governing Board (https://matrix.org/blog/2024/06/election-results/) which includes a mix of representatives from commercial players, the community, as well as Spec Core Team members and Guardians. Also, there are nowadays several Spec Core Team members who are not employed or contracted by Element, including some who are working for (near-)competitors in the space.

In other words, people are actively thinking of and implementing measures to mitigate the risk of accidentally/unintentionally backsliding into a closed standard.

Not directly related, but I feel that any references to Ansible being slow should be accompanied by a mention of the amazing Mitogen.

https://mitogen.networkgenomics.com/ansible_detailed.html

Oh boy, do I have a treat for you. Try saving the following as `input.md`:

    # Hello *world*
    
    ## Math
    
    $$x = 2 \cdot y^3$$
    
    - foo
    - bar
    - baz
    
    1. Yes
    2. No
    3. Maybe
    
    ---
    
      Right     Left     Center     Default
    -------     ------ ----------   -------
         12     12        12            12
        123     123       123          123
          1     1          1             1
    
    Table:  Demonstration of simple table syntax.

Then run

    pandoc -t html input.md | xclip -selection clipboard -t 'text/html'

And paste into a Google doc.

A lot of the problems were caused by the legacy crypto implementations. The misery is not caused by ripping them out and replacing them with matrix-rust-sdk crypto, but by it (unavoidably) taking a while.

The risk being accepted is that a homeserver can currently add members to the group with the group being notified of this.

This risk will be removed completely once TOFU and signed control events are implemented, which is planned (and was planned before this research). It's just more work than could fit in the disclosure timeline, especially because it's a large change needing ecosystem coordination.

It's true Matrix today doesn't implement end-to-end auth for room control messages, but it's a bit of a stretch to say you can spy on conversations in this way.

In a room where participants are verified with each other, you'd be warned of this with a loud red shield with an exclamation mark in the room header. Additionally, if you're extra worried about a room, there's a "Never send encrypted messages to unverified sessions in this room from this session" setting you can flip in the Element clients.

That said, this can and will be improved in the future, by signing room state events and implementing TOFU (trust-on-first-use) for user identities, so that you can have a large amount of protection even before you perform manual verification with other users.

It may be a serious question, but I don't see how it relates to the part you quoted. It still is a dumb idea, regardless of the answer to your question.

You'll be thrilled to know this pretty much isn't true anymore, even with Synapse. My instance is running on a cheap Hetzner VPS with a not very powerful CPU and is currently using about 700M RSS and not much CPU. And I'm in a lot of rooms, some of them quite large and high in traffic.

I'm also not even using Synapse workers at all, just a monolithic instance. Splitting the setup into workers would buy me an additional speedup if things got overly slow.

Realistically, when would you be in a hundred-person encrypted group? Mostly this is the case when you're a member of some kind of organization, and there are ideas how to solve this case without pairwise verifying all participants (e.g. by delegating trust through a single trusted person such as the CEO, reducing the number of verifications necessary from N(N+1)/2 to N). Even without this, fully verified E2EE is still feasible and useful for smaller groups.

And even if you own the homeserver, you still want E2EE since you don't want the data to rest in plaintext server-side.

However, there is work currently being done to make it feasible for every node to also be its own homeserver, via P2P Matrix (https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix).

The Rust rewrite is stalled but not abandoned, there's just been a bit of a slump due to time constraints. Which features are you missing the most?

Author here. As one of the other comments mentions, afl++ (and to some extent vanilla afl) already has capability to automatically scrape magic values from arguments to special functions like `strcmp` and the like. The older technique is called libtokencap (https://github.com/AFLplusplus/AFLplusplus/blob/stable/utils...), but afl++ also has a newer feature called AUTODICT (https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...).

But this only solves the problem of magic constants expected in the input. If the check depends on dynamic properties of the input or happens deeper in the code after the input's already been through some transformations, it can't be solved like this. There are other techniques to help with this, though. One of the earlier attempts to solve such types of more complex checks is called laf-intel (https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...) and boils down to transforming a more complex check into a nested series of simpler checks. This makes it more probable that the fuzzer's random mutation will be able to solve the outer check and hence hit new coverage, enabling the fuzzer to detect the mutation as productive.

afl++ has a more modern variant of this called CmpLog (https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...) which is based on the RedQueen technique. The paper for RedQueen is a really interesting read: https://www.syssec.ruhr-uni-bochum.de/media/emma/veroeffentl...

The problem of checksums is at times also solved by simply modifying the binary so that the checksum is neutralized and always succeeds, especially if you have access to source code.

As for the problem of fuzzing stateful things like the double ratchet, one way of tackling the problem is to think of the input to the fuzzer as not only the raw bytes that you'll be passing to the program you're fuzzing, but as a blueprint specifying which high-level operations you'll be performing on the input. Then you teach your fuzzer to be smarter and be able to perform a bunch of those operations.

So, let's say you take 512 bytes as the input to the fuzzer. You treat the first 256 bytes as the message to decode and the latter 256 bytes as the high-level cryptographic operations to perform on this message, each byte specifying one of those operations. So you could say a byte of value 1 represents the operation "ENCRYPT WITH KEY K1", 2 represents "ENCRYPT WITH KEY K2", 3 represents "DECRYPT WITH KEY K1", 4 represents "DECRYPT WITH KEY K2", 5 represents "PERFORM SHA2" and so on. Now you can feasibly end up with a sequence which will take a message encrypted with key K1, decrypt it, modify the message, then re-encrypt with key K2. Or, in the case of the double ratchet algorithm, have it perform multiple successive encryption steps to evolve the state of the ratchet and be able to fuzz more deeply.

Of course, the encoding needs to be rather dense for this to work well so that ideally each low-level bit mutation the fuzzer does on an input still encodes a valid sequence of valid high-level operations.