@jon_giraffe for more options:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash -s -- --help

#Rust installation instructions go like:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

But what you actually want to do most of the time, is probably:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash -s -- --no-modify-path

#rustlang

@orsinium So I did look into it a bit and if I got the right understanding it has its own backing storage thing.

So my thought are that:

• A more stream-lined interface for OpenPGP keys would be more than welcome.
• That said it should be able to fully connect to the existing GnuPG infrastructure because of compatibility sake. It would be tedious to switch whole “ecosystem” just for a better command-line tool.
• As long as the tool takes care of the shenanigans it does not matter how complicated the storage format is.

I.e. if I have a fresh GNOME desktop it already has gpg-agent ongoing with zero configuration (thanks to systemd). So by all practical means the backend side is sort of almost defacto standard.

Great, got it working:

• https://lkml.org/lkml/2024/3/24/14
• https://lore.kernel.org/all/D01IRZK3V45H.3594SKXE83TN9@kernel.org/T/#t

#linux #kernel #kprobes #riscv

@orsinium Right one other thing is that any tool must by practical means be compatible with gpg-agent. I'm voting for better interface but because of incompatibility issues it actually would be better off if it could persist to the gnupg's backing storage. This for compatibility with session managers, gpg-agent and all sorts of GUI applications dealing with OpenPGP keys.

It's my old #kprobes fix but scaled down to only riscv: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=kprobes-v2&id=751d26b0addddf0470f6a9383e7da4b3d23b8b4e

Note that I've not even compile-tested this yet, i.e. due to changes still.

Yes, something like kprobes_alloc perhaps could make sense but I see the scope of patch sane: it does a necessary evolutionary step towards more logical separation.

making my first arch/riscv patch ever :-) nothing flashy but you have to start from something in everything… #linux #kernel #riscv

@orsinium BTW, I'd suggest you to do some day comparison with your tool and https://www.kernel.org/doc/html/latest/process/maintainer-pgp-guide.html.

That sets the bar for considering alternative tool. That is not to say that the current version does not but I don't have that information. If it can do equivalent management and is fully compatible with the existing management, then it can be potentially used for kernel development.

@orsinium I've yet to meet a person who would describe gpg command-line as "approachable", so even "approachable to someone" would be a level up...

@orsinium OK, cool, sounds interesting!

Does it play together with hardware such as Yubikey?

Learned a bit o #python #gnupg bindings to automate tasks, as gpg command line can be sometimes a bit confusing and ambiguous.

E.g. this is how to purge revoked keys after gpg --refresh-keys:

#!/usr/bin/env python3

import gnupg

if __name__ == "__main__":
    gpg = gnupg.GPG()
    keys = gpg.list_keys(True)
    for k in keys:
        info_db = k['subkey_info']
        for subk in k['subkeys']:
            info = info_db[subk[0]]
            if info['trust'] == 'r':
                fp = subk[2]
                print(f"{fp} {gpg.delete_keys(fp, expect_passphrase=False, exclamation_mode=True)}")

Definitely worth of trouble because I’m super-talented on making destructive mistakes with command-line arguments :-)

have to admit that i’ve missed this before but better late than never: https://libguestfs.org/. super useful #qemu

@sgued When I started programing, I used Turbo Pascal and Turbo Assembler a lot. Turbo Pascal was basically like Rust, and Rust is like modern take on Niklas Wirth's ideas. Ideas in Rust are not new in computer science, it was more like that there was two decades of strongly typed languages not trending.

@sgued Kernel is a resource manager if you strip down the gist of it.

Anything else with some sort of resource manager benefits from more stringent memory management.

Most of the stuff that make money-wise sense to do in Rust ends up being some sort of resource manager in any kind of commercial setting.

For stuff that is not resource manager it is cheaper to use something like Python or (ugh) JavaScript. For non-trivial orchestration something like Go is factors more productive than Rust. Where Rust makes generally sense is where you want to pay more from R&D.

E.g. if you strip down the gist of something like Unreal Engine, it is a resource manager.

Not really much to do with kernel in that sense. It is just that Rust does not support all features where it is profitable for business to invest in Rust.

@sgued Optimal would be if Rust would require explicit allocations and checks for OOM conditions. The way heap works in Rust's stdlib is not how I would like it to work and heapless is best suboptimal solution for that to this date...

Rust's borrow checker is essentially solution for only one vector of memory conditions, i.e. it does not deal with over-consumption of memory.

In addition to looking how #Ubuntu #TPM2 boots I'm also somewhat interested on how e.g. #Fedora and #OpenSUSE are approaching this, or will do so in future. I have OpenSUSE in my main desktop but it is still using traditional passphrase style...

IMHO best way to address AI plagiarism would be to educate the staff on the topic.

E.g. just with human eye and simple comparison you can often spot snippets of wikipedia articles.

Also, models always lag behind so by adding as up to date stuff as possible to assignments the applicability of AI will decrease by factors.

Generally speaking AI risks should be dealt same way as vulnerabilities and malware, i.e. you should think it as a process rather than a something ending up with some final solution.

What puzzles me here is that 0x81010001 is reserved handle by TCG for the endorsement key so why would Ubuntu ever pick that as the NV index?

I'm confused but I barely skimmed the tpm2 tools outputs (tpm2_readpublic etc.).

For any Linux distribution builders out there, please read carefully before making any non-compliant changes: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/

That said I did not investigate this yet properly so forgive me I missed something essential :-)

This is way way too whitepaper'ish and lacks all the details: https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-coming-to-ubuntu

Just looking at what #Ubuntu installation stores #NVRAM of #TPM chip when installed with #TPM2 sealed #encrypted boot:

$ sudo tpm2_getcap handles-persistent
- 0x81000001
- 0x81010001

So: I guess the 2nd key, which has a policy bind, is what is “the fast path” with #PCR unsealing, and the first key is “the slow path” unsealed with the value given by snap recovery --show-keys.

Is this how it is laid out?

@peterkorsgaard can hold over weekend np i just thought that it would be good put it to the loop, so downshifting with this is totally fine! At least I don't want you to waste your weekend on this :-)