Skip to content
Snippets Groups Projects
  1. Oct 30, 2014
  2. Oct 29, 2014
  3. Oct 28, 2014
  4. Oct 27, 2014
  5. Oct 24, 2014
  6. Oct 22, 2014
    • Shaun Ruffell's avatar
      codec_dahdi: Cannot use struct ast_translator.core_{src,src}_codec. · c4d7e7e2
      Shaun Ruffell authored
      This fixes a Segmentation fault introduced in r419044 "media formats: re-architect
      handling of media for performance improvements".
      
      The problem is that codec_dahdi was using core_src_codec and core_dst_codec in the
      ast_translator structure when these fields were never set. Now instead of trying to map
      the new core codec descriptions to the way DAHDI defines different codecs, we will store
      the DAHDI specific formats in 'struct translator' directly so we can refer to them without
      mapping.
      
      This also allows us to remove the "global_format_map" structure, since we can now query
      the list of translators directly to make sure we do not ever register a DAHDI based
      translator for a specific path more than once and eliminate the need to keep the list and
      the map in sync.
      
      ASTERISK-24435 #close
      Reported by: Marian Koniuszko
      
      Review: https://reviewboard.asterisk.org/r/4105/
      ........
      
      Merged revisions 426097 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426099 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c4d7e7e2
  7. Oct 21, 2014
  8. Oct 20, 2014
    • Matthew Jordan's avatar
      AST-2014-011: Fix POODLE security issues · dad0334c
      Matthew Jordan authored
      There are two aspects to the vulnerability:
      (1) res_jabber/res_xmpp use SSLv3 only. This patch updates the module to use
          TLSv1+. At this time, it does not refactor res_jabber/res_xmpp to use the
          TCP/TLS core, which should be done as an improvement at a latter date.
      (2) The TCP/TLS core, when tlsclientmethod/sslclientmethod is left unspecified,
          will default to the OpenSSL SSLv23_method. This method allows for all
          ecnryption methods, including SSLv2/SSLv3. A MITM can exploit this by
          forcing a fallback to SSLv3, which leaves the server vulnerable to POODLE.
          This patch adds WARNINGS if a user uses SSLv2/SSLv3 in their configuration,
          and explicitly disables SSLv2/SSLv3 if using SSLv23_method.
      
      For TLS clients, Asterisk will default to TLSv1+ and WARN if SSLv2 or SSLv3 is
      explicitly chosen. For TLS servers, Asterisk will no longer support SSLv2 or
      SSLv3.
      
      Much thanks to abelbeck for reporting the vulnerability and providing a patch
      for the res_jabber/res_xmpp modules.
      
      Review: https://reviewboard.asterisk.org/r/4096/
      
      ASTERISK-24425 #close
      Reported by: abelbeck
      Tested by: abelbeck, opsmonitor, gtjoseph
      patches:
        asterisk-1.8-jabber-tls.patch uploaded by abelbeck (License 5903)
        asterisk-11-jabber-xmpp-tls.patch uploaded by abelbeck (License 5903)
        AST-2014-011-1.8.diff uploaded by mjordan (License 6283)
        AST-2014-011-11.diff uploaded by mjordan (License 6283)
      ........
      
      Merged revisions 425987 from http://svn.asterisk.org/svn/asterisk/branches/12
      ........
      
      Merged revisions 425991 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      dad0334c
  9. Oct 19, 2014
    • George Joseph's avatar
      build: Force -fsigned-char on platforms where the default for char is unsigned · 5e10e369
      George Joseph authored
      gcc on the ARM platform defaults 'char' to 'unsigned char' whereas Intel and
      SPARC default to 'signed char'.  This is only an issue in the rare cases where
      negative values are assigned to a 'char' but this this patch insures
      compatibility by detecting platforms that default to 'unsigned' and adding an
      '-fsigned-char' flag to _ASTCFLAGS.
      
      If compiling for ARM (native or cross-compile) be sure to run ./bootstrap.sh
      and ./configure to regenerate the build files.  You shouldn't have to do this
      for Intel or SPARC.
      
      Tested-by: George Joseph
      
      Review: https://reviewboard.asterisk.org/r/4091/
      ........
      
      Merged revisions 425964 from http://svn.asterisk.org/svn/asterisk/branches/12
      ........
      
      Merged revisions 425965 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425966 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      5e10e369
    • Matthew Jordan's avatar
      res/res_pjsip_sdp_rtp: Revert 425924 · 404b6ab3
      Matthew Jordan authored
      This patch for r425924 introduced a bug, wherein sending an INVITE request
      with no SDP would cause Asterisk to not send an SDP Offer in the 200
      OK. The current structure of res_pjsip_sdp_rtp is a bit hard to deal with
      to fix this, as create_outgoing_sdp has no knowledge of whether or not it is
      creating an SDP as a new Offer or an Answer. This is something of an oversight
      in the callback definition, as the caller of it does have this information.
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      404b6ab3
    • Matthew Jordan's avatar
      res/res_pjsip_sdp_rtp: Remove left over reference to override_prefs · b263c8bd
      Matthew Jordan authored
      The usage of the local override_prefs variable in create_outgoing_sdp_stream
      was previously to track an override format preference set by PJSIP_MEDIA_OFFER.
      Now, however, that function simply sets the joint capabilities structure,
      session->req_caps. During the media format rework, the override_prefs was
      instead used to check if there were any formats in session->req_caps.
      
      However, this usage isn't useful in create_outgoing_sdp_stream.
      session->req_caps contains the negotiated formats for *all* streams, not just
      the current one being created. Thus, so long as any stream of any type has
      provided a format, override_prefs will be non-zero. Hence, its usage in
      checking whether or not we should look at the formats on the endpoint or
      the joint capabilities is generally useless.
      
      There's only two things useful to check:
      (1) Does the endpoint have a format for the media type?
      (2) Did we negotiate a format for the media type?
      
      If either of those is a 'no', then we must kill the media stream.
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b263c8bd
  10. Oct 17, 2014
  11. Oct 16, 2014
Loading