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.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED
	autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 7227 invoked from network); 8 Apr 2023 19:00:53 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 8 Apr 2023 19:00:53 -0000
Received: from mail2.ecloud.global ([135.181.6.248]) by 9front; Sat Apr  8 14:59:38 -0400 2023
Received: from authenticated-user (mail2.ecloud.global [127.0.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail2.ecloud.global (Postfix) with ESMTPSA id D61E8720A31
	for <9front@9front.org>; Sat,  8 Apr 2023 18:59:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e.email; s=mail2;
	t=1680980369;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=czoX9XiO4lYNt+HuDbKMr6t3fsPOgX6o4g+Xqb1ZUyw=;
	b=CFj3LUwgXVHSKgqR1xfJSA3WJF39PDX+6eTF92kSR/ZriCrvw4TtebGYR76hW2P660vFIM
	cQc8rLmp6QlqtaUR0QrNcYT/byv+6ALV/0wRyszD7VZYGosqIhIE+kZiaa6kEqIajM5czR
	QUuzlrLUo0GR8h2utMzKKIBGG1JP99Y=
Date: Sat, 8 Apr 2023 18:59:25 +0000 (UTC)
From: ooga@e.email
To: 9front@9front.org
Message-ID: <2395b93a-cc5d-4e87-8aae-20de85191293@e.email>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Correlation-ID: <2395b93a-cc5d-4e87-8aae-20de85191293@e.email>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=e.email;
	s=mail2; t=1680980369;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=czoX9XiO4lYNt+HuDbKMr6t3fsPOgX6o4g+Xqb1ZUyw=;
	b=MZo9oexPFfVp4o07rrOyBAYW55FGrc/Pw1BDF8g0cW5YBjpdt5L7vnhvgcPmdxb+9lv0CL
	1hbAcU3Cm2y91E4DQeLjIhEBN/IyZF2Xu5nHvBWIN+pYnbzAGD7p51DXr25zhEEFOSk8It
	cJG7n04KLcem61yJZFNZPePeVuc51Ug=
ARC-Seal: i=1; s=mail2; d=e.email; t=1680980369; a=rsa-sha256; cv=none;
	b=tnCuVJ9fIdspGeFoTo10SpL5Odkn6d+H7LObp/y3SKvhbgmCQc2ROHu4B8B5RaFvEXXi5u
	tVpXg7u5wIYBn9KlhC+/EtyA9D3DXE33UJi6vrRxSeZJbw72NScN7phNgYYOgFPwe0qDFe
	/+iopPf9LIXxd+0N/PD52rbReJYzk7g=
ARC-Authentication-Results: i=1;
	mail2.ecloud.global;
	auth=pass smtp.mailfrom=ooga@e.email
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: lossless anonymous element callback-based dependency package-oriented event 
Subject: [9front] Loading TLS keys from secstore during boot
Reply-To: 9front@9front.org
Precedence: bulk

On an all-in-one plan9 install, auth+fs+cpu, I load the private TLS keys into factotum from cpurc (from disk). All is fine with the https, IMAP and SMTP servers, but I wonder if I can keep the keys in secstore, instead of the /sys/lib/tls/acmed/ directory.

I've created the sectsore for glenda (with the factotum file holding the TLS keys), I've run auth/wrkey again, this time filling the secstore password (of glenda). But, on boot, factotum has only the authentication keys (p9sk1, dp9ik). It is true that auth/secstored is started in my /cfg/$sysname/cpurc, when factotum is already running. So, I think I miss something and more :)

The FQA mentions that I shouldn't fill the secstore password when I run auth/wrkey on an auth server, but I don't see how else can I do it. If I run auth/secstore, it asks the password. I was hopping the kernel will load that from nvram during boot.

Why it doesn't work?
What else can I do?