[9fans] backwards-incompatible changes

[9fans] backwards-incompatible changes

[Russ Cox]

There are two backwards incompatible changes
that will appear on sources tomorrow.  If you prepare
for them, nothing will break when you do the pull.

First, namespace files now have a `.' syntax to include
other files.  /lib/namespace will include /lib/namespace.$sysname.
Thus, namespace.$sysname will become additions to the
default name space rather than replacing it.  To prepare for
this change, add the line ``clear'' to the top of any
namespace.$sysname files you have.  The old code
will ignore it, and the new code will do rfork(RFCNAMEG)
when it sees it.  Once you are running the new code
everywhere, you can trim your namespace.$sysname
files considerably.

Second, the handling of rsa keys is redone.  The new
tools are already out -- see rsa(8).  

There will be a new ssh client that looks for keys
identified by 

	proto=rsa service=ssh

rather than

	proto=sshrsa

If you put both tags on the key, that will work with
either ssh.  Once you've switched, you can remove
the proto=sshrsa tag.

There will be a new sshserve that uses factotum
to hold the host key, identified by

	proto=rsa service=sshserve

You can convert with

	awk '{
		printf("key proto=rsa service=sshserve owner=* ");
		printf("size=%s ek=%s !dk=%s n=%s !p=%s !q=%s !kp=%s !kq=%s !c2=%s\n",
			$1, $2, $3, $4, $5, $6, $7, $8, $9);
	}' /sys/lib/ssh/hostkey.secret

After the switch you can delete hostkey.secret.

TLS will look for keys identified by

	proto=rsa service=tls

rather than

	proto=sshrsa

As with the ssh client, if you put both tags on the key,
it will work with old and new.

Also, and not an incompatibility, there is a new factotum
that knows about an ``owner'' tag to specify who can use
the key.  owner=* means anyone, otherwise you give
a list owner=rsc owner=presotto etc.  This way, you can
publish, in bootes's factotum, the SSH host key and
TLS key, and then services using them can run as none.

Summary:

	- add "clear" to the top of your namespace.$sysname files
	- add "proto=rsa service=ssh" to your ssh client keys
	- add your ssh host key to factotum
	- add "proto=rsa service=tls" to your tls server keys

Russ

Re: [9fans] backwards-incompatible changes

[Dan Cross]

> First, namespace files now have a `.' syntax to include
> other files.

Hooray!  But,

> /lib/namespace will include /lib/namespace.$sysname.
> Thus, namespace.$sysname will become additions to the
> default name space rather than replacing it.  To prepare for
> this change, add the line ``clear'' to the top of any
> namespace.$sysname files you have.  The old code
> will ignore it, and the new code will do rfork(RFCNAMEG)
> when it sees it.  Once you are running the new code
> everywhere, you can trim your namespace.$sysname
> files considerably.

Ick.  Why not include a /lib/namespace.local, which can do things as it
sees fit?  The rationale here is that one can keep /lib/namespace the
same as on sources (reducing the maintenance burden), but provide much
the same functionality (/lib/namespace.local can include
/lib/addns.$sysname or something similar).

	- Dan C.

Re: [9fans] backwards-incompatible changes

[Russ Cox]

> Ick.  Why not include a /lib/namespace.local, which can do things as it
> sees fit?  The rationale here is that one can keep /lib/namespace the
> same as on sources (reducing the maintenance burden), but provide much
> the same functionality (/lib/namespace.local can include
> /lib/addns.$sysname or something similar).

Because including /lib/namespace.$sysname is a sensible default.
Perhaps /lib/namespace.local should also be included, in the
spirit of /rc/bin/termrc.local and /lib/ndb/local, but that's separate.
If we did it your way, everyone who wanted to use a
/lib/namespace.$sysname would have to create /lib/namespace.local
and maintain that themselves.  I don't see a good reason for it.
You should be able to customize, not be forced to.

Put another way, we use /lib/namespace.$sysname.  Therefore, 
the include of that should go in /lib/namespace (which we can 
tweak) rather than /lib/namespace.local (which is left for you to
tweak).

Re: [9fans] backwards-incompatible changes

[Dan Cross]

> > Ick.  Why not include a /lib/namespace.local, which can do things as it
> > sees fit?  The rationale here is that one can keep /lib/namespace the
> > same as on sources (reducing the maintenance burden), but provide much
> > the same functionality (/lib/namespace.local can include
> > /lib/addns.$sysname or something similar).
> 
> Because including /lib/namespace.$sysname is a sensible default.

Which already has another well-defined meaning and is commonly.

> Perhaps /lib/namespace.local should also be included, in the
> spirit of /rc/bin/termrc.local and /lib/ndb/local, but that's separate.

I think that'd be a good idea.

> If we did it your way, everyone who wanted to use a
> /lib/namespace.$sysname would have to create /lib/namespace.local
> and maintain that themselves.  I don't see a good reason for it.
> You should be able to customize, not be forced to.

But we're already being forced to customize /lib/namespace.$sysname,
something that is already established and in common use.  How's that
different from maintaining /lib/namespace.local?  How is having
/lib/namespace.local `forcing' you to customize?

> Put another way, we use /lib/namespace.$sysname.  Therefore, 
> the include of that should go in /lib/namespace (which we can 
> tweak) rather than /lib/namespace.local (which is left for you to
> tweak).

I'm not opposed to the idea of including /lib/something.$sysname in
/lib/namespace, but I think the naming convention is a little weird.
Why not call it /lib/addns.$sysname or something like that?  Why
overload the meaning of /lib/namespace.$sysname?

	- Dan C.

Re: [9fans] backwards-incompatible changes

[Russ Cox]

> Which already has another well-defined meaning and is commonly.

We have about 20 namespace.$sysname files here, and every
one of them was only appending to the standard name space
rather than replacing it.  And they weren't doing a good job either --
many of them had diverged from namespace since being created.
The common case thus appears to be append rather than replace.
Further, we couldn't see any reason you'd really want to replace.
Hence we changed the default interpretation.   The only reason we
added the ``clear'' verb was to make a smooth transition possible.

I think the only reason namespace.$sysname sounds weird to you
for ``things to run after running namespace'' is that you've already
got it stuck to ``things to run instead of running namespace.''  
I don't think there's anything inherently strange about the new
convention.

> Why overload the meaning of /lib/namespace.$sysname?

We didn't overload it.  We replaced it.  /lib/addns.$sysname
sounded clunky, and we didn't have any better ideas.
Think of it as fixing a bug in the way namespace.$sysname
works. 

> But we're already being forced to customize /lib/namespace.$sysname,
> something that is already established and in common use.  How's that
> different from maintaining /lib/namespace.local?  How is having
> /lib/namespace.local `forcing' you to customize?

The fact that newns consults /lib/namespace.$sysname is useful.
Unless I misunderstand you, you are proposing that /lib/namespace
should include /lib/namespace.local, which should, if the user feels
like it, include /lib/namespace.$sysname.  So you're forced to create
/lib/namespace.local in order to get this useful commonly-used 
not-really-local feature of including namespace.$sysname.
That feels like a mistake.

Russ

Re: [9fans] backwards-incompatible changes

[Geoff Collyer]

/lib/namespace.httpd has always been an addendum, so namespace files
that add to the namespace rather than creating it from scratch are
nothing new.

Re: [9fans] backwards-incompatible changes

[Russ Cox]

A few more notes. 

If you're running a straight terminal out of the box,
the only point that affects you is the SSH client key
renaming.

To be more explicit about how to make the RSA changes:

* If you use SSH to connect to other systems using an RSA key,
right now you have a key 

key ek=dd n=e5306cf4e... proto=sshrsa size=1024 !dk? !p? !q? !kp? !kq? !c2?

in your own personal factotum.  You need to
s/proto=sshrsa/proto=sshrsa proto=rsa service=ssh/.
Keeping "proto=sshrsa" means the key will keep working now.
Adding "proto=rsa service=ssh" means the key will work later.

* If you run TLS servers, your server factotum contains a key like:

key ek=dd n=e5306cf4e... proto=sshrsa size=1024 !dk? !p? !q? !kp? !kq? !c2?

You need to s/proto=sshrsa/proto=sshrsa proto=rsa service=tls/.
Same explanation, except note the different service tag.

You may be loading the key into factotum with

	auth/secretpem key.pem >/mnt/factotum/ctl

Instead, use

	auth/pemdecode 'RSA PRIVATE KEY' key.pem |
	auth/asn12rsa -t 'service=tls' >key.rsa

and then you can load the key with

	cat key.rsa >/mnt/factotum/ctl

or add key.rsa to your server's factotum secstore file.

* If you run an SSH server, you generated a host key long ago
with aux/ssh_genkey.  It is stored in /sys/lib/ssh/hostkey.secret.
You need to convert it into standard factotum RSA format and
load it into factotum:

	cd /sys/lib/ssh
	awk '{
		printf("key proto=rsa service=sshserve ");
		printf("size=%s ek=%s !dk=%s n=%s !p=%s !q=%s !kp=%s !kq=%s !c2=%s\n",
			$1, $2, $3, $4, $5, $6, $7, $8, $9);
	}' hostkey.secret >hostkey.rsa
	chmod 600 hostkey.rsa

If you load your server's factotum key ring via secstore, add
the contents of hostkey.rsa to the factotum file.  If you don't,
then you should add

	cat /sys/lib/ssh/hostkey.rsa >/mnt/factotum/ctl

to your cpurc to hand the key to factotum.

===

I'll put the changed sources out soon, but will not install
the binaries until tomorrow evening.  The rsa(8) tools are
supposed to be more regular and easier to understand 
than the ad hoc collection we had before.  I apologize for the
fact that they are changing.  Hopefully it's a small short-term 
inconvenience for a long-term gain.

Russ