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

Would make porting all sorts of old protocol stacks to #Rust so much easier if the enum fields could have aliased names. #rustlang

I'm looking into repealing and replacing the error type with this with the error type from my lab project: https://github.com/tpm-rs/tpm-rs/issues/71

#tpm #tpmrs #rust #rustlang

Language Server Protocol really would need a competitor with a #plugin based architecture.

Then editor and analyzer could have:

1. A better memory and caching strategy.
2. Both faster performance and lower operation latency.

#LSP is IMHO is exactly like the worst ideas of lrzsz modified to work as a language analyzer.

#telescope is awesome with the #kernel tree #neovim

The work on #bootc Is coming along very nice! This morning keynote by @cgwalters, Dan Walsh, and Stef Walter was very nice to see the current state of it in #Fedora and CentOS Stream. #devconf_cz

#neovim in #fedora 40 does this when opening a #lua file:

Error detected while processing BufReadPost Autocommands for "*":
Error executing lua callback: /usr/share/nvim/runtime/filetype.lua:35: Error executing lua: /usr/share/nvim/runtime/filetype.lua:36:
 BufReadPost Autocommands for "*"..FileType Autocommands for "*"..function <SNR>1_LoadFTPlugin[20]..script /usr/share/nvim/runtime/f
tplugin/lua.lua: Vim(runtime):E5113: Error while calling lua chunk: /usr/share/nvim/runtime/lua/vim/treesitter/language.lua:107: no
parser for 'lua' language, see :help treesitter-parsers
stack traceback:
        [C]: in function 'error'
        /usr/share/nvim/runtime/lua/vim/treesitter/language.lua:107: in function 'add'
        /usr/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:111: in function 'new'
        /usr/share/nvim/runtime/lua/vim/treesitter.lua:41: in function '_create_parser'
        /usr/share/nvim/runtime/lua/vim/treesitter.lua:108: in function 'get_parser'
        /usr/share/nvim/runtime/lua/vim/treesitter.lua:416: in function 'start'
        /usr/share/nvim/runtime/ftplugin/lua.lua:2: in main chunk
        [C]: in function 'nvim_cmd'
        /usr/share/nvim/runtime/filetype.lua:36: in function </usr/share/nvim/runtime/filetype.lua:35>
        [C]: in function 'nvim_buf_call'
        /usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
stack traceback:
        [C]: in function 'nvim_cmd'
        /usr/share/nvim/runtime/filetype.lua:36: in function </usr/share/nvim/runtime/filetype.lua:35>
        [C]: in function 'nvim_buf_call'
        /usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
stack traceback:
        [C]: in function 'nvim_buf_call'
        /usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
Press ENTER or type command to continue