Skip to content
Snippets Groups Projects
Select Git revision
  • dailybuild_linux-x64
  • dailybuild_win32
  • master default protected
  • sqlite
  • rip_abstraction
  • dailybuild_macos-armv8
  • dd_file_lister_filanem_in_desc_color
  • mode7
  • dd_msg_reader_are_you_there_warning_improvement
  • c23-playing
  • syncterm-1.3
  • syncterm-1.2
  • test-build
  • hide_remote_connection_with_telgate
  • 638-can-t-control-c-during-a-file-search
  • add_body_to_pager_email
  • mingw32-build
  • cryptlib-3.4.7
  • ree/mastermind
  • new_user_dat
  • sbbs320d
  • syncterm-1.6
  • syncterm-1.5
  • syncterm-1.4
  • sbbs320b
  • syncterm-1.3
  • syncterm-1.2
  • syncterm-1.2rc6
  • syncterm-1.2rc5
  • push
  • syncterm-1.2rc4
  • syncterm-1.2rc2
  • syncterm-1.2rc1
  • sbbs319b
  • sbbs318b
  • goodbuild_linux-x64_Sep-01-2020
  • goodbuild_win32_Sep-01-2020
  • goodbuild_linux-x64_Aug-31-2020
  • goodbuild_win32_Aug-31-2020
  • goodbuild_win32_Aug-30-2020
40 results

pack_qwk.cpp

  • Rob Swindell's avatar
    4e1ca83a
    Fix possible crash when no extractable file types are configured in SCFG · 4e1ca83a
    Rob Swindell authored
    If libarchive couldn't extract a QWK or REP packet, we'd fallback to searching
    for a match among the configured extractable file types and if no extension/type
    match was found, default to the first configured extractable file type
    (even if there wasn't one) which would result in a NULL pointer dereference
    and most likely a crash. Instead, if no matching configured extractable
    file type is found, just log a warning message and don't continue with the
    extraction attempt. With SBBS v3.19+, it's totally valid/legit to have no
    extractable file types configured in SCFG and things "just work" (using
    libarchive).
    4e1ca83a
    History
    Fix possible crash when no extractable file types are configured in SCFG
    Rob Swindell authored
    If libarchive couldn't extract a QWK or REP packet, we'd fallback to searching
    for a match among the configured extractable file types and if no extension/type
    match was found, default to the first configured extractable file type
    (even if there wasn't one) which would result in a NULL pointer dereference
    and most likely a crash. Instead, if no matching configured extractable
    file type is found, just log a warning message and don't continue with the
    extraction attempt. With SBBS v3.19+, it's totally valid/legit to have no
    extractable file types configured in SCFG and things "just work" (using
    libarchive).