@codrusofathens ... and counter arguments are 90% of time qualitative arguments, e.g. "we have this contract/abstraction/invariant so you're wrong".

I only believe in quantitative arguments for the most part. E.g. spec growth is one of such, e.g. you can compare that to a spec that does not grow. Would be foolish to think that spec growth does not have a negative impact to static analysis.

But for any quantitative arguments it is hard to say anything conclusive. Can't beat Gödel's theory of incompleteness, right? ;-)

@codrusofathens and the whole narrative that Rust almost invented memory safety is like totally untrue.

E.g. in the backend Java has delivered the whole gist of memory safety literally decades and JVM's JIT is a monster dealing with server payloads... It is optimized by the best breed of Intel, ARM etc. companies for each micro-architecture.

When looking at beyond the hype I feel that there's exactly one area where I find Rust best tool so far: cli-interfaces. For tpm2-cli I chose Rust because input validation was easier with it than in my previous python experiments (I've done a small Python based stack for kselftest previously).

Not a revolution really ;-)

@codrusofathens yeah, it is f*****g horror story how this plays :-) absolutely hate rusty forking culture.

@hunger local reasoning is not something that i can measure, so pure ignore the whole concept ;-)

Zbus looks cool: https://dbus2.github.io/zbus/

Early potatoes, herring and egg dip 😛

@hunger I do like Rust, I'm using it too, and have contributed to some upstream projects features and also have some things of my own going on too (still unreleased ASN.1 to bytecode compiler, and alternative super light-weight TPM2 stack).

I just generally learn best by applying "learn by hate"-methodology ;-)

Like when doing kernel dev, I look Linux more like how bad it is, and from that angle I find ways to improve it. And even look into how great NT kernel or Darwin are doing some things, whereas Linux is under-performing.

@hunger yup, I can more or less align with this!

@hunger Except the one that I already mentioned:

1. Rust static analysis can get only worse over time, given the steady complexity growth in the spec.
2. C static analysis can get only better over time, given a stable and compact spec. And it does. Tooling for analyzing C is a whole multi-million industry of its own.

@hunger would take me ages to open code that argument so i just say that I can agree on disagreeing with your argument 😉

@hunger it is well anchored comparison also given the build artifact: ELF binary (or COFF/PE).
Also in binary analysis C wind by a large margin given its trivial binary structure, which is result of compact language spec with only constructs that are great fits for any possible microarchitecture ABI.

@hunger

I find it somewhat easy because the application category is well defined in my post:

1. I based amount of C dependencies based on what I’m typically seeing in the project file. GNOME is a project umbrella, not a dependency.
2. Dependencies might be larger but there are much less forks, larger user bases, which adds up to the QA and generally well-defined processes.
3. For many Rust libraries I find sometimes hard to trust, given that they have not been exposed that much in the “warzone”. And this is sort of feature of the ecosystem too because you pile up your app stack from these nuts and bolts (also known as “crates”). You end up constructing yourself the “big dep”.

@janantos @duxsco I think it is a great invention to use elliptic cryptography for social id's no matter how you categorize it ;-)

A typical #TUI #Rust application has usually about ~600 dependencies or similar figure.

A typical C applications has less than ten. C application might possibly be less "memory safe" language but you can statically analyze every bit and piece of the code base, including dependencies.

And by doing hat, you end up getting more verified, and *objectively* more memory safe build artifact ;-) 🤷

What many people especially in the Rust community completely have ignored, one side-effect of this new language popping, was igniting the heyday of the development of static analysis of the C language, which has *vastly* improved both in LLVM and GCC toolchains.

Just look at how amazing e.g. GCC 14 is when analyzing C code, and given the low amount of dependencies you can get pretty solid guarantees on safety of your code base.

Static analysis of C can *only* get better because the base language is compact and does not really grow anymore. One thing where C is factors more immutable is the language spec itself ;-) Rust language spec on the other hand is the most mutable spec ever invented, and run by a Github pull request process...

#rustlang #gcc #llvm #toolchain

@janantos @duxsco OK, Bitcoin's so called "proof of work" is also based on Merkle tree per TX block.

@janantos @duxsco Ah, right I always connect the whole to the distributed version! So it is taxonomy dependent how you argue about the topic. Thanks, I did not know nothing about David Chaum's past work. I will read that...

@janantos @duxsco Yep, I get a gut feeling that marketing department has mixed up blockchain and revocable ECDSA signature ;-)

@duxsco @janantos

Do want to slander our neighbor nation but I’m bit skeptical towards claim that Estonia had its first blockchain in 2007.

Bitcoin paper came out in 31st of October, 2008, so possible conclusions:

1. Bitcoin was not the first blockchain like within the metrics for such data structure that the paper defines.
2. KSI has some of the characteristics of those defined in the original Bitcoin paper but is not an “actual” blockchain.

Without better knowledge, bullet 2 is pretty good base assumption. Or who knows, perhaps Satoshi Nakamoto is an Estonian citizen or a group of citizens.

I want to my own so called wallet and looking at options of hardware incorporation:

1. TPM2: not feasible since does not handle P256K1 (only P256R1).
2. Hardware crypto wallets (from companies like Ledger): in my opinion worst inventions done during past 20 years. We need open and application agnostic keystore backends, not pollution like these.
3. FIDO2: Yubikey very compelling collection of crypto algorithms and ECC curves, including popular ones for blockchains.

So the choice is somewhat obvious based on this quick feasibility study: I want a FIDO2 wallet.

The next issue. I found this really nice FIDO2 wallet in C++: https://github.com/hoytech/defido2

My next question would be tho does anyone know is the choice of implementation language in this driven by “passion” or something actually preventing to do this using W3C API’s for FIDO2?

Does W3C API e.g. block some ECC curve types that my Yubikey might support?

#blockchain #wallet #w3c #fido2 #ethereum

@janantos @duxsco OK, so if my information is correct KSI uses the NIST curve, i.e. P256R1 and because of that ECDSA signatures. Bitcoin also uses ECDSA but with a different curve P256K1.

Meaning that even my in progress patch set can sign those when the private key is managed by a TPM chip [1]. Anyway good to know.

[1] https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/T/#t