Skip to content
Snippets Groups Projects
Select Git revision
  • dd_msg_reader_list_personal_email_in_reverse_choose_msg_fix
  • 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
  • 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

Blame
    • 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).