CTCjlib -- IMPORTANT UPDATE!

The previous CTCjlib update (2.3.2178.34472) was built off an experimental (and broken) code-base, the result of my having set the project aside some years (and computers) ago, and taking from the wrong repository.

I have now reverted the code-base to the last released archive from this site, and built CTCJlib.dll v 2.3.2181.36359 from that. As noted before, this incorporates the fix noted in the 26-Jun-05 entry below, plus the altered source files, and with detached signatures in the archive too.

Please accept my apologies, and — Enjoy!

CTClib inflate issue

The CTClib deflate implementation follows PGP 2.x in limiting the compression window to 8k; it also limits the decompression window similarly. Other implementations e.g. Bouncy Castle, do not heed this limitation. Andrew Paterson writes:

Since my last e-mail, I did a quick experiment and I have established that, as you suggested, the 8K window size was the culprit. As it was easier to modify CTC, I changed the definition of WSIZE back to 32K (0x8000) in gzip.h then defined WSIZE as 8K (0x2000) in deflate.c before gzip.h was included. That did the trick! Encryption/signing (deflating) uses an 8K window size whilst decryption (inflating) uses a 32K window size. Problem solved and, as a bonus, the compatibility of CTC is actually increased.

Unfortunately, it does mean that I will have to rebuild/redeploy all of my software that uses CTC but I think I prefer that to using an uneasy hybrid of Sun JDK, hacked Bouncy Castle JCE and hacked GNU Classpath zip classes. There are also licence implications in that the Bouncy Castle crypto libraries are not under the GPL whereas the GNU Classpath classes obviously are.

Look for an update build sometime.

PassiveFTP problem

I have observed a flaw in the implementation of PassiveFTP. I intended to make the data channel socket non-blocking, but instead re-asserted that for the command channel. Also the host I usually FTP to has started to choke on uploads done at full ADSL rate, so I need to get the non-blocking behaviour fixed, so I can throttle the upload rate appropriately.

Look for an update in the next week or so.

PassiveFTP 1.6

PassiveFTP 1.6 — PassiveFTP version 1.6.1701.15662 — when XP SP2 dropped my screen depth from 32-bit to 16-bit off its own bat, all hell broke loose. Fix for the default 16-bit style, maybe all 16-bit and even 24-bit. No 8-bit or less planned.

Glitches -- PassiveFTP and Janus/.Net

With Passive FTP 1.4 I've encountered a number of occasions in live use — but not, alas when running in set-up tests, where it seems that operations on a large server-side directory and shuffling that around by adding or deleting files can cause some sort of fault in the icon rendering.

In Janus.Net 1.1, I have observed that null credentials (empty username and password) will suffice to perform NTLM authentication. A little digging suggests that this is a "feature" of the protocol. Note that IE prevents you giving an empty username+password in the login dialog box by keeping the OK button disabled under those circumstances.

CTClib 2.3 bug report

One sort-of bug report against CTClib 2.3; if you generate excessively short RSA keys, shorter than the size of the signature packet for self signature, the signature process fails. This is not checked, and so the attempt to verify the signature ends up chasing a nil pointer. As you should not use a keylength below 512 bits, and to be safer, no shorter than 1024 bits, this should not actually be provoked in reasonable use.