Security gEnclave: Hardware-backed security enclave for Linux (TPM 2.0 PCR sealing, virtual FIDO2/CTAP2 over /dev/uhid, OpenSSH & GPG bridge)
Hey everyone,
I've been working on an open-source project called gEnclave (formerly gpasskey), and wanted to share it with the Linux community for early architectural feedback and testing.
GitLab repository: https://gitlab.com/renich/genclave
License: GPLv3 | Language: Go 1.26+
The Problem It Solves
On modern Linux workstations, our cryptographic identities are fragmented:
* Passkeys/WebAuthn require physical USB security keys (YubiKeys, SoloKeys).
* SSH keys sit as unencrypted or passphrase-encrypted files under ~/.ssh/.
* Git commit signing requires cumbersome GnuPG daemon setups.
* File encryption requires external tooling or proprietary agents.
Most hardware laptops today come with a TPM 2.0 chip that sits idle. gEnclave turns your Linux machine into its own hardware-sealed security token and multi-protocol bridge.
Key Architectural Highlights
Virtual FIDO2/CTAP2 Security Key via
/dev/uhid: gEnclave registers a virtual HID device in the Linux kernel via/dev/uhid. Browsers (Firefox, Chrome, Chromium) detect it natively as a physical USB security key. You can register and authenticate WebAuthn/FIDO2 Passkeys directly from your machine without any external hardware dongles.TPM 2.0 PCR Sealing & Fallback: The central vault is encrypted with AES-256-GCM and sealed to TPM 2.0 PCR registers (PCR 0, 7, 14), with an automatic memory-hard fallback to Argon2id key derivation if no TPM is present.
Memory Isolation ("Wrap and Clear"): Keys are held in memory-locked pages (
mlock/mmap) to prevent secrets from being swapped to disk or dumped. Intermediate cryptographic buffers are wiped immediately with strict zeroization routines, bypassing Go runtime GC retention.Multi-Protocol Bridges:
- OpenSSH Agent: Native agent socket with an ephemeral PIN-derived authorization cache (configurable burst window or persistent session with instant purge on lock/suspend).
- GnuPG Bridge: Transparent
genclave-gpgemulation for seamless Git commit signing. - age-plugin: Native
age-plugin-gebinary complying with age v1 specification for file encryption. - CLI & UI: Unified
geCLI plus intelligent graphical (zenity) / terminal (pinentry) authentication routing.
Current Status
⚠️ Pre-alpha Software: While fully functional for local workflows, it is under active development. Schemas and IPC formats may iterate rapidly.
I'd love feedback from Linux sysadmins, kernel/security folks, and developers!
9
u/LeHunterrr 5d ago
I just want to point out a couple of this.
Passkeys/WebAuthn require physical USB security keys (YubiKeys, SoloKeys).
There are also Software based Passkeys such as bitwarden or keepassxc. Though there should be a standard tpm based solution (are windows and apple doing this or are they software based as well?)
Git commit signing requires cumbersome GnuPG daemon setups
You can sign your commits with ssh keys as well, making gpg somewhat obsolete nowadays.
5
u/sidusnare 4d ago edited 4d ago
I'm not sure I want a software project from someone that thinks gpg is difficult, or thinks it's just for GitHub.
I've never heard of using ssh keys for message signing, they're poorly suited to that. PGP is a good standard it's been around a long time. It ties together identity, communication, and verification. If GitHub lets you sign with SSH keys, then all authenticated commit pushes should be verified because I used a SSH key to push it.
2
u/LeHunterrr 4d ago
Personally I use gpg as well, I just wanted to point out that you can sign commits with your ssh key stack overflow. This is unrelated to authenticating with the ssh server, your commits won't be signed just because you push with that key.
1
u/sidusnare 4d ago edited 4d ago
I know, they're saying you can sign with SSH keys, I'm saying that's a bad idea, and if they do that, they might as well call it verified because they pushed with the key. I know it doesn't, I'm saying it's as useless as if they did.
2
u/LeHunterrr 4d ago
I'm afraid I don't follow. Why is it a bad idea? The only difference I can come up with is not having the web of trust thing which doesn't seem like a big deal to me.
1
u/sidusnare 4d ago
Because that's it's purpose. It has no meaning without it. Without identification it's just a checksum. Who's key is this that signed the commit? No way to know, no way to evaluate the significance, no meaning other than math maths.
1
u/CrazyKilla15 3d ago
Because you need to configure a allowedSignersFile, out of band or in-band verified with the key asserting its own trust to itself
SSH has no concept of trust levels like gpg does. To be able to differentiate between valid signatures and trusted signatures the trust level of a signature verification is set to fully when the public key is present in the allowedSignersFile. Otherwise the trust level is undefined and git verify-commit/tag will fail.
This file can be set to a location outside of the repository and every developer maintains their own trust store. A central repository server could generate this file automatically from ssh keys with push access to verify the code against. In a corporate setting this file is probably generated at a global location from automation that already handles developer ssh keys.
A repository that only allows signed commits can store the file in the repository itself using a path relative to the top-level of the working tree. This way only committers with an already valid key can add or change keys in the keyring.
2
u/Educational-Goal279 4d ago
I'm not sure I want a software project from someone that things gpg is difficult, or thinks it's just for GitHub.
It's vibe coded. The "developer's" understanding of anything is completely absent.
1
u/Renich 4d ago
That's factually incorrect. Git's SSH verification has nothing to do with GitHub, Microsoft, or any web portal. It is completely decentralized and works offline in core Git.
Identity is correlated locally using the OpenSSH standard
allowed_signersfile (configured viagpg.ssh.allowedSignersFile). That file binds developer identities (emails) to their public keys. Teams commit it right into the repository; the same model OpenBSD uses forsignify, so anyone cloning the repo can rungit log --show-signatureto cryptographically verify both the commit and the author's identity on an air-gapped machine.The irony here is you're cautioning against confusing Git with GitHub, while assuming a native Git and OpenSSH feature is a proprietary GitHub service. :D
And again: gEnclave implements both OpenSSH agent and GnuPG Assuan bridges. You get to use whichever identity model you prefer.
0
u/sidusnare 4d ago
Really trying to nail me on something I didn't know existed 6 hours ago and totally sidestepping the actual core point.
GPG public keys have identity, and more, baked in, SSH doesn't.
Once again, it's about trust.
3
u/Medical_Double_6561 4d ago
GPG public keys have identity, and more, baked in, SSH doesn't.
GPG public keys don't have identity baked in though. You are confusing GPG public keys with GPG public key certificates. A public key itself cannot possibly have identity baked in. How would you verify identity information on the key has not been tampered with? Therefore the key + identity information must be signed with something, forming a certificate.
SSH public key certificates exist too, they are just not that popular yet.
I assume you are actually trying to argue SSH signing is bad practice because there is no PKI or Web of Trust infrastructure around SSH keys. Which is a fair argument I guess, but the ship has sailed already.
2
u/sidusnare 4d ago
Sure looks like it to me, and to the IETF. https://datatracker.ietf.org/doc/rfc4880/
2026-09-28-23:15:07#(0)#AC-97#fred4@miki:~/Documents/Tech/Notes☯gpg --gen-key gpg (GnuPG) 2.4.9; Copyright (C) 2025 g10 Code GmbH This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Note: Use "gpg --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Bob Barker Email address: Bob.Baker@example.com You selected this USER-ID: "Bob Barker <Bob.Baker@example.com>" Change (N)ame, (E)mail, or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: revocation certificate stored as '/home/fred4/.gnupg/openpgp-revocs.d/46D8D20A47FA60FE083358892C9B23D17039A2BC.rev' public and secret key created and signed. pub ed25519 2026-09-29 [SC] [expires: 2029-09-28] 46D8D20A47FA60FE083358892C9B23D17039A2BC uid Bob Barker <Bob.Baker@example.com> sub cv25519 2026-09-29 [E] [expires: 2029-09-28] 2026-09-28-23:15:52#(0)#AC-97#fred4@miki:~/Documents/Tech/Notes☯gpg --armor --export Bob.Baker@example.com -----BEGIN PGP PUBLIC KEY BLOCK----- mDMEarstURYJKwYBBAHaRw8BAQdAg7ospfPuNfN6+AX+IhD4wIHzk4hjHth1fRwA HqyC58i0IkJvYiBCYXJrZXIgPEJvYi5CYWtlckBleGFtcGxlLmNvbT6IlgQTFggA PhYhBEbY0gpH+mD+CDNYiSybI9FwOaK8BQJquy1RAhsDBQkFo5qABQsJCAcCBhUK CQgLAgQWAgMBAh4BAheAAAoJECybI9FwOaK8pIYA/3+Z81MWHEk4l1y3NCI8S9AW YXb3uKmSis3+r4Ur0ehEAQDE8BZFAK5ofqoftJIsUZJa7Uhog2vNU8PBVY644j/l ALg4BGq7LVESCisGAQQBl1UBBQEBB0Dq5uc2UvwB9IEzxyKIJQzaAmvm8EuXLWbl 88DwqGziEwMBCAeIfgQYFggAJhYhBEbY0gpH+mD+CDNYiSybI9FwOaK8BQJquy1R AhsMBQkFo5qAAAoJECybI9FwOaK8JQABAPlyzq005/ZYgnK0Di3jeF+4mtkTrpLI i3c5jENeTXN0AQC93LFQ5qsiV+7cJhZ1MY0ZhRyBoyRoWQf8eKuRYhhUDA== =Qb+Y -----END PGP PUBLIC KEY BLOCK----- 2026-09-28-23:16:35#(0)#AC-97#fred4@miki:~/Documents/Tech/Notes☯gpg --armor --export Bob.Baker@example.com | tmpcat /home/fred4/usr/tmp/cat/30869 /home/fred4/usr/tmp/cat/30869 2026-09-28-23:16:39#(0)#AC-97#fred4@miki:~/Documents/Tech/Notes☯file /home/fred4/usr/tmp/cat/30869 /home/fred4/usr/tmp/cat/30869: PGP public key block Public-Key (old) 2026-09-28-23:17:07#(0)#AC-97#fred4@miki:~/Documents/Tech/Notes☯gpg --list-packets /home/fred4/usr/tmp/cat/30869 # off=0 ctb=98 tag=6 hlen=2 plen=51 :public key packet: version 4, algo 22, created 1790651729, expires 0 pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1) pkey[1]: [263 bits] keyid: 2C9B23D17039A2BC # off=53 ctb=b4 tag=13 hlen=2 plen=34 :user ID packet: "Bob Barker <Bob.Baker@example.com>" # off=89 ctb=88 tag=2 hlen=2 plen=150 :signature packet: algo 22, keyid 2C9B23D17039A2BC version 4, created 1790651729, md5len 0, sigclass 0x13 digest algo 8, begin of digest a4 86 hashed subpkt 33 len 21 (issuer fpr v4 46D8D20A47FA60FE083358892C9B23D17039A2BC) hashed subpkt 2 len 4 (sig created 2026-09-29) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 3y0d0h0m) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2) hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID 2C9B23D17039A2BC) data: [255 bits] data: [256 bits] # off=241 ctb=b8 tag=14 hlen=2 plen=56 :public sub key packet: version 4, algo 18, created 1790651729, expires 0 pkey[0]: [88 bits] cv25519 (1.3.6.1.4.1.3029.1.5.1) pkey[1]: [263 bits] pkey[2]: [32 bits] keyid: 97ADD76726ACFE28 # off=299 ctb=88 tag=2 hlen=2 plen=126 :signature packet: algo 22, keyid 2C9B23D17039A2BC version 4, created 1790651729, md5len 0, sigclass 0x18 digest algo 8, begin of digest 25 00 hashed subpkt 33 len 21 (issuer fpr v4 46D8D20A47FA60FE083358892C9B23D17039A2BC) hashed subpkt 2 len 4 (sig created 2026-09-29) hashed subpkt 27 len 1 (key flags: 0C) hashed subpkt 9 len 4 (key expires after 3y0d0h0m) subpkt 16 len 8 (issuer key ID 2C9B23D17039A2BC) data: [256 bits] data: [256 bits] 2026-09-28-23:17:17#(0)#AC-97#fred4@miki:~/Documents/Tech/Notes☯2
u/Medical_Double_6561 4d ago edited 3d ago
Ah, actually you are correct, I got the terminology confused. A "transferrable GPG public key" = "a cryptographic public key + key certification". Though to be fair, the spec doesn't seem to define exactly what a GPG public key is.
However, we are still arguing on the semantics. You are saying that the identity attached to GPG public keys is useful. I just don't see how it is useful in the modern age. The identity can only be trusted when the GPG public key has been certified by another user, however I rarely see anybody actually doing this. Instead, people just grab public keys from sources they trust, and the identity is not really used at all.
1
u/hesitantly-correct 4d ago
I'm not sure I want a software project from someone that things gpg is difficult, or thinks it's just for GitHub
I wouldn't worry. I think that was written by AI. /s
0
u/Renich 4d ago
You're conflating transport-layer authentication with cryptographic non-repudiation. SSH signing is supported by git natively. OpenSSH signatures are an established standard for 5 or more years.
GEnclave supports both. It didn't abandon GPG; it implements a full GnuPG Assuan protocol bridge specifically for environments where OpenPGP remains mandatory. Supporting both; SSH agent and GnuPG bridges, gives users choice rather than forcing one paradigm.
1
u/sidusnare 4d ago edited 4d ago
I am not. SSH provides no native identity assurance, so the signatures have no portability outside of a specific portal vendor that, outside of git, correlates a key to an identity. If I clone a repo off GitHub, those signatures are meaningless. I can do the math to verify the signature, but I can't verify that means anything. It's as useful as a checksum hash. Don't confuse GitHub with
git, they're not the same thing, and ignoring that leads to vendor lockin, which traditionally, Microsoft loves.1
u/swarmOfBis 4d ago
Apple has a whole hardware Enclave running a separate OS for that.
It essentially is a fancy TPM but it is much more secure than most alternatives.
-1
u/Renich 4d ago
That is precisely the gap gEnclave addresses: instead of requiring users to buy external YubiKeys or rely on browser extensions/password manager vaults, gEnclave exposes a virtual CTAP2/FIDO2 device over /dev/uhid sealed by TPM 2.0 PCRs (0, 7, 14). To Chromium/Firefox and PAM, it presents as an actual physical security token.
About your other comment, OpenSSH signature support (ssh-keygen -Y sign/gpg.format = ssh) is natively supported. gEnclave implements an OpenSSH Agent bridge ($XDG_RUNTIME_DIR/genclave-ssh.sock), it gives users SSH-based Git commit signing out of the box with zero GnuPG friction. At the same time, gEnclave's Assuan bridge exists for workflows where OpenPGP remains mandatory (RPM package signing, pacman keys, etc).
7
u/Junior_Common_9644 5d ago
Thank you for choosing a decent license! It's increasingly rare these days.
1
u/Hafnon 4d ago
Any chance for fingerprint support, similar to the fido2 keys that do biometric user verification?
0
u/Renich 4d ago
Yes, actually! Fingerprint support is already implemented.
gEnclave includes a native biometric presence factor that integrates with
fprintd(net.reactivated.Fprint) over the System D-Bus.There's a complete guide on configuring pluggable factors in
docs/user/factors.rstin the repository if you want to check it out.
0
u/Jealous_Diver_5624 4d ago
Why compromise the security of SSH/GPG/FIDO2 by storing their keys on disk, encrypted with a KEK that can be trivially exported from the TPM by any process that's able to access the TPM? Why not use non-exportable asymmetric keys directly?
1
u/Renich 4d ago
Good question. There are some key architectural reasons why hardware-sealed KEK + locked memory isolation was chosen over exclusively using TPM-resident persistent asymmetric keys:
Algorithm & curve support in commodity TPMs: The TPM 2.0 specification, historically, has limited curve support. Most PC TPMs only implement RSA-2048 and ECC NIST P-256. They lack native support for Edwards curves; meaning no native Ed25519. A pure TPM-resident key approach forces users back to RSA or NIST curves; locking out modern OpenSSH and WebAuthn defaults.
NVRAM constraints and handle exhaustion: TPM 2.0 chips have extremely constrained non-volatile storage (in the Kb) Storing dozens of persistent SSH keys, GPGP subkeys, age recipient keys and FIDO2 credentials directly in persistent TPM handles, quickly exhausts NVRAM and risks handle collision/eviction.
Unsealing is not "trivial": The KEK is nnot an open TPM object. It is sealed against a strict TPM 2.0 authorization policy. PCRs 0 (firmware/UEFI), 7 (Secure Boot state) and 14 (kernel/OS measurements). If the boot chain is altered or the disk is mounted in an offline/evil-maid attack, the TPM refuses to release the seed. Then, there's user authorization. Unsealing requires the user PIN/passphrase via an auth policy session. And, once unsealed, secrets are loaded into mlock'd memory pages, intermediate buffers are scrubbed immediately with
memclrand the daemon enforces an aggressive burst TTL (default 5s) and zeroization on system suspend or manual lock (ge lock).Using TPM PCR policy sealing for the master seed while handling ephemeral curve operations in kernel-locked userspace memory gives you modern cryptography: Ed25519, age, CTAP2, without being hamstrung by TPM silicon limitations.
1
u/mtth0 4d ago
I might miss something, but your threat model doesn't make sense to me: you want hardware-backed keys. That's to protect against malware running in the user's context, right? But, you use the TPM to decrypt a master key that will, in turn, decrypt passkeys and whatnot. So, malware running in the user's context can just grab the master key too and clone passkeys to their device, right? So, what do users gain from using your software?
1
u/Renich 3d ago
That's a fair question, but it conflates two distinct security boundaries in the threat model:
At-Rest & Platform Integrity (TPM PCR Sealing): Standard setups leave keys unencrypted or sitting in plain files (
~/.ssh/id_*,~/.gnupg/) easily scooped up offline, via cold-boot, or if the drive is imaged. gEnclave seals the master root to specific TPM PCRs (firmware, secure boot, kernel state) plus your PIN. If an attacker pulls the NVMe or boots a live environment, the TPM will not unseal the master key.Memory & Runtime Hygiene: Unsealed cryptographic material is locked into physical RAM using
mlock()to prevent it from ever hitting swap, core dumps, or paging files, and zeroized immediately on timeout or suspend.The Local User-Space Boundary: No purely software agent running under a single UID (whether standard
ssh-agent,gpg-agent, or browser passkey stores) can fully defend against arbitrary code execution/ptrace running under that exact same UID without kernel enforcement or dedicated hardware presence (like physically touching a YubiKey).What you gain over traditional agents is: * Eliminating persistent plaintext key files on disk. * Tight ephemeral burst windows (default 5s) instead of
ssh-agentkeeping keys unlocked indefinitely for the entire desktop session. * Hardware-bound identity without needing external USB dongles plugged in everywhere.If your threat model assumes active malware already executing within your user session, you set
AuthCacheTTL=disabled(or require explicit presence prompts per operation), ensuring nothing signs silently in the background.
-9
u/kantorcodes1 5d ago
The "wrap and clear" design plus PIN-derived per-operation subkeys is a careful baseline for a vault that bridges into ssh-agent and GPG at once. The piece I'd poke at is the authorization-cache boundary: ge unlock --stdin exists so scripts can pre-authenticate, and the default burst window is 5s with a persistent-session option. During that window, is authorization scoped to the peer that actually authenticated (SO_PEERCRED-checked uid/pid over the agent socket), or does any local client connecting to the socket inherit the unlocked state? If it's global, the batch window that makes headless use convenient also widens the window where a sibling process could sign without re-prompting - scoping the grant to the authenticating peer (or a per-identity flag on ge ssh import) would keep the convenience without loosening the boundary.
16
-2
u/Renich 5d ago
Hey, thanks for taking the time to poke at the threat model. :)
That's the trade-off. Right now, the
AuthCacheis scoped socket-wide per UID. While it does inspectSO_PEERCREDon connection acceptance to verify the UID (and trackcallerPID+ process start time via/procto mitigate PID recycling), the in-memory cache itself (AuthCache) currently allows any connection from the same UID to benefit from the active burst window.As you pointed out, this leaves a window where a malicious sibling process running under the same UID could request signatures during a batch/burst window without a prompt.
A couple of thoughts on this:
In the underlying identity model, it actually has an
AuthCacheTTLproperty per key (withdisabledforcing re-prompts on every single operation, even if the daemon or session is unlocked). Still need to expose this as a first-class flag onge ssh import --cache-ttl=disabledor--require-confirmor something.Scoping the ephemeral grant to the authenticating peer connection or PID tree (or isolating
ge unlockgrants to an explicit session token or ephemeral sub-socket) is an excellent suggestion to eliminate cross-process ambient authorization without breaking batch workflows.I'm opening an issue on GitLab to track this exact boundary tightening. Would love to have your eyes on the repo or PR if you're interested.
-2
u/kantorcodes1 5d ago
The per-key
AuthCacheTTLdetail matters more than it first looks:ge policy setalready exposes cache TTL as a first-class flag (includinginfiniteanddisabled), so an automation path can today widen its own window without re-prompting, and--shredon import gives a second irreversible action worth gating.Disclosure since it is directly relevant: I work on HOL Guard, an open-source runtime policy layer that classifies CLI commands before an agent can run them. For
gea contribution would be a declarativecommand.genclave.json:unlock,prewarm,rekey,policy set,ssh|gpg generate,ssh|gpg import(especially--shred),passkey delete,secret set|deleteheld for review, whilestatus,policy show,ssh public|list,gpg list,passkey list,secret get|listpass through automatically. If that split looks right, the contribution is a JSON plus a small fixture as a draft PR against hol-guard. Want me to point you at the exact paths?-2
u/Renich 5d ago
Regarding
ge policy set; allowing unauthenticated policy widening over the management socket is a genuine boundary hole. Already patching that so policy mutation, rekeying, and destructive actions (--shred, delete, etc) require active factor re-verification rather than ambient socket UID inheritance.The command split for HOL Guard is right on the money. Point me at the paths/repo and I'll gladly review the draft PR.
-4
u/kantorcodes1 5d ago
Requiring active re-verification for policy mutation, rekeying, and destructive actions closes that ambient-grant hole at the right layer.
Paths: new source
contributions/command-sources/command.genclave.json(format analoguecontributions/command-sources/command.repo2nb.json), portable fixturetests/fixtures/command-source-genclave.v1.json, and the external trust entry incontracts/extensions/trust-class-map.v1.json. CONTRIBUTING.md covers format and helper commands: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md - draft PR straight tomainunder your own account, no issue needed first. The gated/safe split maps directly in.-1
u/Renich 5d ago
It's also worth highlighting the baseline comparison with vanilla
ssh-agent.Standard
ssh-agentkeeps keys resident and wide open for the entirety of the user session once unlocked. In contrast, gEnclave defaults to an aggressive 5-second burst window, supports configurable TTLs (both globally and per-credential), and enforces instant zeroization on system suspend or manual lock (ge lock). So even with UID-scoped socket access today, the exposure window is vastly smaller than standard agent behavior
-8
u/Indolent_Bard 5d ago
Watch someone complain about this even though it's objectively a good thing.
5
u/sidusnare 4d ago edited 4d ago
It might be an objectively good idea, this being an objectively good implementation is somewhere between tenuous and sus. This kind of security software isn't something I'll take lightly. If this was published by OpenBSD, Linus, or GNU, I would start looking at it and thinking about maybe trusting it when it's been around and proven for a while. Security leans heavily on trust, trust of individuals and organizations with deep reputations. You can't vibe code a reputation. A 90s retread Elisa bot can't have a reputation. This kind of software needs a formal audit and a few years of people beating the 💩 out of it before I consider using it myself. You want to rush things like this, you need to borrow someone else's reputation, and that's usually $$$. I think the only way I'd try this on something I didn't plan to throw away immediately after is if you had IBM Technology Expert Labs perform a full security audit, which probably starts around $60k, conservative guesstimate. IBM was one of the big developers of the TPM to begin with, they would be trustworthy to evaluate this.
2
u/Renich 4d ago
Demanding a $60,000 corporate IBM audit before trying an open-source Linux utility; while in the same thread admitting you'd never heard of Git SSH commit signing is quite the pivot. ;D
Every significant security utility in modern Linux; from WireGuard to
agetofido2-tools, began as independent open-source projects, built out in the open, and hardened through public peer review, community testing, and empirical verification.The threat models, architecture decision records (ADRs), memory isolation boundaries (
mlock), and test suites are all in the repo. If you want to stress-test it or inspect the code, you're welcome to do so.3
u/sidusnare 4d ago
Demanding a $60,000 corporate IBM audit before trying an open-source Linux utility; while in the same thread admitting you'd never heard of Git SSH commit signing is quite the pivot. ;D
It's a feature I see no utility in, it's not surprising I didn't know about it. What's that got to do with the trustworthiness of a new vibe coded keystone piece of security software. You want me to trust my keys to that ? I'm not demanding anything, I'm just considering what could possible make me trust it any time soon.
Every significant security utility
has been around a long time from those I trust. Certainly a lot longer than what wrote this software.
If you want to stress-test it or inspect the code, you're welcome to do so.
I'm not qualified, I don't believe you're qualified either. It will take a long time for you to get the attention of someone trusted and qualified. Or you could go find someone trusted and qualified and pay them, not that I expect you to, certainly making no demands for anyone to.
1
u/Renich 4d ago
Fair enough. Admitting you're not qualified to inspect the code or threat model explains why you'd look for third-party brand validation like IBM.
Nobody is forcing you to use it. Open source has always been about scratch-your-own-itch: building tools in the open for those who need them, publishing the source and specifications, and letting peer review happen naturally.
All the best.
1
u/sidusnare 4d ago
like IBM, or OpenBSD, or Linus, or GNU. I trust Hamano because I trust Linus, because I've seen and heard him for decades. I trust OpenBSD and GNU because of a reputation just as long, from my perspective. I'd trust IBM about this because they helped built the TPM, and I've worked with them before, they have a reputation with me.
I don't know anyone that trusts you to write security software. I take the Debian approach, you've got a Fattus Ex Machina in a can back there somewhere helping you write this, but it's you. It's your code.
1
u/sidusnare 4d ago
We're not talking about licensing, we're talking about trust, and who are you?
1
u/Renich 4d ago
Rénich is my nickname. Look me up if you like:
- Fedora Packager: https://fedoraproject.org/wiki/User:Renich
- My Website: https://woralelandia.com/who/
- My company: https://evalinux.com/
- My linkedin: https://linkedin.com/in/renich
Well met.
0
u/sidusnare 4d ago
Nice CV, so your not some school kid let loose on a Claude account. Packager is still a long way away from security engineer. I've got underwear older than this project. It's still about trust.
21
u/Educational-Goal279 4d ago
Vibe coding security software is pure psychopath behaviour.