Missing user blowfish key gives unintuitive PM failure from sitebot

[erich]

Alzax reported this bug, and I have confirmed it with rev 1997.

Apparently nothing happens, and drftpd.log doesn't say anything beside that I can see that it receives the command.

[djb61]

This isn't actually anything to do with the command, this is happening because blowfish is enabled and when this is on the bot expects everything to be encrypted, that includes PMs. In this case the user does not have a blowfish key set (PMs use per user keys not the main chan keys) so it can't encrypt a response and silently disregards it.

If the IRC nick can be associated with a known ftp user then we should probably send a plaintext error message in this case (for unknown users it should remain silent however).

A user blowfish key can be set using "site setkey" or "site setblowfish" commands over ftp, or by using a DH1080 key exchange on IRC. The DH1080 option is disabled in the default config so that also has to be enabled, this is by default off (and separate from the main blowfish option) as it requires the export crypto addon to be installed in the Java VM due to the keylength required.

[erich]

Confirmed the behavoir and closing ticket. Extra info: Download Java Cryptography Extension (JCE) Unlimited Strength and place the 2 jar's from the zip file into JAVA_HOME/jre/lib/security The files should already exist. Just overwrite and restart the master. Then DH1080 will work if enabled in irc.conf. Download URL: http://java.sun.com/javase/downloads/index.jsp

'site setkey <key>' also works, but DH1080 is far better.

Also see: http://www.drftpd.org/forums/viewtopic.php?f=19&t=2695

[djb61]

Reopening this due to the work mentioned on notifying users of missing keys rather than simply not responding.

[cheet4h]

replace your SiteBot.java located in src/plugins/org.drftpd.plugins.sitebot/src/org/drftpd/plugins/sitebot with the attated one.

now the SiteBot will notice known ftp users if they contact the bot without a blowfish key

[djb61]

Please don't mark tickets as closed until the fix actually makes it into SVN.

Additionally a patch against the current SVN revision is much easier to review/work with than a full copy of the affected file(s), it isn't quick/easy for me to see what you've changed without a patch.

[djb61]

Committed with changes in [2024] , thanks. See the commit log for the amendments made and reasons for them.