> It supports strong encryption but is exportable from > the US because it does not have encryption compiled in by default. Instead > it downloads the scripts it needs from South Africa when it runs for the > first time.
This is *extremely* risky behavior. FTP and HTTP sites *are* compromised. Software packages *are* compromised. Look no further than "TCP Wrappers"... A major part of the security process is having a human involved who knows what software was downloaded. A human may later see a pertinent news report and act on it; scripts will not. A *mandatory* part of a site's security process is having a human who has the final authority to approve the use of a package. A human who can be held accountable, and thus is motivated to pay attention to what's going on. A script blows off this part of the process. > South Africa has no export restrictions on cryptography. It > supports file transfer and secure logins shells. It can offer secure file transfers and multiple cryptographic checksums, and the end result is just as unacceptable. *We must start with the assumption that the server might be compromised.* If the server is compromised, secure login shells and FTP won't help. If the server is compromised, checksums (even MD5 checksums) won't help. The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a "chain of trust" to evaluate whether to trust the key used to sign the checksum. What's the answer? Download *PGP* to verify the checksums on that PGP file,... ? As an aside, why would a mirror program even want strong encryption? Encryption != authentication, although the implementatons have significant overlap. Bear Giles [EMAIL PROTECTED]
