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=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21326 invoked from network); 2 Jun 2022 03:08:48 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2022 03:08:48 -0000 Received: from sirjofri.de ([5.45.105.127]) by 9front; Wed Jun 1 23:05:42 -0400 2022 Received: from sirjofri.de ([109.43.51.126]) by sirjofri.de; Thu Jun 2 05:05:38 +0200 2022 Date: Thu, 2 Jun 2022 03:05:38 +0000 (UTC) From: sirjofri To: 9front@9front.org Message-ID: <1d537d66-b454-46fd-b1e8-e78d7acd88a1@sirjofri.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Correlation-ID: <1d537d66-b454-46fd-b1e8-e78d7acd88a1@sirjofri.de> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: agile standard browser-oriented extension Subject: Re: [9front] Introduction and regarding guidance Reply-To: 9front@9front.org Precedence: bulk Hello, 02.06.2022 03:54:41 Noam Preil : > 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 > 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? That's what I currently personally do. Also sometimes you don't need a factotum at all. > * 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. If you look in default lib/profile that's what is done here: the /mnt/term/dev/secstore file is read into /mnt/factotum/ctl to add the keys, then the file is cleared. So much for the theory, I never got it working. > * Or, maybe drawterm should hold on to the factotum keys from secstore, > seed them to the factotum, and *then* forget them. In lib/profile this isn't done by drawterm, and I think drawterm should be agnostic to the factotum system of the host. > 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. What I believe would be a huge step forward: imagine drawterm just has a full factotum device like a 9 host. You could just forget about running a factotum on the host at all, and just bind /mnt/term/mnt/drawterm /mnt/drawterm and call it a day. It would be possible, but someone has to port factotum to drawterm, I can imagine it's not that easy because of platform specific code. Some magician who listens could do that. My 2 cents, as a drawterm-on-windows user. sirjofri