While you're waiting for the Matrix blog post to go public, how about some 0day in one of the only OMEMO v0.9.0 implementations I can find?

[soatok@furry.engineer]

While you're waiting for the Matrix blog post to go public, how about some 0day in one of the only OMEMO v0.9.0 implementations I can find?

Security Issues · Issue #4 · mierenhoop/picomemo

TipYou don't have a security policy set up. If you don't want issues disclosed publicly out-of-the-gate, consider writing one. Buffer Underflow in omemoDecryptMessage (OMEMO2) After AES-CBC decryption, the PKCS#7 padding removal process ...

GitHub (github.com)

[cliffle@hachyderm.io]

@soatok I swear, the whole "assert becomes a no-op" thing is an evergreen source of security vulnerabilities.

[david_chisnall@infosec.exchange]

@cliffle @soatok

Just wait until C++26 is released. If I had designed a language construct specifically for inserting supply chain attacks, it would have looked a lot like C++ contracts.

[krig@goto.liten.app]

@david_chisnall @cliffle @soatok It’s pretty amazing and somehow an ode to the human spirit that there are people out there who look at C++ and think ”What this needs are more features”

[david_chisnall@infosec.exchange]

@krig @cliffle @soatok

C++26 also comes with compile-time reflection features, which have been known to be a big missing feature since C+98 was standardised. Building a good compile-time reflection feature is hard and generalised constexpr was a prerequisite. So I can see that there are still features that should be added.

Unfortunately, contracts are a pretty good case study in how not to design a language feature. They introduce new special-case syntax and semantics, in a place where generic syntax and semantics would be useful (e.g. function decorators built from reflection). And they do so with inadequate implementation experience (the implementers experience report ignored all of the bits that are hard to implement and the GCC implementation had trivial soundness bugs).

[krig@goto.liten.app]

@david_chisnall @cliffle @soatok I can see where you are coming from, but personally I think this is misguided. Everyone in the committee has their own pet feature that is the one that really needs to be added to the language. Contracts is the biggest pet feature of them all. But the biggest problem that the language has IMO is that it has too many features! Adding more features just cannot solve that problem. If there absolutely has to be a new language version, it should remove something. Make it stricter, restrict pointer arithmetic unless marked as unsafe etc. Compile time reflection is cool but not essential.

But I have moved on from C++, anyway.

[david_chisnall@infosec.exchange]

@krig @cliffle @soatok

I agree in a large part. Far too little attention is paid to the fact that every new feature is technical debt.

The problem with C++ is partly that it's too large a language, but also that a lot of that size is the wrong features. But you can't easily remove features (profiles will hopefully help with that and let you say things like 'no pointer arithmetic, no bare new / delete, in this file). You can add features, and some of the new features are huge improvements. Lambdas are 'just' a little bit of syntactic sugar over inline objects with constructors that capture some local things and an operator() that invokes them, but they're a huge usability improvement. Modern constexpr doesn't let you do anything you couldn't already do with templates, except that there's a good chance someone else might be able to read the code if you use constexpr. Concepts don't let you do anything you couldn't do with a big pile of std::enable_if (which, itself, is just a helper for SFINAE) but, again, someone else might have a chance at understanding the code if you use concepts.

Programming C++23 is far more pleasant than C++11 due to these things, and the addition of move semantics (and the things enabled by it such as std::unique_ptr) made C++11 much better to use than C++14.

At the same time, you're always using a subset of the language. There's a nice subset of C++, and ideally the subset that you recommend people use should be almost identical to the set of new things, with the old things being deemphasised, then removed in profiles. But adding big new features without considering how they will compose with future features is how we got to the state where the nice subset of C++98 was a very small subset of the language.