AdiIRC Support/Bugs/Feature Requests: Issueshttps://dev.adiirc.com/https://dev.adiirc.com/favicon.ico?14868454782018-11-02T01:27:06ZAdiIRC Support/Bugs/Feature Requests
Redmine AdiIRC - Bug #4184 (Closed): Issues/observations related to DCChttps://dev.adiirc.com/issues/41842018-11-02T01:27:06ZPaul Janson
<p>making sure there's no download file and create dummy file:<br /> //remove downloads\test2.txt | btrunc test2.txt 0 | bwrite test2.txt 4095 1 t | echo -a size $file(test2.txt).size</p>
<p>Create an event to monitor what's happening with the DCC:</p>
<pre><code>CTCP <strong>:*:</strong>:echo <del>s ctcp from $nick : $1</del></code></pre>
<p>Bug1: The menu says "ON CTCP" even though there's no 'ON'. Ditto with "ON RAW".</p>
<p>Send to self:<br /> //dcc send $me test2.txt</p>
<p>DCC Send of test2.txt to self complete (00:00:00 24.69KB/Sec)<br />DCC Get of test2.txt from self complete (00:00:00 249.99KB/Sec)</p>
<p>Bug2: DCC send/resume should trigger the CTCP event, but did not.<br />Bug3: I'm having trouble replicating the cause, but I ended up with a test1.txt which didn't allow writing to it nor could Windows Explorer delete it. Once this happened, of course /bwrite fails to write to it, and /btrunc can't change the filesize either. However there is no error message, and there's nothing that halts the next next command from executing. There is an error when /write /remove or /rename try to mess with it.</p>
<p>change dummy size smaller:<br /> //bwrite -c test2.txt 2047 1 33 | echo -a size $file(test2.txt).size</p>
<p>fix: add -c switch to the TODO list, filesize still 4096</p>
<p>Other related issues with handling of DCC protocol.</p>
<p>1. If incoming file is same filesize as the file you already have, should it really do a DCC RESUME so it can ask for the last 8kb of the file? Best case scenario is that you receive data identical to the last 8192 bytes of the existing image.jpg of the same filesize, and the file is not changed other than updating the timestamp. The alternative is that the incoming file is coincidentally the same filename/filesize as a file you already have but a different image, so a valid image gets the final 8kb replaced with the content of a different image.</p>
<p>To avoid having the sender think you were rejecting the file, or had problems accepting files, instead of resuming an identical filesize, it could 'lie' to the sender and say it received the DCC ok but really does nothing. Like it does when the incoming file is larger than the existing file.</p>
<p>2. If the file in the download folder has filesize 0-8192, it requests a dcc-resume at offset zero. Would it be reasonable for the client to just do a normal ACCEPT, then if the transfer begins successfully, just replace the content beginning at the start of the file. It's even doing a dcc-resume at offset zero if the existing file is size zero. My prior ISP caused a problem where sometimes the port changed somewhere outside the client, which meant normal DCC worked fine, but which caused all dcc-resume to fail because the port was unknown. In the case of size 8192 or smaller, this seems wasted handshaking when the successful DCC does the same thing as if the DCC overwrites the existing filename entirely.</p>
<p>I know DCC's not supposed to truncate the file unless the transfer actually begins, otherwise someone could delete your small file or else snip 8kb from the tail end just by starting a DCC then failing.</p>
<p>3. I'm assuming the reason for resuming the last 8192 of a file was in case the last packet of the transfer was corrupted, to either to make sure to repeat the last full packet when packet size was 4096, or because 8192 used to be the max valid packetsize. However now that packet sizes of up to 64k are allowed, should this 8192 also be configurable too? Either allowing it to be zero to not repeat anything, or to have it be 100% or 200% of whatever your configured dcc-get packetsize is? i.e. if I change my packet size to 65536, resuming at 8192 below the existing filesize doesn't make sense, since that's retrieving only 1/8th of a packet. Related to <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Sysinfo does not update (Closed)" href="https://dev.adiirc.com/issues/1">#1</a> above, I'm not sure if packets being corrupted would happen when a transfer reports to both sides that it was successful at 100% of filesize.</p> AdiIRC - Bug #4169 (Closed): $calc and other $math identifiershttps://dev.adiirc.com/issues/41692018-10-29T01:54:52ZPaul Janson
<p>Crashes from too big number: //echo -a $calc(2^96 -1)<br />Happens also in /var command: //var %a 2 ^ 96</p>
<p>Handles non-numeric terms differently.</p>
<p>//echo -a add $calc(1 + x) vs $calc( x + 1) / sub $calc(1 - x) vs $calc( x - 1)</p>
<p>Returns<br />add 1 vs 1 / sub 1 vs -1<br />instead of<br />add 1 vs 0 / sub 1 vs 0</p>
<p>The accuracy for integers does not extend through 2^53, probably due to offering 28 digits in fractions. Above 2^53 returns different 'wrong' answers. If the valid range is going to be different, would help to have the new range documented.</p>
<p>//echo -a $calc(2^49 -1 ) correct<br />//echo -a $calc(2^50 -1 ) wrong</p>
<p>$calc handles alphanumerics differently if number embedded among the letters</p>
<p>//echo -a $calc(123deadbeef) is 123<br />//echo -a $calc(123deadbeef1) is 0</p>
<p>($calc is often used as a shortcut to strip non-numbers from the end of a string, because $int() and similar don't do the same for if they think it's scientific notation.)</p>
<p>//echo -a $abs(123X) should be 123<br />//echo -a $int(123e4) $abs(123e4) $ceil(123e4) $floor(123e4) should all be 1230000<br />but $calc should not handle scientific notation differently than other non-numerics as the above identifiers should.</p>
<p>$xor $or $and $not negatives/decimals:</p>
<p>//echo -a $not(1) s/b 4294967294<br />//echo -a $not($calc(2^31-1)) s/b 2147483648<br />//echo -a $not(4.1) s/b 4294967291</p>
<p>//echo -a $xor(8,1.1) fraction should be ignored, instead causes term treated as if zero<br />//echo -a $and(7,7.1) ditto<br />//echo -a $or(8,1.1) ditto</p>
<p>//echo -a $or(8,-8) s/b 4294967288<br />//echo -a $xor(8,-1) s/b 4294967287<br />//echo -a $and(-8,-9) s/b 4294967280</p>
<p>//echo -a $ord(111) $ord(112)</p>
<p>In spite of extra decimal places, this fails all 100 instead of failing most:</p>
<p>//var %i 1 , %list | while (%i isnum 1-100) { var %list %list $round(%i $+ .05 ,1) | inc %i } | echo -a round: %list</p> AdiIRC - Bug #4168 (Closed): $encrypt/$decrypt if password parameter is $null, contains codepoint...https://dev.adiirc.com/issues/41682018-10-28T20:17:07ZPaul Janson
<p>FYI. The $encrypt/$decrypt pages both say EBC, when they really mean 'ECB' for Electronic Code Book.</p>
<p>The output appears to be the 8_bytes-to-12_text encoding used in FISH, and doesn't offer a binary input/output switch, so until I can make an alias to translate that output to binary, it's hard to verify the test vectors. But I did find edge cases where the password is not handled correctly.</p>
<p>1. $null password crashes:</p>
<p>//echo -a $encrypt(test,$null)<br />//echo -a $decrypt(test,$null)</p>
<p>2. Codepoints above 127 are used as if $chr(63) "?" is used.</p>
<p>//echo -a <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Sysinfo does not update (Closed)" href="https://dev.adiirc.com/issues/1">#1</a> $encrypt(test,pass $+ $chr(10004))<br />//echo -a #2 $encrypt(test,pass $+ $chr(233))<br />//echo -a <a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: Multiline messagebox is buggy (Closed)" href="https://dev.adiirc.com/issues/3">#3</a> $encrypt(test,pass $+ $chr(224))<br />//echo -a <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Scroll mouse in all datagrid views (Closed)" href="https://dev.adiirc.com/issues/4">#4</a> $encrypt(test,pass $+ $chr(63))<br />//echo -a $decrypt(C9.i6Y5LrozZ,pass $+ $chr(63))</p>
<p>I believe that, when the password is a text string, the correct bytes to use are from UTF-8 encoding the input, or to reject input that isn't 7-bit. If the input is ever binary, such as using a sha1/sha256/sha512 digest, the input should retain the 0x00's and 0x80-0xff's without UTF8 encoding them.</p>
<p>3. Password is expanded to fill the 72-byte internal key incorrectly.</p>
<p>//echo -a $encrypt(test,$str(abcde,1)) input length 5x1=5<br />//echo -a $encrypt(test,$str(abcde,11)) input length 5x11=55<br />//echo -a $encrypt(test,$str(abcde,12)) input length 5x12=60</p>
<p>These 3 produce identical outputs. The first two should do that, the 3rd should not. From how it handles the 4 combinations of 71 or 72 a's followed by either 'b' or 'c', it appears $encrypt() is using $left(input,72) then replicating that until length 72 if it's shorter.</p>
<p>The correct method is to use only the first 56 bytes of the input, even if that chops in the middle of a multi-byte UTF8 symbol, then replicate that 1-56 byte string until it has length of 72. Blowfish design requires that at least 16 of the 72 bytes be repeated. It's your call whether to use $left($utfencode(input),56) or to generate an error if the input contains more than 56 bytes (not 56 characters).</p>