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 31695 invoked from network); 2 Jun 2022 04:26:34 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2022 04:26:34 -0000 Received: from maat.thinktankworkspaces.com ([45.79.94.76]) by 9front; Thu Jun 2 00:22:51 -0400 2022 Message-ID: To: 9front@9front.org Date: Wed, 01 Jun 2022 21:22:49 -0700 From: william@thinktankworkspaces.com In-Reply-To: <1d537d66-b454-46fd-b1e8-e78d7acd88a1@sirjofri.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: lossless extended configuration framework Subject: Re: [9front] Introduction and regarding guidance Reply-To: 9front@9front.org Precedence: bulk I use drawterm cloned from git repo via cmd line ./drawterm -a ip -h ip -u username and only enter password once unless I have ipso in /lib/profile then I use the password twice. Quoth sirjofri : > 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 >