• src/sbbs3/ftpsrvr.c

    From Rob Swindell@VERT to Git commit to main/sbbs/m on Mon Jan 30 16:00:00 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/5fdf8f0fddbcc5016c033af8
    Modified Files:
    src/sbbs3/ftpsrvr.c
    Log Message:
    Don't MQTT-publish the download of temp files

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/m on Thu Feb 2 17:51:00 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/8e94a448a7346a36d4a85dbe
    Modified Files:
    src/sbbs3/ftpsrvr.c
    Log Message:
    Fix uploader-notification, credit awards, download-counters in FTP downloads

    Since v3.19 (the new filebases), when a user FTP-downloaded a file, we failed to properly find/load that file's record from the filebase (searching for the file's full path, rather than just the filename), so the code the increments the file's download counter, notifies the uploader, awards credits, etc. did not ever execute. This means that FTP-downloads for all files downloaded via FTP were effectively "free" (and nobody noticed). No error was logged either.

    I discovered this while debugging the case of "(null)" filenames in the action/download MQTT topic messages being published by the FTP server. So
    that issue is fixed as part of this commit as well.

    Oh, and if this code had executed before, it would have memory-leaked the
    file information, so that's fixed too (added call to smb_freefilemem). Ugh.

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Thu Feb 9 12:43:11 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/3709ae9d438cc0932f70c46f
    Modified Files:
    src/sbbs3/ftpsrvr.c
    Log Message:
    Free/zero out the file_t struct *after* sending the MQTT action msg

    ... not before. This explains why FTP-uploaded actions had a (null) filename.

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Sat Mar 18 19:40:18 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/448e18156d14b0b8a2bb535a
    Modified Files:
    src/sbbs3/ftpsrvr.c
    Log Message:
    Add free disk space check against minimum space configured

    Disallow uploads when free disk space falls below minimum configured
    minimum free disk space.

    This fixes issue #535

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Sat Mar 18 19:40:18 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/36fea1c5acf774be516d1df6
    Modified Files:
    src/sbbs3/ftpsrvr.c
    Log Message:
    Limit uploaded file sizes, accounting for free disk space

    The lower of the configured maximum file size (for the FTP server) and
    the available disk space minus the configured minimum free disk space
    is used as the maximum file size to allow upload. Appended files
    are accounted for too.

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (in GitKraken)@VERT to Git commit to main/sbbs/master on Fri Mar 24 12:01:53 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/2e93426824b48954395c0b1f
    Modified Files:
    src/sbbs3/ftpsrvr.c
    Log Message:
    Fix some signed/unsigned comparison warnings from MSVC

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Thu Apr 13 18:45:54 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/3e2c3176de6108c697d25a69
    Modified Files:
    src/sbbs3/ftpsrvr.c
    Log Message:
    Fix false "SUSPECTED BOUNCE ATTACK ATTEMPT" for IPv6 FTP-data connections

    This bug only impacted non-passive FTP connections. Using an FTP client
    with active (not passive) data connections over an IPv6 connection would false-trigger the "bounce attack" detection and the FTP server responded with "504 Bad port number" and logged a hack attempt in data/hack.log.

    The issue was that we were comparing the socket address structure (which contains other fields besides the address itself) between the control and proposed-data connections. While this logic worked okay for IPv4,
    it did not for IPv6 (the 2 structs contained some non-address differences). Rather than modify the socket address structures to match where needed, I'm just comparing the string representation of the addresses, since that's
    what we really care about anyway.

    Thank to "mark i" of Truck Stop BBS for alerting me to this issue

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net