I am working on a port of Openssh 3.8p1 after already
having done a port of Openssh 3.5p1. There are a
couple of new lines in buffer_get_bignum2() that are
causing me problems:
if (len > 0 && (bin[0] & 0x80))
fatal("buffer_get_bignum2: negative
numbers not supported");
The "& 0x80" check is not relevant in ebcdic.
Does anyone know why this check was added?
What are the consequences of removing it?
Does anyone have any idea how I could get the same
result as this check in ebcdic?
Thank You,
Greg Lambert
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
Greg Lambert wrote:> I am working on a port of Openssh 3.8p1 after already > having done a port of Openssh 3.5p1. There are a > couple of new lines in buffer_get_bignum2() that are > causing me problems: > > if (len > 0 && (bin[0] & 0x80)) > fatal("buffer_get_bignum2: negative > numbers not supported"); > > The "& 0x80" check is not relevant in ebcdic.Why not? The contents of a bignum are binary, not text.> Does anyone know why this check was added? > What are the consequences of removing it?These should be obvious from the error message. -d
On Thu, Jul 22, 2004 at 01:36:06PM -0700, Greg Lambert wrote:> I am working on a port of Openssh 3.8p1 after already > having done a port of Openssh 3.5p1. There are a > couple of new lines in buffer_get_bignum2() that are > causing me problems: > > if (len > 0 && (bin[0] & 0x80)) > fatal("buffer_get_bignum2: negative > numbers not supported"); > > The "& 0x80" check is not relevant in ebcdic. > > Does anyone know why this check was added?because negative numbers are not supported by our buffer_get_bignum2. see below> What are the consequences of removing it? > > Does anyone have any idea how I could get the same > result as this check in ebcdic?bin[] is not a character, it's just a byte. here's a quote from the secsh-architecture draft: mpint Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the most significant bit of the first byte of the data partition. If the most significant bit would be set for a positive number, the number MUST be preceded by a zero byte. Unnecessary leading bytes with the value 0 or 255 MUST NOT be included. The value zero MUST be stored as a string with zero bytes of data. By convention, a number that is used in modular computations in Z_n SHOULD be represented in the range 0 <= x < n. Examples: value (hex) representation (hex) --------------------------------------------------------------- 0 00 00 00 00 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 80 00 00 00 02 00 80 -1234 00 00 00 02 ed cc -deadbeef 00 00 00 05 ff 21 52 41 11
Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An embedded message was scrubbed... From: Greg Lambert <glemtp at yahoo.com> Subject: Re: ebcdic problem in bufaux.c Date: Fri, 23 Jul 2004 07:58:27 -0700 (PDT) Size: 2242 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040723/775cc09b/attachment.mht