9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Romano <unobe@cpan.org>
To: 9front@9front.org,cinap_lenrek@felloff.net
Subject: Re: [9front] [patch] /sys/src/cmd/ssh.c notify user of unavailable cipher
Date: Tue, 21 Apr 2020 22:42:35 +0000	[thread overview]
Message-ID: <A19166F8-06DD-4851-B15A-D75146006532@cpan.org> (raw)
In-Reply-To: <F414DF13A5B4C15F6EA1E29F284E99C1@felloff.net>



On April 21, 2020 6:46:13 PM UTC, cinap_lenrek@felloff.net wrote:
>> +		if(unpack(p, recv.w-p, "s.", &s, &n, &p) < 0)
>> +			break;
>> +		if(debug)
>>  			fprint(2, "%s: %.*s\n", *t, utfnlen(s, n), s);
>> +		if(!strcmp(*t,"clicipher") && !strstr(s,cipheralgs)) {
>> +			fprint(2, "%s not found in %.*s\n", cipheralgs, utfnlen(s, n),
>s);
>> +			sysfatal("server does not support cipher");
>>  		}
>
>hm... this is wrong as "s" is not NUL terminated here.

Cinap,

Thanks for the feedback! I am new to this and I appreciate the pointers.

By wrong, you mean that utfnlen() shouldn't be used with 's'? That usage already existed in the chunk I modified, so would that mean the implementation @ tip is also wrong in that way? Or  is there something else I'm missing?

> also not correct as you'd need to check if the overlap is properly
>delimited.

Even if there's only one supported cipher by the client at this point?

>also, this is not good enougth as to predict if the handshake
>would fail you'd need to also check kex and zip algorithms.

Agreed: I was scratching the itch I had, admittedly, abd thought less was more. I pondered doing more but as this is my first foray into this system and code base, I was trying to limit the effects of my changes. The generalized case would be nice to implement, but I fear there'd be so much of my crappy code for veterans like you to comment on, it would stall improvement. Do you think that adding the patch actually makes anything operate worse than it currently does on tip? Do you think it's a step backwards?

>overall, i'd prefer to implement the handshake proper and maybe
>add support for some common older ciphersuits instead adding
>code that does alot of clever things working around these
>limitations.

Yes, I'd prefer that too. I can review the RFC to see how far off-base the current implemenation is. Also, I am not a crypto expert and my beginning perusal of the 9front code didn't yield info for me on where to begin with adding new ciphers. So I guess this would be a good time to ask: do you (or does anyone else) have some pointers on where I would begin with adding other ciphers?


  reply	other threads:[~2020-04-21 22:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21  4:46 Romano
2020-04-21  5:16 ` [9front] " Stanley Lieber
2020-04-21 18:46 ` cinap_lenrek
2020-04-21 22:42   ` Romano [this message]
2020-04-21 23:00     ` cinap_lenrek
2020-04-21 23:05       ` Romano
2020-04-21 23:25     ` cinap_lenrek
2020-04-22  1:04       ` ori
2020-04-22  5:40       ` Romano
2020-04-27 23:11         ` Romano
2020-04-27 23:17           ` ori
2020-04-28  6:18             ` hiro

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=A19166F8-06DD-4851-B15A-D75146006532@cpan.org \
    --to=unobe@cpan.org \
    --cc=9front@9front.org \
    --cc=cinap_lenrek@felloff.net \
    /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).