My hobbyist coding updates and releases as the mysterious "Mr. Tines"

Wednesday 21 December 2005

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!

Saturday 10 December 2005

Enkoder applet

“E”-ddress encoder 1.0 — a utility based on the the old Hiveware “Enkoder”, only this one is a Java app/applet. Offered into the public domain.

Saturday 29 October 2005

PassiveFTP 1.8

PassiveFTP 1.8 — build 1.8.2127.30224 — minor bug-fix release — only treats client-side executables as possibly having unique icons, so does not get icon creation failures when scanning client-side folders with vary many files. Also set default upload to dial-up compatible 2kb/s for best observed stability.

From the windows page

Sunday 26 June 2005

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.

Monday 9 May 2005

PassiveFTP 1.7

PassiveFTP version 1.7.1955.38236 — allows the upload rate to be limited for fussy servers.

From the Windows page, as usual.

Sunday 8 May 2005

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.

Saturday 15 January 2005

Angerona/CTClib/CTCJava suspended

Well it's probably time to formally declare that there isn't going to be any more work on CTClib, CTCJava or Angerona, except for bug-fixes that affect my own use of the system. It's too much ancient history now.