From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27575 invoked from network); 4 Mar 2023 09:43:47 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 4 Mar 2023 09:43:47 -0000 Received: from sirjofri.de ([5.45.105.127]) by 9front; Sat Mar 4 04:40:26 -0500 2023 Received: from dummy.faircode.eu ([109.43.50.90]) by sirjofri.de; Sat Mar 4 10:40:18 +0100 2023 Date: Sat, 4 Mar 2023 10:40:14 +0100 (GMT+01:00) From: sirjofri To: 9front@9front.org Message-ID: <5840f023-1688-4b96-874a-bf2fd6d1db26@sirjofri.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Correlation-ID: <5840f023-1688-4b96-874a-bf2fd6d1db26@sirjofri.de> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: extensible responsive extension callback deep-learning layer Subject: [9front] Factotum "extensions" and secstore security Reply-To: 9front@9front.org Precedence: bulk Hello, I was wondering how factotum behaves if it's fed with keys that factotum doesn't understand, e.g. with a proto that factotum can't handle? I'm planning on changing factotum a bit, but maybe only on one machine to keep stability. Though it is easy to just feed the locally adjusted factotum with the new secrets, I'm still wondering if it's fine to keep all the secrets in one file (secstore-style) and if the unchanged factotum will just ignore them. For those wondering, I'm planning for proto=totp and maybe even an updated secstore that allows for totp-based security since I've heard that secstore isn't secure for modern standards (with the suggestion to only run it on a local network). So, what's the state of secstore? How would a more secure version of secstore look like? sirjofri