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,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 11725 invoked from network); 2 Jun 2022 01:58:42 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2022 01:58:42 -0000
Received: from out0.migadu.com ([94.23.1.103]) by 9front; Wed Jun  1 21:55:59 -0400 2022
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pixelhero.dev;
	s=key1; t=1654134956;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=XtLqR3gDmZTAJQNYUwDvw12ZTtqWLrvoRuQ/KyVQafM=;
	b=Tnm7t2/mS+0KG2MHoGNJ/mwZo7xE2dJ3z6P4nCMVWa606DrucXFH5pqhobeomOFkReoWOt
	o5zRPrTRUUxJeC9PlExzFZ4conDxlwYT1tXD9bvHgdtkNL12C6L5ZEVPdYv/nSb/I1dgFV
	m//2dPINF3EXf44l9ae9yoL2RyxIDlY77BXqDVYWuK7TVQh6dK800fN7HFRXhLSugFYPE1
	93zQThi/B7d63cK0lzN1a2VKirURLlmGQMxllnQjgUU7HlYKzgZoz0qYguD9pZjcXW3Zn9
	lh8FNQLX3e4lZwSAFD9MQ9lmJ3G4tKFTpSBRWS2d59B3DSWtTOe1EwtRekHAZg==
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 01 Jun 2022 21:54:41 -0400
Message-Id: <CKF9VM8MM8DB.2SAW1H6K35QV7@pixelpc>
Cc: 
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: "Noam Preil" <noam@pixelhero.dev>
To: <9front@9front.org>
References: <AD01B85F54A3C00F8C3E8DD888CCE35F@eigenstate.org>
 <cf87d038-e3c4-6d1e-d7dc-6e6f55c19960@fjrhome.net>
In-Reply-To: <cf87d038-e3c4-6d1e-d7dc-6e6f55c19960@fjrhome.net>
X-Migadu-Flow: FLOW_OUT
X-Migadu-Auth-User: pixelhero.dev
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: generic hosting-aware just-in-time manager 
Subject: Re: [9front] Introduction and regarding guidance
Reply-To: 9front@9front.org
Precedence: bulk

Hey,

I looked into this a few months ago for much the same reason.

First, drawterm has to auth *to* the remote, to start the session. To do
so via secstore, it loads the auth key from secstore, discards the=20
secstore file, and uses the key to auth in (then forgetting the key as
with any other).

Factotum loaded *from the remote end* then gets started, and wants the
keys from secstore. So, it logs into secstore as with any other time
you run auth/factotum in userspace.

In theory, there's a couple solutions:

* Accept the status quo. This isn't a great answer, but really there's
two things doing authentication, so why *shouldn't* it ask for the
password twice?

* Well, maybe there shouldn't be two things during authentication. If
factotum is run *by drawterm*, and that normal factotum is used for
initial auth, then there's no need to run factotum after connecting, and
the password only gets asked for once.

* Or, maybe drawterm should hold on to the factotum keys from secstore,
seed them to the factotum, and *then* forget them.

There's probably a couple options I haven't thought of. The hardest part
is to figure out *desired* behavior. Once that's known, the actual code
should be relatively straightforward.

- Noam Preil