For gpg-agent I have the following entries in ~/.gnupg:

gpg-agent.conf
gpg-agent.conf.darwin
gpg-agent.conf.linux-gnu

In a new installation the correct configuration can be deployed as follows:

cp ~/.gnupg/gpg-agent.conf.$OSTYPE ~/.gnupg/gpg-agent.conf

#teardown and #bootstrap gpg-agent, pcscd to have a working configuration:

#!/usr/bin/env sh
# Copyright (c) Jarkko Sakkinen 2024
# Bootstrap gpg-agent and pcscd for Yubikey use.

GPG_AGENT_SOCKETS=(gpg-agent-ssh.socket
                   gpg-agent-browser.socket
                   gpg-agent-extra.socket
                   gpg-agent-ssh.socket
		   gpg-agent.socket)
systemctl --user disable --now "${GPG_AGENT_SOCKETS[@]}"
gpgconf --kill gpg-agent
sudo systemctl disable --now pcscd.socket

systemctl --user enable --now gpg-agent.socket gpg-agent-ssh.socket
sudo systemctl enable --now pcscd.socket

#yubikey

Why Curve25519 uses EdDSA for signing, and SECP-P256-R1 and SECP-P256-K1 use ECDSA?

It’s the scale. Curve25519 field has the size that fits within 255 bits, and two previous have the size that fits within 256 bits.

So from that follows:

• a new signature formalization is needed to reach similar or better results.
• given the smaller size it can only reach this goal by integrating tightly to the choices of the finite field parameters.

There is formal backing for this but pure common sense it is exactly like “if loose some, you must gain some” ;-)

#cryptography #note

I realized that I have something profound broken in my asymmetric TPM2 key series: TPM2 specific keys should only sign, not verify.

struct public_key, which is the central structure used for built-in, vendor and machine owner keys, should be able to verify the signature, even when the TPM chip is removed.

As a consequence, I will delete all the verification code from the key type(s) and set the supported_ops a KEYCTL_SUPPORTS_SIGN, instead of previous KEYCTL_SUPPORTS_SIGN | KEYCTL_SUPPORTS_VERIFY.

I’ll also rework tests to have two asymmetric keys: one for signing in the chip and other outside holding only the public key. That should also better verify that the feature is working correctly.

Would be nice if #systemd would release yearly #showcase image and ISO. Twice a year would be even better but a yearly "the state of systemd" would already do miracles!

In my opinion, a working design for kernel developers for this would be an image that would have the some recent release number, and easy way to build and deploy a test kernel.

Love the name of the #systemd's python-bindings: "pystemd"

Right. I should take my TPM2 signing code and merge it to struct public_key, use only TPM2_Sign and ditch TPM2_RSA_Decrypt.

Just hit me out of the void. Then e.g. builtin/secondary/machine keyrings, x.509 certiificates etc. is also in the finish line once this feature lands :-)

Three week clocked to the development so far so I think this is going in good phase.

I’ll start a new series (because it is not the exact same feature as before).

#linux #kernel #tpm

Condolences.

Mike Karels of Berkeley Unix/BSDi died of a heart attack on his way home from BSDCon.

Karels was responsible for implementing TCP/IP on BSD, which was later ported to Linux. Since you're reading this, you are benefitting directly from his work.

RIP, Mike. We won't forget you.

https://freebsdfoundation.org/mike_karels/

Great, my patches adding host compilation for #libstpm and #swtpm was picked by the #BuildRoot upstream finally 🎂

@bluca Yep, ended up sending a small patch set to #BuildRoot:

https://lists.buildroot.org/pipermail/buildroot/2024-June/754783.html

@peterkorsgaard

@bluca I’ll try picking these and see if it makes any difference:

ed01b92e1c92 ("basic: add PIDFS magic (#31709)")
201148b08de6 ("basic: Add BCACHEFS magic")

EDIT: Apply cleanly on top of v255 :-)

I really like #mmv https://github.com/rrthomas/mmv/. Archaic but does not get in the way..

Like for instance:

❯  mmv -n '*.patch' '#l1.patch'
0001-basic-add-PIDFS-magic-31709.patch -> 0001-basic-add-pidfs-magic-31709.patch

Handy :-)

#mv #cp #ln #rm

@bluca OK thasnks, I can clone that and check:

1. git clone systemd
2. export SYSTEMD_OVERRIDE_SRCDIR=$PWD/systemd

Then cherry-pick the patches… I want to pick over 255 because last version with all the legacy and it is BuildRoot in question (not necessarily fully systemd unity compatible).

Trying to deploy #systemd to BuildRoot build:

Filesystem found in kernel header but not in filesystems-gperf.gperf: BCACHEFS_SUPER_MAGIC                                                    
Filesystem found in kernel header but not in filesystems-gperf.gperf: PID_FS_MAGIC                                                            

I think I might know how to fix these tho so should not be an issue.

I had QEMU style build. I’m repeal and replacing that with a build that builds 2GB disk image ESP/UEFI compatible. That can then supplied to qemu/libvirt or burned to stick and booted with hardware.

#linux #kernel #testing

@vbabka Like https://www.microsoftpressstore.com/store/code-the-hidden-language-of-computer-hardware-and-software-9780137909100

I did read the first edition years ago :-)

Don't get too excited: Intel TXT will be also available in #x86s ;-)

Unfortunately this is not documented yet in Intel SDM , which misguided a bit when I was reviewing Trenchboot.

Finally I found [1], which has a "3.15 SMX Changes" section and asociated pseudocode Hopefully soon also in the SDM.

So long live measured DRTM launch ;-) The future is now.

[1]
https://lore.kernel.org/linux-integrity/D1SPFVXS6FOG.IQQB3INFYEF2@kernel.org/
[2]
"X86S EXTERNAL ARCHITECTURAL SPECIFICATION"
https://cdrdv2.intel.com/v1/dl/getContent/776648

#linux #kernel #x86

@pinkforest Right and obviously you can use mmap() in addition to extend and truncate the address space on the run. FALLOC_FL_PUNCH_HOLE just removes page from reserved set, and does not unmap page. As soon as it is accessed a new page is created the of course in this case. So anyway, there is all of this really nice stuff just in plain Linux uapi that you can use to do amazing things with memory, and de-facto Rust installation is totally unaware of their existence. Quite lame to put it as I really think it is :-)

@pinkforest Like for instance. What would you possibly do with a re-allocating vector in any modern systems software? For small chunks, create large enough fixed arrays. For data that needs to scale dynamically however many gigabytes of addresses can be mapped with a total zero cost, and the #PF handler takes care of the rest. Finally there is an option to manually scale the space down with fallocate() (FALLOC_FL_PUNCH_HOLE).

This is standard stuff in modern C systems software. If this is over the top, then I tend to think that probably Java or Go would be better picks in the first place.I just use Python then because more than liking a tool, I like measurable value, which cannot be just my liking. Self-deception IMHO :-)

Over the years best things that have came out from #Microsoft that I've liked have been from Microsoft Press :-) IMHO, the best subsidiary of Microsoft.

@pinkforest Anyway, I have a small little project to work on where macros in Rust work great :-) Also small set of dependencies I'd like to see it compiling gccrs and rustc and find ways to keep that constraint. Probably have something together in August.