@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

@janantos @duxsco yep, well IMHO ID is always also a number ;-) Anyway, thanks a lot could not find it myself! Might become essential if the curves turn to be right :-)

Tomorrow I step through https://docs.oracle.com/en/learn/oci_nextcloud_ampere_a1/index.html

Stumped into a bug straight out right in the get-go ;-) It goes like this…

First, consider:

❯ cat pubkey.txt 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3un58bzSwrEXD5PMNuT9nYhyBfdiEeDrcQd3Facw9PZihlFwfec+iz00u4bbNmcrG0YhT056PSnqIR4DqGSK3N2iancS1anBfgNS7Se02jcOyoHsgrDFH6MxEgkZLoFY8XodE5NPDGt6rPoiy6MeN0jKNvuMMQ9UFge67ky0pWZjyDjdyXERZWEIjcp+OQXMaFAU3zJCbnaLgVn7CizZcwriu2ElMg0tVvxdkW59QW9dSgmCdF4zwSvLN6XVpaCw+fiXV+09Wq5PT65qT/rWC/0yO4BWuZFteX8gXyDQBJqEzNKjkvACNFI4ublSUQO7zYnyFQjlww04+afTFkWZYIV2UtOZYzJaTg90DT3fQBkJMxsHHc4G8eF+SveIy1tiOq7jf8btvdKLCyvIrNMlhB99YPAzBFUd/X/w7uOEtm7L4zoWa+6YRjtKiPtuaeGGQVr3CEU/L9rtPY9PfkPOxGUahnM5M2MsST5NPZ9+tWvhjEFX4nSYo5EShFBE9m01sa675mzrOwsBXwi7AlBZtT4hEYN1jvVUVXrwEC8W7RKy3C0mgU/mlnxXHp23af9YEkjiYA5ZBmK4+q85o0pBf616cLAhzebDwoT5v9VkYY+q1t3nLWpaG9HAH0BmPyEW0jlB1jxqwUvlmWQ14vtZUOAzrFnAoUKDVLTeuK+w5vw== cardno:23_610_166

Uploading this results “Invalid file type. SSH public key (.pub) files only” (screenshot #1).

Then, consider:

❯ mv pubkey.{txt,pub}
❯ cat pubkey.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3un58bzSwrEXD5PMNuT9nYhyBfdiEeDrcQd3Facw9PZihlFwfec+iz00u4bbNmcrG0YhT056PSnqIR4DqGSK3N2iancS1anBfgNS7Se02jcOyoHsgrDFH6MxEgkZLoFY8XodE5NPDGt6rPoiy6MeN0jKNvuMMQ9UFge67ky0pWZjyDjdyXERZWEIjcp+OQXMaFAU3zJCbnaLgVn7CizZcwriu2ElMg0tVvxdkW59QW9dSgmCdF4zwSvLN6XVpaCw+fiXV+09Wq5PT65qT/rWC/0yO4BWuZFteX8gXyDQBJqEzNKjkvACNFI4ublSUQO7zYnyFQjlww04+afTFkWZYIV2UtOZYzJaTg90DT3fQBkJMxsHHc4G8eF+SveIy1tiOq7jf8btvdKLCyvIrNMlhB99YPAzBFUd/X/w7uOEtm7L4zoWa+6YRjtKiPtuaeGGQVr3CEU/L9rtPY9PfkPOxGUahnM5M2MsST5NPZ9+tWvhjEFX4nSYo5EShFBE9m01sa675mzrOwsBXwi7AlBZtT4hEYN1jvVUVXrwEC8W7RKy3C0mgU/mlnxXHp23af9YEkjiYA5ZBmK4+q85o0pBf616cLAhzebDwoT5v9VkYY+q1t3nLWpaG9HAH0BmPyEW0jlB1jxqwUvlmWQ14vtZUOAzrFnAoUKDVLTeuK+w5vw== cardno:23_610_166

As can been seen from screenshot #2, the public key was successfully uploaded. For me this looks like as if validation was based on the filename extension o_O

A correct validation would ignore the file’s name and base validation on RFC 4716: The Secure Shell (SSH) Public Key File Format.

Stumped into a bug straight out right in the get-go ;-) It goes like this…

First, consider:

❯ cat pubkey.txt 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3un58bzSwrEXD5PMNuT9nYhyBfdiEeDrcQd3Facw9PZihlFwfec+iz00u4bbNmcrG0YhT056PSnqIR4DqGSK3N2iancS1anBfgNS7Se02jcOyoHsgrDFH6MxEgkZLoFY8XodE5NPDGt6rPoiy6MeN0jKNvuMMQ9UFge67ky0pWZjyDjdyXERZWEIjcp+OQXMaFAU3zJCbnaLgVn7CizZcwriu2ElMg0tVvxdkW59QW9dSgmCdF4zwSvLN6XVpaCw+fiXV+09Wq5PT65qT/rWC/0yO4BWuZFteX8gXyDQBJqEzNKjkvACNFI4ublSUQO7zYnyFQjlww04+afTFkWZYIV2UtOZYzJaTg90DT3fQBkJMxsHHc4G8eF+SveIy1tiOq7jf8btvdKLCyvIrNMlhB99YPAzBFUd/X/w7uOEtm7L4zoWa+6YRjtKiPtuaeGGQVr3CEU/L9rtPY9PfkPOxGUahnM5M2MsST5NPZ9+tWvhjEFX4nSYo5EShFBE9m01sa675mzrOwsBXwi7AlBZtT4hEYN1jvVUVXrwEC8W7RKy3C0mgU/mlnxXHp23af9YEkjiYA5ZBmK4+q85o0pBf616cLAhzebDwoT5v9VkYY+q1t3nLWpaG9HAH0BmPyEW0jlB1jxqwUvlmWQ14vtZUOAzrFnAoUKDVLTeuK+w5vw== cardno:23_610_166

Uploading this results “Invalid file type. SSH public key (.pub) files only” (screenshot #1).

Then, consider:

❯ mv pubkey.{txt,pub}
❯ cat pubkey.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3un58bzSwrEXD5PMNuT9nYhyBfdiEeDrcQd3Facw9PZihlFwfec+iz00u4bbNmcrG0YhT056PSnqIR4DqGSK3N2iancS1anBfgNS7Se02jcOyoHsgrDFH6MxEgkZLoFY8XodE5NPDGt6rPoiy6MeN0jKNvuMMQ9UFge67ky0pWZjyDjdyXERZWEIjcp+OQXMaFAU3zJCbnaLgVn7CizZcwriu2ElMg0tVvxdkW59QW9dSgmCdF4zwSvLN6XVpaCw+fiXV+09Wq5PT65qT/rWC/0yO4BWuZFteX8gXyDQBJqEzNKjkvACNFI4ublSUQO7zYnyFQjlww04+afTFkWZYIV2UtOZYzJaTg90DT3fQBkJMxsHHc4G8eF+SveIy1tiOq7jf8btvdKLCyvIrNMlhB99YPAzBFUd/X/w7uOEtm7L4zoWa+6YRjtKiPtuaeGGQVr3CEU/L9rtPY9PfkPOxGUahnM5M2MsST5NPZ9+tWvhjEFX4nSYo5EShFBE9m01sa675mzrOwsBXwi7AlBZtT4hEYN1jvVUVXrwEC8W7RKy3C0mgU/mlnxXHp23af9YEkjiYA5ZBmK4+q85o0pBf616cLAhzebDwoT5v9VkYY+q1t3nLWpaG9HAH0BmPyEW0jlB1jxqwUvlmWQ14vtZUOAzrFnAoUKDVLTeuK+w5vw== cardno:23_610_166

As can been seen from screenshot #2, the public key was successfully uploaded. For me this looks like as if validation was based on the filename extension o_O

A correct validation would ignore the file’s name and base validation on RFC 4716: The Secure Shell (SSH) Public Key File Format.

Since I switched from #Dropbox to #Storj, I’ve been almost solely using rclone.

Now I’ve started to feel that t it would be nice to have also an ownCloud instance and point out its storage to my #S3 bucket at Storj.

After looking through cloud options, I think got with ARM Ampere A1 VM: that #Oracle offers:

“Up to 4 instances of ARM Ampere A1 Compute with 3,000 OCPU hours and 18,000 GB hours per month”

Should scale a to my personal ownCloud with storage backend at Storj. The amount of OCPU hours nailed this really…

I also feel better when the server room that is "center piece of my digital life" is within homeland's borders ;-)

Right this is only people who live in Finland ;-) (nationality not required)

@Foxboron @duxsco
Morten just a summary

1. TPM's containing TCG algorithms for Ed curves are rare, or perhaps even non-existent.
2. Still, having `TCG_ECC_CURVE_ID` matters obviously because it hard requirement for having the implementation. 0.1% so much better than 0.0% odds, right?