From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue,  4 Oct 2005 22:04:25 +0100
From: Uriel <uriell@binarydream.org>
To: 9fans <9fans@cse.psu.edu>
Message-ID: <20051004210425.GC19776@server4.lensbuddy.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.11
Subject: [9fans] p9sk2
Topicbox-Message-UUID: 93ca41be-ead0-11e9-9d60-3106f5b1d025

I was trying to document -O in cpu(1) which is undocumented, it enables
'p9sk2', but what that does is rather confusing, my initial guess was that it
was a deprecated version of p9sk1,  but lookman p9sk2 pointed me at
factotum(4) which says:

p9sk1   a Plan 9 shared key protocol described in
      authsrv(6)'s ``File Service'' section.
p9sk2   a variant of p9sk1 described in authsrv(6)'s
      ``Remote Execution'' section.

(Oh, and it seems that factotum(4) in p9p and in Plan 9 are out of sync..
*sigh*)

Looking at authsrv(6) leaves me even more confused. 

But auth/factotum/p9sk1.c seems to confirm the original theory:

% grep p9sk2 /sys/src/cmd/auth/factotum/p9sk1.c|sed 1q
 * p9sk1, p9sk2 - Plan 9 secret (private) key authentication.

This all started because cpu -O is used in
http://plan9.bell-labs.com/wiki/plan9/Drawterm_to_your_terminal/

My guess is that it's needed for drawterm to be able to connect, will dt2k
fix that? what is up with dt2k anyway?

uriel