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-cli create
tpm2-cli load
TPM2_Load
tpm2-cli save
TPM2_Import
Persistent objects:
tpm2-cli punch
.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/
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:
gc.*
for the sake of predictability in timing. Run it when your app is idling. Do not run it at the hot spots.[1] https://thenewstack.io/why-python-is-so-slow-and-what-is-being-done-about-it/
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
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());
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