From: sirjofri <sirjofri+ml-9front@sirjofri.de>
To: 9front@9front.org
Subject: Re: [9front] Introduction and regarding guidance
Date: Thu, 2 Jun 2022 03:05:38 +0000 (UTC) [thread overview]
Message-ID: <1d537d66-b454-46fd-b1e8-e78d7acd88a1@sirjofri.de> (raw)
In-Reply-To: <CKF9VM8MM8DB.2SAW1H6K35QV7@pixelpc>
Hello,
02.06.2022 03:54:41 Noam Preil <noam@pixelhero.dev>:
> 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
next prev parent reply other threads:[~2022-06-02 3:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-01 20:36 Deepak kr. Mahato
2022-06-01 22:43 ` ori
2022-06-02 0:27 ` Frank D. Engel, Jr.
2022-06-02 1:54 ` Noam Preil
2022-06-02 3:05 ` sirjofri [this message]
2022-06-02 3:21 ` noam
2022-06-02 4:22 ` william
2022-06-02 4:55 ` Mart Zirnask
2022-06-02 5:02 ` sirjofri
2022-06-02 14:44 ` Deepak kr. Mahato
2022-06-02 14:50 ` Stanley Lieber
2022-06-02 14:51 ` Christos Margiolis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d537d66-b454-46fd-b1e8-e78d7acd88a1@sirjofri.de \
--to=sirjofri+ml-9front@sirjofri.de \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).