Early potatoes, herring and egg dip 😛

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

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

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…

Just paid 40 EUR annual bill for my Kapsi SSH account. It is the center piece of my digital life :-)

Kapsi has a IMAP inbox for my personal email and kernel.org mail (the same inbox is shared via RFC 5233 sub-addressing ), IRC screen (tmux), sometimes bots (tmux), exposing files via https URL’s (sometimes more feasible than e.g. dropbox shared links). It also provides for each user 50 GiB of backed up quota (with self-restore) and 500 GiB of space “in your own responsibility”.

Servers are hardened with quite reasonable standards and some of the people at Kapsi maintaining the backend actually know what they are doing when it comes to #infosec ;-)

It just continues to amaze me how dirt cheap this service is… and how awesome it is :-)

#Kapsi #Oulu #Finland

-

Resetting the commit history of pass

pushd  ~/.password-store
git checkout --orphan main2
git add .
git commit -a -s -m epoch
git branch -D main
git branch -M main
git push origin main -f    
git log -1
popd

Execution transcript:

~ main
❯ pushd  ~/.password-store
git checkout --orphan main2
git add .
git commit -a -s -m epoch
git branch -D main
git branch -M main
git push origin main -f
git log -1
popd

~/.password-store ~
Switched to a new branch 'main2'
[main2 (root-commit) a25d65b] epoch
# <snip>
Deleted branch main (was 0600cc7).

Enumerating objects: 76, done.
Counting objects: 100% (76/76), done.
Delta compression using up to 8 threads
Compressing objects: 100% (68/68), done.
Writing objects: 100% (76/76), 33.51 KiB | 11.17 MiB/s, done.
Total 76 (delta 0), reused 44 (delta 0), pack-reused 0
To kapsi.fi:git/password-store
 + 0600cc7...a25d65b main -> main (forced update)
commit a25d65b3ebcf87f45540bd54f209193fc5f1fef2 (HEAD -> main, origin/main, origin/HEAD)
Author: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
Date:   Mon Jun 17 02:18:06 2024 +0300

    epoch

    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>

Meanwhile, while I'm on a #Ghidra bender this evening - I just found this neat tutorial on using Zynamics #BinDiff with Ghidra, via the #BinExport plugin:
https://www.0x90.se/reverse%20engineering/install-binexport-and-bindiff/

I'm planning to give this a go - while I had access to IDA+Bindiff, I used it a fair bit.

Edit - in case you missed it, BinDiff and BinExport are also now open-source:
BinDiff: https://github.com/google/bindiff
BinExport: https://github.com/google/binexport

Here’s the next steps for tpm2-cli.

Transient objects:

• tpm2-cli flush
  • TPM2_FlushContext
• tpm2-cli create
  • TPM2_Create
• tpm2-cli load
  1. ASN.1 decode.
  2. TPM2_Load
• tpm2-cli save
  1. TPM2_Import
  2. ASN.1 encode.

Persistent objects:

• tpm2-cli punch.
  • Inspired by fallocate(2) FALLOC_FL_PUNCH_HOLE.
• tpm2-cli persist
  • TPM2_EvictControl

So the basic gist here is that the command-line I/O goes always in ASN.1 format. Obviously other formats could be supported too but that is what I care myself ATM.

After that I’ll see how much the smoke test transcripts in my kernel patch set cover letter simplify:

https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/

A use case for #OpenPGP #signing that would combine best of #Yubikey and a #TPM2 chip:

1. A/S/E subkeys inside Yubikey.
2. C (#certificate) key as TPM2 ASN.1 blob.

The C key can be tied a to single chip during its creation. If someone gets a copy it is useless without that exact chip.

For the sake of defense in depth, a maintainer would keep that exact blob still in USB stick.

This scheme would be pretty airtight as even certification creation while the machine is online, would have quite low risks. E.g. if the ASN.1 blob is stolen while online, the key is useless by itself.

So in the context of #Linux #kernel #PGP #maintainer #guide this would make the whole process way more relaxed and convenient with the help of TPM2 chip.

How we deal with subkeys that part is smooth but there's still room for improving The Maintainer Experience when dealing with your Certification key :-)

I will work on user space shenanigans for this maintainer flow upgrade after this patch set is finished: https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/T/#t. I.e. find good route for gnupg to access the TPM2 (RSA4096/Curve25519) key, which is imported OpenPGP cert key...

lnav is a terminal-based log file viewer (TUI) for #Linux, #FreeBSD, #macOS, and other #Unix like systems. It combines the functionality of tools like tail, grep, awk, sed, and cat into a single interface. It also allows you to run SQL queries against your log files to build reports and offers basic support for Linux containers like Docker. lnav – Awesome terminal log file viewer https://www.cyberciti.biz/open-source/lnav-linux-unix-ncurses-terminal-log-file-viewer/

My question would be this why you want to do anything to address the (context-dependent) conclusion that “Python is slow”? ;-)

How I would address [1] with any Python3 dot release would be:

1. LATENCY: Manual driver/controller in the app for gc.* for the sake of predictability in timing. Run it when your app is idling. Do not run it at the hot spots.
2. BANDWIDTH: Use a freaking C-library for the payload processing. By practical means all of them have Python bindings.

[1] https://thenewstack.io/why-python-is-so-slow-and-what-is-being-done-about-it/

#Python #Python3 #PyCon #performance #gc

I finally released b4-0.14.0 with some neat features. Read the announcement for details:

https://lore.kernel.org/tools/20240614-flashy-inquisitive-beaver-ddcfea@lemur/T/#u

Still my #TUI file manager of choice after all these years.

Closed my tpm-rs bug because I do not want to contribute to that project: https://github.com/tpm-rs/tpm-rs/issues/71#issuecomment-2171360982

Why? I think mine is better or will grow so much better than this. It is more idiomatic #Rust, and generally less layered and more lean and mean ;-)

I will review merge requests for mine tho, on the basis of common sense and code quality tho: https://gitlab.com/jarkkojs/tpm2_library/-/issues

#linux #kernel #tpm2 #rustlang

put some #feedback about size units to a #fedora #magazine #article ;-)

https://crates.io/crates/tpm2_cli 0.3.0, 634 downloads after 48h of starting of development.

tpm2-cli 0.2.3: https://crates.io/crates/tpm2_cli

#tpm #tpm2 #linux #rust #rustlang

TPM2 command encoding with #bincode and #serde:

            let options = DefaultOptions::new()
                .with_fixint_encoding()
                .with_big_endian();
            buf.extend(&options.serialize(&(Tag::NoSessions as u16)).unwrap());
            buf.extend(&options.serialize(&22_u32).unwrap());
            buf.extend(
                &options
                    .serialize(&(CommandCode::GetCapability as u32))
                    .unwrap(),
            );
            buf.extend(&options.serialize(&(Capability::Handles as u32)).unwrap());
            buf.extend(&options.serialize(&HR_PERSISTENT).unwrap());
            buf.extend(&options.serialize(&1_u32).unwrap());

#rust #rustlang

Well, these authors cut right to the chase in this paper!

#LLMs
#AI
#GenerativeAI
#bullshit
#ethics
#truth

Just noticed that #aerc has native support for #zoxide: see :z. #email