1. 11 Sep, 2017 1 commit
  2. 10 Sep, 2017 2 commits
  3. 08 Sep, 2017 3 commits
  4. 07 Sep, 2017 5 commits
  5. 06 Sep, 2017 6 commits
  6. 05 Sep, 2017 8 commits
  7. 04 Sep, 2017 5 commits
    • Christian Heimes's avatar
      [2.7] bpo-30622: Change NPN detection: (GH-2079) (#3316) · 72ed2331
      Christian Heimes authored
      * Change NPN detection:
      
      Version breakdown, support disabled (pre-patch/post-patch):
      - pre-1.0.1: OPENSSL_NPN_NEGOTIATED will not be defined -> False/False
      - 1.0.1 and 1.0.2: OPENSSL_NPN_NEGOTIATED will not be defined ->
      False/False
      - 1.1.0+: OPENSSL_NPN_NEGOTIATED will be defined and
      OPENSSL_NO_NEXTPROTONEG will be defined -> True/False
      
      Version breakdown support enabled (pre-patch/post-patch):
      - pre-1.0.1: OPENSSL_NPN_NEGOTIATED will not be defined -> False/False
      - 1.0.1 and 1.0.2: OPENSSL_NPN_NEGOTIATED will be defined and
      OPENSSL_NO_NEXTPROTONEG will not be defined -> True/True
      - 1.1.0+: OPENSSL_NPN_NEGOTIATED will be defined and
      OPENSSL_NO_NEXTPROTONEG will not be defined -> True/True
      
      * Refine NPN guard:
      
      - If NPN is disabled, but ALPN is available we need our callback
      - Make clinic's ssl behave the same way
      
      This created a working ssl module for me, with NPN disabled and ALPN
      enabled for OpenSSL 1.1.0f.
      
      Concerns to address:
      The initial commit for NPN support into OpenSSL [1], had the
      OPENSSL_NPN_* variables defined inside the OPENSSL_NO_NEXTPROTONEG
      guard. The question is if that ever made it into a release.
      This would need an ugly hack, something like:
      
      	GH-if defined(OPENSSL_NO_NEXTPROTONEG) && \
      		!defined(OPENSSL_NPN_NEGOTIATED)
      	GH-	define OPENSSL_NPN_UNSUPPORTED 0
      	GH-	define OPENSSL_NPN_NEGOTIATED 1
      	GH-	define OPENSSL_NPN_NO_OVERLAP 2
      	GH-endif
      
      [1] https://github.com/openssl/openssl/commit/68b33cc5c7.
      (cherry picked from commit b2d096bd)
      72ed2331
    • Zachary Ware's avatar
      [2.7] bpo-30450: Pull Windows dependencies from GitHub rather than SVN (GH-1783) (GH-3306) · 986b7ffc
      Zachary Ware authored
      The Windows build now depends on Python 3.6 to fetch externals, but it
      will be downloaded via NuGet (which is downloaded via PowerShell) if it
      is not available via `py -3.6`.  This means the only thing that must be
      installed on a modern Windows box to do a full build of CPython with all
      extensions is Visual Studio.
      
      Cherry-picked from 51599e2b, parts of 40a23e88, parts of 68d663cf, d5cd21d7, and possibly others that I've missed.
      
      Also:
      
      * Rename db -> bsddb for disambiguity
      
      * Update sqlite3 to 3.14.2.0 since it's the version we use on 3.x, and it's simpler to just use it than to also upload the old version to cpython-source-deps
      
      * Add PCbuild/*.ilk to .gitignore
      986b7ffc
    • Christian Heimes's avatar
      [2.7] bpo-25674: remove sha256.tbs-internet.com ssl test (GH-3297) (#3301) · 57d963b0
      Christian Heimes authored
      * bpo-25674: remove sha256.tbs-internet.com ssl test (#3297)
      Signed-off-by: default avatarChristian Heimes <christian@python.org>
      (cherry picked from commit 002d6403)
      
      * [2.7] bpo-25674: remove sha256.tbs-internet.com ssl test (GH-3297)
      
      Signed-off-by: Christian Heimes <christian@python.org>.
      (cherry picked from commit 002d6403)
      57d963b0
    • larryhastings's avatar
      Blurbify 2.7. (#3286) · 05308c73
      larryhastings authored
      05308c73
    • INADA Naoki's avatar
      bpo-31095: Fix potential crash during GC (GH-3197) · 4cde4bdc
      INADA Naoki authored
      (cherry picked from commit a6296d34)
      4cde4bdc
  8. 02 Sep, 2017 1 commit
    • Pauli Virtanen's avatar
      [2.7] bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (GH-31) (#3242) · 990b2d04
      Pauli Virtanen authored
      [2.7] bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (GH-31)
      
      Ctypes currently produces wrong pep3118 type codes for several types.
      E.g. memoryview(ctypes.c_long()).format gives "<l" on 64-bit platforms,
      but it should be "<q" instead for sizeof(c_long) == 8
      
      The problem is that the '<>' endian specification in the struct syntax
      also turns on the "standard size" mode, which makes type characters have
      a platform-independent meaning, which does not match with the codes used
      internally in ctypes.  The struct module format syntax also does not
      allow specifying native-size non-native-endian items.
      
      This commit adds a converter function that maps the internal ctypes
      codes to appropriate struct module standard-size codes in the pep3118
      format strings. The tests are modified to check for this..
      (cherry picked from commit 07f1658a)
      990b2d04
  9. 29 Aug, 2017 1 commit
  10. 27 Aug, 2017 1 commit
  11. 26 Aug, 2017 5 commits
  12. 22 Aug, 2017 2 commits