• 0 Posts
  • 58 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle
  • No, rust is stricter because you need to think a lot more about whether weird edge cases in your unsafe code can potentially cause UB. For ex. If your data structure relies on the Ord interface (which gives you comparison operators and total ordering), and someone implements Ord wrong, you aren’t allowed to commit UB still. In C++ land I’d venture to guess most any developer won’t care - that’s a bug with your code and not the data structure.

    It’s also more strict because rusts referencing rules are a lot harder then C’s, since they’re all effectively restrict by default, and just turning a pointer into a reference for a little bit to call a function means that you have to abide by those restrictions now without the help of the compiler.





  • The vulnerability has nothing to do with accidentally logging sensitive information, but crafting a special payload to be logged which gets glibc to write memory it isn’t supposed to write into because it didn’t allocate memory properly. glibc goes too far outside of the scope of its allocation and writes into other memory regions, which an attacked could carefully hand craft to look how they want.

    Other languages wouldn’t have this issue because

    1. they wouldn’t willy nilly allocate a pointer directly like this, but rather make a safer abstraction type on top (like a C++ vector), and

    2. they’d have bounds checking when the compiler can’t prove you can go outside of valid memory regions. (Manually calling .at() in C++, or even better - using a language like rust which makes bounds checks default and unchecked access be opt in with a special method).

    Edit: C’s bad security is well known - it’s the primary motivator for introducing rust into the kernel. Google / Microsoft both report 70% of their security vulnerabilities come from C specific issues, curl maintainer talks about how they use different sanitizers and best practices and still run into the same issues, and even ubiquitous and security critical libraries and tools like sudo + polkit suffer from them regularly.





  • True, but that doesn’t necessarily matter if I can compromise the privileged app instead. I could replace it, modify it on disk, or really any number of things in order to get myself a hook into a privileged position.

    Just injecting code in some function call which launches malware.exe would do the trick. Ofc signature checks and the like can help here - but those aren’t a given. There’s any number of ways you can elevate yourself on a system based off of user security if your threat model is malicious processes. Linux (and windows) will stop users from accessing each other’s crap by default, but not processes.

    Or: supply chain attacks. Now your official app without any modifications is malicious.






  • As a third party, my understanding is that both the implementation and the protocol are really hard, if not next to impossible to iterate on. Modern hardware doesn’t work like how it did when X did, and X assumes a lot of things that made sense in the 90s that don’t now. Despite that, we cram a square peg into the round hole and it mostly works - and as the peg becomes a worse shape we just cram it harder. At this point no one wants to keep working on X.

    And I know your point is that it works and we don’t need too, but we do need too. New hardware needs to support X - at least the asahi guys found bugs in the X implementation that only exists on their hardware and no one who wants to fix them. Wayland and X are vastly different, because X doesn’t make sense in the modern day. It breaks things, and a lot of old assumptions aren’t true. That sucks, especially for app devs that rely on those assumptions. But keeping around X isn’t the solution - iterating on Wayland is. Adding protocols to different parts of the stack with proper permission models, moving different pieces of X to different parts of the stack, etc. are a long term viable strategy. Even if it is painful.





  • The data model there is fundamentally different. That would break how git would work because operations that worked one way before would now no longer work that way. You’d functionally have rewritten and mapped all the old functionality to new functionality with subtle differences, but at that point is it even git? You have a wrapper with similar but subtly different commands and that’s it. It’s like saying “instead of reinventing functionality by building both ext4 and btrfs, why don’t we just improve ext4”?

    The two are practically entirely different.


  • It being objectively better then SVN or CVS doesn’t mean that it’s the best we can do. Git has all sorts of non-ideal behaviors that other VCS’s don’t. Pijul’s data structure for instance is inherently different from git and it can’t be retrofitted on top. Making tooling only support git effectively kills off any potential competitors that could be superior to git.

    One example is pijul specifically let’s you get away from the idea that moving commits between branches changes their identity, because pijul builds a tree of diffs. If two subtrees of diffs are distinct, they can always be applied without changing identity of those diffs. This means “cherry picking” a commit and then merging a commit doesn’t effectively merge that commit twice resulting in a merge conflict.

    That’s one example how one VCS can be better.


  • Not OP, but personally yes. Every code forge supporting only git just further enforces git’s monopoly on the VCS space. Git isn’t perfect, nor should be treated as perfect.

    The above is probably the reason why so many alternative VCS’s have to cludge themselves onto git’s file format despite likely being better served with their own.

    Interesting new VCS’s, all supporting their own native format as well for various reasons:

    • pijul
    • sapling
    • jujutsu

    Sapling is developed by meta, jujutsu by an engineer at Google. Pijul is not tied to any company and was developed by an academic iirc. If you’re okay with not new:

    • mercurial
    • fossil
    • darcs

    VCS’s are still being itterated on and tooling being super git centric hurts that.