From pssh at richardfearn.co.uk  Mon May  1 16:27:45 2006
From: pssh at richardfearn.co.uk (Rich Fearn)
Date: Mon May  1 16:27:27 2006
Subject: [pssh-users] Private key parsing bug fixes
Message-ID: <000801c66d5d$b4f3a3d0$0102020a@home.rdf>

Hello,

I've fixed a few more problems in pssh, all related to private key parsing.

More consistent handling of comments. In the ImportKeyFromMemo function (in 
forms/memoform.c), the chunk holding a memo's contents (pointed to by memoP) 
includes a NUL character; memoEnd actually points to the character following 
this NUL. If the start of the memo looks like a comment, lineEnd is also set 
to the character after the NUL. If no newline is subsequently found, lineEnd 
is not changed (i.e. still points to memory outside of the memo) - and this 
pointer is used when processing the (zero-length) key data! I've changed 
this so that lineEnd is first initialised to point to the NUL. This makes 
everything more consistent; regardless of whether a comment is present or 
not, and regardless of how many lines the memo has, lineEnd will always 
point to the key data, after the comment (if there is one). The key data may 
then consist of just a NUL byte. (In the subsequent calls to 
openssh_encrypted and openssh_read, the bufferlen parameter is now also 
correct because of this change.)

More informative error messages. I've changed openssh_read and 
load_openssh_key (both in ssh/keyimport.c) so that an "error buffer" can be 
passed in. If a buffer is supplied, and an error is generated, the error 
message is copied into the buffer. This allows ImportKeyFromMemo to display 
a better message than just "Incorrect passphrase, or incorrectly formatted 
memo". I've also changed the second use of "Unexpected end of file" to 
"Missing key footer", to better handle the case of a missing "-----END..." 
line.

More robust handling of key data. If the key data consists of just 
"-----BEGIN RSA PRIVATE KEY-----" followed by a newline, my T|X resets every 
time due to a bug in the load_openssh_key function. I've fixed this and the 
key parsing seems pretty robust now (I've tried various forms of incomplete 
key).

No funny symbols in the memo list. When DrawMemo (in data/memolist.c) draws 
the text for each memo, a square is shown at the end of a memo's title if 
the memo consists of just one line. This is because the NUL is included in 
the title (this is a similar problem to the inconsistency in 
ImportKeyFromMemo). By changing the byte that is initially assumed to be the 
end of the first line of the memo, the NUL is not included, and the square 
is not displayed.

The attached patch will make all the required changes to the 2005-06-23 
version of the source code. It is possible to apply both this patch, and my 
patch from January, which fixed a problem with the memo list that's 
displayed when importing keys. That patch can be found attached to the 
following post:

http://six.pairlist.net/pipermail/pssh-users/2006-January/000089.html

It dawned on me a few months ago that despite all the references in pssh to 
importing "public" keys, it's actually *private* keys that you import! 
Perhaps I'll post another patch to deal with that sometime...

Richard Fearn 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: privkeys.patch
Type: application/octet-stream
Size: 7407 bytes
Desc: not available
Url : http://six.pairlist.net/pipermail/pssh-users/attachments/20060501/20e4034c/privkeys.obj