inquery: plans for phasing out cpu, rx and import

inquery: plans for phasing out cpu, rx and import

[cinap_lenrek]

now that we have rcpu taking over for cpu, import and rx...
i want to discuss how to phase out the old protocols.

rationale:

the cpu and import protocols are flawed in several ways:

- initial handshake is not authenticated nor encypted,
  mitm attacker can change the commandline and import
  path without any credentials.

- import and rx default to unencrypted connection.

- when encrypting, defaults to rc4 with sha1... no
  automatic cipher negotiation.

- cpu and import are the only programs still needing
  devssl in the kernel.

- import's authentication negotiation requires some
  ugly code in exportfs snooping the first message
  of the 9p conversation to see if its a import calling.


the following things could be done:

- disable listen scripts for exportfs, cpu and rx services.
  so 9front machines will not serve these anymore by
  default. client would still work as normal, code still
  there and continuing maintaining it.

- rename the old programs, say, move them to /bin/old/^(cpu exportfs import ...)
  scripts will break, but program still there under a different
  name in case one needs it. code still there and will be
  maintained.

- just delete the code. you need to keep old binaries arround
  yourself to use it. and maintain your own kernel config to have
  devssl for it to work. code not maintained anymore.

suggestions?

--
cinap

Re: [9front] inquery: plans for phasing out cpu, rx and import

[sl]

> now that we have rcpu taking over for cpu, import and rx...
> i want to discuss how to phase out the old protocols.

Strongly agree.


> the following things could be done:
> 
> - disable listen scripts for exportfs, cpu and rx services.
>   so 9front machines will not serve these anymore by
>   default. client would still work as normal, code still
>   there and continuing maintaining it.

I think this is the best option. This way, 9front can keep
talking to Plan 9.

sl

Re: [9front] inquery: plans for phasing out cpu, rx and import

[kokamoto]

>> the following things could be done:
>> 
>> - disable listen scripts for exportfs, cpu and rx services.
>>   so 9front machines will not serve these anymore by
>>   default. client would still work as normal, code still
>>   there and continuing maintaining it.
> 
> I think this is the best option. This way, 9front can keep
> talking to Plan 9.

I wonder this.
Any novice user like me would not notice the dangerness
of the situation, if s/he can connect to other Plan 9 system
without any work.

- rename the old programs, say, move them to /bin/old/^(cpu exportfs import ...)
  scripts will break, but program still there under a different
  name in case one needs it. code still there and will be
  maintained.

maybe better.

Kenji  --just my two cents

Re: [9front] inquery: plans for phasing out cpu, rx and import

[sl]

>>> - disable listen scripts for exportfs, cpu and rx services.
>>>   so 9front machines will not serve these anymore by
>>>   default. client would still work as normal, code still
>>>   there and continuing maintaining it.
>> 
>> I think this is the best option. This way, 9front can keep
>> talking to Plan 9.
> 
> I wonder this.
> Any novice user like me would not notice the dangerness
> of the situation, if s/he can connect to other Plan 9 system
> without any work.

Old cpu is the *only* way to connect to Plan 9 from Bell Labs.

9front will have old cpu listeners disabled by default.

sl

Re: [9front] inquery: plans for phasing out cpu, rx and import

[kokamoto]

> Old cpu is the *only* way to connect to Plan 9 from Bell Labs.
> 
> 9front will have old cpu listeners disabled by default.

I think I understand your words.
I just pointed the rational result, if we push rcpu.

Kenji

Re: [9front] inquery: plans for phasing out cpu, rx and import

[stanley lieber]

kokamoto@hera.eonet.ne.jp wrote:

>> Old cpu is the *only* way to connect to Plan 9 from Bell Labs.
>>
>> 9front will have old cpu listeners disabled by default.
>
>I think I understand your words.
>I just pointed the rational result, if we push rcpu.
>
>Kenji

I don't think I understand the danger. 9front users will not be able to devolve to old cpu out of habit when connecting to 9front because on 9front old cpu listeners will be disabled by default. When connecting to Plan 9 from Bell Labs old cpu is the only option, so renaming the old cpu commands will only haven the effect of causing Plan 9 users to have to mentally replace all documented commands with the new names. 9front's new cpu commands already have new names, and existing documentation refers to them by those names.

Renaming the old cpu commands will only cause confusion.

sl

Re: [9front] inquery: plans for phasing out cpu, rx and import

[hiro]

i agree with sl. my reason is that i imagine some older plan9
installations are accessible only from some small local networks at
home or work where security isn't as crucial as for publicly
accessible installations and it's better to allow these folks to
tinker on with their systems undisturbed.
not everyone should be forced to upgrade all their systems to 9front.
perhaps they are interested more in history than security.

Re: [9front] inquery: plans for phasing out cpu, rx and import

[cinap_lenrek]

> Renaming the old cpu commands will only cause confusion.

yes, i agree. also, if we ever do to remove cpu and import
commands, you can still bring them back. will not reuse the
old names.

--
cinap

Re: [9front] inquery: plans for phasing out cpu, rx and import

[cinap_lenrek]

> perhaps they are interested more in history than security.

plan9 is different. you dont have many separate installations,
but usually you share one file server with many computers. so
keeping stuff consistent is easy.

interoperability between systems is a different matter. note
that inferno is also incompatible to plan9. it shares 9p but its
authentication infrastucture is different.

i think backwards compatibility is fine for now, but long term
i'd rather want a clean system that someone can understand fully.
this was the most valuable thing with plan9 for me, i could read
the code and understand it. if i now want to understand how
exportfs works, my eyes bleed when i have to read the main function
of exportfs because of all this import crap in there. it shouldnt
deal with authentication, encryption and aan networking.

with rcpu, concerns are much better separated. exportfs really
just exports a file tree serving 9p on its stdinput and output
file descriptors.

so its not just security, its about complexity. i want people
to love 9front when they realize that it can do what ssh does
and much more but all with a rc script that is smaller than
ther ssh configuration file.

--
cinap

Re: [9front] inquery: plans for phasing out cpu, rx and import

[hiro]

it's a good point. perhaps remove the files and put somewhere in the
fqa the hg command that will revert this again?
then there's a documented way for people to access an old plan9
machine, but no code to confuse people who download 9front and
directly just read the code.

Re: [9front] inquery: plans for phasing out cpu, rx and import

[Kurt H Maier]

On Tue, Aug 09, 2016 at 11:45:18AM +0200, hiro wrote:
> it's a good point. perhaps remove the files and put somewhere in the
> fqa the hg command that will revert this again?
> then there's a documented way for people to access an old plan9
> machine, but no code to confuse people who download 9front and
> directly just read the code.

I'd rather see this in contrib, or maybe a separate hg repo of its own.
I don't know how feasible that is given the kernel bits.

khm

Re: [9front] inquery: plans for phasing out cpu, rx and import

[stanley lieber]

hiro <23hiro@gmail.com> wrote:

>it's a good point. perhaps remove the files and put somewhere in the
>fqa the hg command that will revert this again?
>then there's a documented way for people to access an old plan9
>machine, but no code to confuse people who download 9front and
>directly just read the code.

So we keep things like ftp and nfs clients in the base system but remove the ability to talk to Plan 9?

Disabling the listeners on 9front is obvious, and since Plan 9 is dead, maintenance is not really needed, but why remove it, exactly? Just to feel "clean"?

We still keep a lot of other dirty stuff, specifically so we can talk to other outmoded servers that are not even Plan 9. Maybe Plan 9 systems are so rare it doesn't matter, but this policy seems quite randomly applied.

sl

Re: [9front] inquery: plans for phasing out cpu, rx and import

[stanley lieber]

Kurt H Maier <khm@sciops.net> wrote:

>On Tue, Aug 09, 2016 at 11:45:18AM +0200, hiro wrote:
>> it's a good point. perhaps remove the files and put somewhere in the
>> fqa the hg command that will revert this again?
>> then there's a documented way for people to access an old plan9
>> machine, but no code to confuse people who download 9front and
>> directly just read the code.
>
>I'd rather see this in contrib, or maybe a separate hg repo of its own.
>I don't know how feasible that is given the kernel bits.
>
>khm

If it does get removed, putting a tarball in /n/extra does seem like a good idea.

sl

Re: [9front] inquery: plans for phasing out cpu, rx and import

[Kurt H Maier]

On Tue, Aug 09, 2016 at 11:09:41AM -0400, stanley lieber wrote:
> 
> So we keep things like ftp and nfs clients in the base system but remove the ability to talk to Plan 9?
> 

I didn't see this as removing support for a protocol so much as removing
an older version of the protocol -- like not shipping support for nfsv1
or whatever.  I have reconsidered and I agree, we should keep them.

> Disabling the listeners on 9front is obvious, and since Plan 9 is dead, maintenance is not really needed, but why remove it, exactly? Just to feel "clean"?

Originally I supported removing them because they were completely
superseded by rcpu et al; if what we have is sufficient, it would
simplify code maintenance and documentation, presumably, to remove the
cruft.

> We still keep a lot of other dirty stuff, specifically so we can talk to other outmoded servers that are not even Plan 9. Maybe Plan 9 systems are so rare it doesn't matter, but this policy seems quite randomly applied.

This is what made me reconsider -- as long as sources is up, I don't
like the idea of losing access to labs contrib.  Obviously we could
make it available with our tools...

... on the other hand, when was the last time any of us saw a labs plan
9 installation that wasn't some transient nerd totem, like a raspberry
pi or something?  

Anyone on this list touch labs plan 9 on the regular?

khm

Re: [9front] inquery: plans for phasing out cpu, rx and import

[cinap_lenrek]

> We still keep a lot of other dirty stuff, specifically so we can talk to other outmoded servers that are not even Plan 9. Maybe Plan 9 systems are so rare it doesn't matter, but this policy seems quite randomly applied.

correct, but theres a difference there. cpu and import are our native
plan9 protocols. for foreign protocols you cannot do much, if they
are bad and widely deployed. while cpu and import deployment is assumingly
much smaller as we used it mostly ourselfs. so the responsibility of
cleaning up the mess is on us i think... before anyone gets hurt.

disabling the listener is a good first step, maybe many people will
whine about it. but i doubt it. lets see.

speaking of other outmoded servers, openssh deleted sshv1 protocol
support.

> sl

--
cinap

Re: [9front] inquery: plans for phasing out cpu, rx and import

[cinap_lenrek]

> I'd rather see this in contrib, or maybe a separate hg repo of its own.
> I don't know how feasible that is given the kernel bits.

feasable, the kernel bits are a single .c file, exportfs is a directory
and cpu.c and import.c

--
cinap

Re: [9front] inquery: plans for phasing out cpu, rx and import

[cinap_lenrek]

> Disabling the listeners on 9front is obvious, and since Plan 9 is dead, maintenance is not really needed, but why remove it, exactly? Just to feel "clean"?

i just recently fixed a bug in devssl.c. its not like if labs doesnt change
the protocol anymore, the impementation was bugfree. worse, this bug could
be used to disrupt the whole system, not just break security of the weakly
encrypted connection.

--
cinap

Re: [9front] inquery: plans for phasing out cpu, rx and import

[stanley lieber]

cinap_lenrek@felloff.net wrote:

>> We still keep a lot of other dirty stuff, specifically so we can talk
>to other outmoded servers that are not even Plan 9. Maybe Plan 9
>systems are so rare it doesn't matter, but this policy seems quite
>randomly applied.
>
>correct, but theres a difference there. cpu and import are our native
>plan9 protocols. for foreign protocols you cannot do much, if they
>are bad and widely deployed. while cpu and import deployment is
>assumingly
>much smaller as we used it mostly ourselfs. so the responsibility of
>cleaning up the mess is on us i think... before anyone gets hurt.
>
>disabling the listener is a good first step, maybe many people will
>whine about it. but i doubt it. lets see.
>
>speaking of other outmoded servers, openssh deleted sshv1 protocol
>support.
>
>> sl
>
>--
>cinap

9front users don't need old cpu at all. The only reason I recommend keeping it is so we can continue talking to Plan 9. Those old Plan 9 systems don't have the option of using rcpu and friends instead of old cpu. It just seems weird to chop off those legacy systems completely, since the Plan 9 world does not consist solely of 9front.

I agree that the number of Plan 9 systems is decreasing and it probably doesn't really matter. In the end, anyone who really needs old cpu on 9front will be capable of grabbing it from /n/extra.

Pointing out that ssh1 is deprecated is not really a like comparison, because ssh servers now mostly offer ssh2. Old Plan 9 cannot offer rcpu.

sl

Re: [9front] inquery: plans for phasing out cpu, rx and import

[stanley lieber]

cinap_lenrek@felloff.net wrote:

>> Disabling the listeners on 9front is obvious, and since Plan 9 is
>dead, maintenance is not really needed, but why remove it, exactly?
>Just to feel "clean"?
>
>i just recently fixed a bug in devssl.c. its not like if labs doesnt
>change
>the protocol anymore, the impementation was bugfree. worse, this bug
>could
>be used to disrupt the whole system, not just break security of the
>weakly
>encrypted connection.
>
>--
>cinap

I guess I did not grasp that leaving the old cpu kernel bits in place still represented a security risk even if nobody is running the old listeners. If that is the case then I agree we should remove the stuff (and perhaps make it available in /n/extra).

sl

Re: [9front] inquery: plans for phasing out cpu, rx and import

[hiro]

is the bell labs contrib mirror complete by now?

Re: [9front] inquery: plans for phasing out cpu, rx and import

[Steve Simon]

yep,

still on the labs code base.

btw. is there a documented way to jump ship to 9 front?

-Steve

> On 9 Aug 2016, at 16:33, Kurt H Maier <khm@sciops.net> wrote:
> 
>> On Tue, Aug 09, 2016 at 11:09:41AM -0400, stanley lieber wrote:
>> 
>> So we keep things like ftp and nfs clients in the base system but remove the ability to talk to Plan 9?
>> 
> 
> I didn't see this as removing support for a protocol so much as removing
> an older version of the protocol -- like not shipping support for nfsv1
> or whatever.  I have reconsidered and I agree, we should keep them.
> 
>> Disabling the listeners on 9front is obvious, and since Plan 9 is dead, maintenance is not really needed, but why remove it, exactly? Just to feel "clean"?
> 
> Originally I supported removing them because they were completely
> superseded by rcpu et al; if what we have is sufficient, it would
> simplify code maintenance and documentation, presumably, to remove the
> cruft.
> 
>> We still keep a lot of other dirty stuff, specifically so we can talk to other outmoded servers that are not even Plan 9. Maybe Plan 9 systems are so rare it doesn't matter, but this policy seems quite randomly applied.
> 
> This is what made me reconsider -- as long as sources is up, I don't
> like the idea of losing access to labs contrib.  Obviously we could
> make it available with our tools...
> 
> ... on the other hand, when was the last time any of us saw a labs plan
> 9 installation that wasn't some transient nerd totem, like a raspberry
> pi or something?  
> 
> Anyone on this list touch labs plan 9 on the regular?
> 
> khm