[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl5-changes
Subject:    [perl.git]  branch tonyc/127743-cperl-storable-fixes created. v5.27.6-80-g6a90b60ea9
From:       Tony Cook <tony () develop-help ! com>
Date:       2017-11-23 3:06:09
Message-ID: E1eHhq5-00011Y-QU () git ! dc ! perl ! space
[Download RAW message or body]

In perl.git, the branch tonyc/127743-cperl-storable-fixes has been created

<https://perl5.git.perl.org/perl.git/commitdiff/6a90b60ea989e9e529eb46e73903f321c47d8458?hp=0000000000000000000000000000000000000000>


        at  6a90b60ea989e9e529eb46e73903f321c47d8458 (commit)

- Log -----------------------------------------------------------------
commit 6a90b60ea989e9e529eb46e73903f321c47d8458
Author: Tony Cook <tony@develop-help.com>
Date:   Wed Nov 22 05:24:29 2017 +0100

    (perl #127743) read the hash's flags for large SX_FLAG_HASH ops
    
    Unfortunately testing this requires more memory than any machine I
    have available has.

commit 053646a3b568cac2d90e04afd11aa61605e598e3
Author: Tony Cook <tony@develop-help.com>
Date:   Wed Nov 22 00:17:33 2017 +0100

    (perl #127743) we should only handle SX_LOBJECT ops on 64-bit platforms
    
    retrieve_lobject() handled such large objects I'm assuming to handle
    smaller sizes stored in a 64-bit length/count, but that can only
    happen if someone isn't using Storable to generate the data.

commit 95cf28e9c44346bd4275ac74cad761b74c05533e
Author: Tony Cook <tony@develop-help.com>
Date:   Tue Nov 21 05:55:32 2017 +0100

    (perl #127743) fix network order read/write of large values
    
    This had a couple of bugs:
    
    - W64LEN() used a union where it should have used an array or struct,
      so a network order 64-bit length was written as 4 bytes.  Oops.
    
      Changed to use an array.
    
    - retrieve_lobject() always read the length in host order, so it sort
      of tried to read the length in network order on 32-bit platforms,
      but then didn't fix the order of the length it read.
    
      Now uses READ_U64() (which I originally messed up myself, oops.)

commit e66d28554ee5ae935a4efba8644774350d90e470
Author: Tony Cook <tony@develop-help.com>
Date:   Tue Nov 21 05:51:07 2017 +0100

    (perl #127743) fixes for READ_U64()
    
    - ntohl() the low word too, doh
    
    - if ntohl() isn't provided, then provide it, with appropriate
      wrapping.  Should be exteneded to other uses.
    
    - only available for 64-bit builds

commit 7aa8439cbc3b78cdbc2f5fbb53122fac9aa103c0
Author: Tony Cook <tony@develop-help.com>
Date:   Tue Nov 21 05:12:16 2017 +0100

    (perl #127743) fix some -DDEBUGGING build issues

commit a56a37f47a3712d56d868388135c4b97ed45c72f
Author: Tony Cook <tony@develop-help.com>
Date:   Tue Nov 21 00:05:28 2017 +0100

    (perl #127743) limit the number of extra refs returned by STORABLE_freeze
    
    Ensure some over enthusiastic STORABLE_freeze() doesn't cause us to
    emit a negative reference count for SX_HOOK.
    
    This fails to be parsed by older versions and flags 64-bit ids for new
    versions of Storable.

commit 19b370e7c8e499f8f74869919f1cb533a44966e6
Author: Tony Cook <tony@develop-help.com>
Date:   Thu Nov 2 06:55:45 2017 +0100

    (perl #127743) fix large object ids in hook sequences
    
    As with SX_OBJECT, if there are a large number of SVs being frozen the
    object ids can exceed the 32-bit limit.
    
    The problem here is how to indicate that we have 64-bit ids without
    breaking older versions parsing our results for smaller object trees?
    
    We don't have any room in the flags byte, currently used as:
    
     bits  use
     ----  ---
     0,1   type
     2     class length is > 255 bytes
     3     frozen string > 255 bytes
     4     more than 255 extra references
     5     class name has been seen before and is represented as an index
     6     an extra reference is stored next
     7     has a list of extra references
    
    and the extra byte is only used for tied SVs.  We can't repurpose the
    bits 6, 7 since it would break older readers.
    
    I considered adding SX_LARGE_HOOK, or something similar, but we find
    out that large ids are needed well after the op code has been emitted.
    
    So how is the handling of the length + ids handled in retrieve_hook()?
    
        I32 len3 = 0;
        ...
            if (flags & SHF_LARGE_LISTLEN)
                RLEN(len3);
    	else
                GETMARK(len3);
            if (len3) {
                av = newAV();
                av_extend(av, len3 + 1);	/* Leave room for [0] */
                AvFILLp(av) = len3;		/* About to be filled anyway */
            }
    
    For SHF_LARGE_LISTLEN this treats the len3 as signed - so if the
    writer had more than 2**31-2 objects after the "frozen" string,
    decoding is going to break anyway, as av_extend_guts() panics on "key"
    values less than -1.
    
    The code that actually reads the ids will fail to read any ids when
    len3 is negative, since the for loop does a i <= len3 check.
    
    So rather than trying to fix this, I used a negative len3 to indicate
    that the object ids are 64-bit.
    
    This means we get backward compatibility in the cases where 32-bit ids
    work, and older versions of Storable will reject it.
    
    If an older version of Storable wrote a negative len3 (due to
    overflow) we'll be attempting to read 32-bit ids as typically very
    large 64-bit ids (much larger than 2**32 in most cases) which won't be
    found in the seen array, failing the thaw.

commit 9f00966805e912276acf1d1d02d20f6e8258499d
Author: Tony Cook <tony@develop-help.com>
Date:   Wed Nov 1 23:58:49 2017 +0100

    (perl #127663) update PERL_TEST_MEMORY requirements for the older tests
    
    PERL_TEST_MEMORY includes any swap, it's not the minimum resident set
    for the test.

commit 629e8dcbfa901568037b884548b7c463ac316e14
Author: Tony Cook <tony@develop-help.com>
Date:   Wed Nov 1 23:31:39 2017 +0100

    (perl #127663) fix two problems with large object ids
    
    Storable assigns an object id to every scalar it freezes, including to
    unused elements in arrays.
    
    There were two problems here:
    
    a) in retrieve(), object ids over 2**31-1 but less than 2**32 were
       treated as signed, so the wrong object was produced in the resulting
       data structure.  Two changes we made to fix this:
    
      i)  retrieve() now treats object ids in the problem range as
          unsigned, so data written by older Storables is now treated
          correctly.
    
      ii) store() now writes object ids in the problem range as 64-bit
          ids, so that older Storables will fail rather than producing an
          incorrect result data structure.
    
    b) once over 2**32 scalars had been output, the code still produced
       32-bit object ids when referring to previous scalars.  Fixed by
       adding support for 64-bit object ids.
    
    There's still an issue with object ids in hook produced data.
    
    Testing these changes requires ridiculous amounts of memory - ~32GB
    for a) and ~66GB for b), and the tests take a long time to run, hence
    for those tests to run you need the following in the environment;
    
      PERL_TEST_MEMORY >= 70
      PERL_RUN_SLOW_TESTS != 0

commit c0251eeb71dc3f11adec24185c29b40d0c549da0
Author: Tony Cook <tony@develop-help.com>
Date:   Wed Oct 25 13:55:52 2017 +1100

    (perl #127743) correct some types for Win32
    
    In a couple of places the code uses unsigned long to represent values
    possibly larger than 2**32, but long is 32-bits on x64 Win32, so
    use STRLEN or Ssize_t instead.

commit 2f3e8b0b3e5ea882c6e7dae0e06b2d0a03a7668d
Author: Reini Urban <rurban@cpan.org>
Date:   Mon Jul 24 13:58:37 2017 +0200

    Storable 3.05_13: safe defaults
    
    mingw fix: use safe defaults, not segfaulting defaults.
    mingw fails on the stacksize binary search, leaving it empty.
    
    (cherry picked from commit 27c613e5f8dfab7b8b43a57e93a478aa962dd9ca)
    
    Conflicts:
    	dist/Module-CoreList/lib/Module/CoreList.pm
    	dist/Storable/Storable.pm
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit dee5ebc5f1ed499d3074c2067960082893385df0
Author: Reini Urban <rurban@cpan.org>
Date:   Fri Jul 14 16:15:40 2017 +0200

    Storable: Analyze #304
    
    Add a better error message on one of the possible failure causes
    when the system cannot catch the stackoverflow.
    
    (cherry picked from commit 3f655dc6444cd56d09d4a99a4be5a92c1119506b)

commit 64b2fffb85961d5a6210f37f3727f7569300f36d
Author: Reini Urban <rurban@cpan.org>
Date:   Wed May 17 22:40:59 2017 +0200

    Storable: cygwin64 MAX_DEPTH /2
    
    (cherry picked from commit 5c3259bf9a54c29b526cb36cdf155005d8f93236)

commit 58c8e32f20ef5b3742eee9b6453b5550639e58e2
Author: Reini Urban <rurban@cpan.org>
Date:   Sun May 14 22:28:21 2017 +0200

    Storable: Need more stack reserve on cygwin also
    
    Same stack quirks as on MSWin32.
    cygwin64 cannot even do 32, try 40.
    
    (cherry picked from commit c663e2126c5060f80eb973828a341606f210f671)

commit 15b86496534575948dd349ae79e9a1c06a05b689
Author: Reini Urban <rurban@cpan.org>
Date:   Fri May 12 09:49:38 2017 +0200

    Storable: fix cygwin stack probing
    
    don't set the PATH needed for other DLLs also.
    
    (cherry picked from commit d0f8b62c3f9ffee9fa8397d4acdadbd695cc4839)

commit e0daa5c7714177709c0a66bf02da4573f7ee0d75
Author: Reini Urban <rurban@cpan.org>
Date:   Wed Apr 19 09:18:49 2017 +0200

    Storable: Update to 3.05_12
    
    enhance stack reserve from 8 to 16
    
    (cherry picked from commit e344ff0826555342fe207a4a52bcdda4b00e2c44)
    
    Conflicts:
    	Porting/Maintainers.pl
    	dist/Module-CoreList/lib/Module/CoreList.pm
    	dist/Storable/Storable.pm
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit d8d132b190a0f4ac00ae4fa830e95a12a7f16c01
Author: Reini Urban <rurban@cpan.org>
Date:   Tue Apr 18 10:39:29 2017 +0200

    Storable: fix stacksize with shared libcperl
    
    LD_LIBRARY_PATH=dist/Storable/../..
    Interestingly only detected on Solaris, not elsewhere.
    
    (cherry picked from commit 4fc1e35393d951b249e36e02f89ec8d0f9cd7537)

commit d77f4a16c182834d8dc3b6d9f3e653cf4dbfcac6
Author: Reini Urban <rurban@cpan.org>
Date:   Thu Mar 30 11:22:31 2017 +0200

    Storable: fix wrong fake_tag check
    
    coverity CID 165506. if (!sv) is always true. check fake_tag instead.
    
    (cherry picked from commit 3cb71a68201936293a78ed93ca8049ee4cba5497)

commit 0174f0ea5d5bf0879f8ef7848248ba63f00b73c7
Author: Reini Urban <rurban@cpan.org>
Date:   Thu Mar 30 09:04:07 2017 +0200

    Storable: memory leak
    
    detected by coverity
    
    (cherry picked from commit b60e26ff913f3ada34f57e79347e11d3872876c9)

commit 7840d559a2abe91ad221862bfdda05f0f3542907
Author: Reini Urban <rurban@cpan.org>
Date:   Wed Mar 29 21:04:28 2017 +0200

    Storable 3.05_11: croak on sizes read > I32_MAX
    
    detected by coverity:
    CID 165606 (#2 of 2): Untrusted value as argument (TAINTED_SCALAR)
    146. tainted_data: Passing tainted variable size to a tainted sink.
    
    (cherry picked from commit 735d9229a540d05f2d34f46ffea1e68aea9fbbc1)
    
    Conflicts:
    	dist/Storable/Storable.pm

commit c6dcfac0288f185f0ff55e6042d3b8fd47d4abef
Author: Reini Urban <rurban@cpan.org>
Date:   Wed Mar 29 21:52:30 2017 +0200

    Storable: simplify last_op_in_netorder
    
    remove dead code, detected by coverity
    
    (cherry picked from commit f1e1f909cfd3e474a0b11f0200a3889b8ff2cc6f)

commit d5eff17d6b119dd6dddda4c23f1cb9c94389db74
Author: Reini Urban <rurban@cpan.org>
Date:   Wed Mar 29 21:32:57 2017 +0200

    Storable: protect from empty retrieve_vstring
    
    empty sv detected by coverity
    
    (cherry picked from commit 96c0b32bf6ab37f5e82494b79149680012dde49f)

commit d935d730d9d5674dc2accf7ffb20229f4282e478
Author: Reini Urban <rurban@cpan.org>
Date:   Wed Mar 29 21:29:46 2017 +0200

    Storable: protect store_other error buf
    
    coverity warns about static buffer overflow.
    
    (cherry picked from commit 74804347b8da42bc5b471646032c2e8d9903106f)

commit 42792e6fe810d78d504b13b1e1f6d8023186e7c1
Author: Reini Urban <rurban@cpan.org>
Date:   Tue Mar 14 10:05:24 2017 +0100

    Storable: Bump to 3.05_10
    
    No changes, synced cpan with CORE
    
    (cherry picked from commit 0edca17dff085908bd7c3286ffabb3c0e9371706)
    
    Conflicts:
    	Porting/Maintainers.pl
    	dist/Module-CoreList/lib/Module/CoreList.pm
    	dist/Storable/Storable.pm
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit 91ff3846551ad1b2370784f348e3ea64e4adb7d0
Author: Reini Urban <rurban@cpan.org>
Date:   Sun Mar 12 12:28:31 2017 +0100

    Storable: various core fixups: $PERL,libpth,getcwd
    
    stacksize needs to run perl, not miniperl,
    but the chdir broke $^X (a relative path).
    Quote $^X only with whitespace.
    Set LD_LIBRARY_PATH with a shared libperl.
    Support a --core argument to stacksize.
    Probe it twice.
    
    (cherry picked from commit 0df5d8e463b9b5cfe14f9c235191fd3e5e4013a4)

commit 3da7a4e634469a48d690b3da07ed9de3b1764b7a
Author: Reini Urban <rurban@cpan.org>
Date:   Fri Mar 10 10:59:53 2017 +0100

    Storable: core Makefile.SH support
    
    redo building Storable after perl was built,
    with the probed stacksize.h values.
    We can only produce stacksize.h with a PERL_EXE
    so we have to do it twice.
    
    TonyC:
    
     - this fixes the stack overflow iff the rebuild_storable target runs
       after storable is built, but there's nothing preventing
       lib/auto/Storable/Storable.so being built *after* rebuild_storable
       in a parallel build at this point.
    
     - It's also possible for both the lib/...Storable.so target and the
       rebuild_storable target to run at the same time, possibly
       corrupting the generated binary (check 4d106cc5 for ext/SDBM_File
       for example)
    
    Conflicts:
    	.git-rr-cache
    	pod/perlcdelta.pod
    	win32/Makefile.ce

commit e0a8bedfd588f37bbb2d1c7b17476ffa1e5606bb
Author: Reini Urban <rurban@cpan.org>
Date:   Thu Mar 9 09:49:31 2017 +0100

    Storable 3.05_09: compute stacksize
    
    (cherry picked from commit a10c78df8c03018ce50f0885bb6b6a5509d9e58f)
    
    TonyC:
     - dist/Storable/t/recurse.t is still crashing on a stack overflow
    
    Conflicts:
    	Porting/Maintainers.pl
    	dist/.gitignore
    	dist/Module-CoreList/lib/Module/CoreList.pm
    	dist/Storable/Storable.pm
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit f51af693624d7095b8f427258e5c73e290d4e1a5
Author: Reini Urban <rurban@cpan.org>
Date:   Wed Mar 8 16:18:32 2017 +0100

    Storable 3.05_08: adjust MAX_DEPTH
    
    2000 is too large for DEBUGGING with clang++. It runs into stack overflow.
    Seperate between c++ and c, debugging and non, 32bit and 64bit.
    
    Tune the stack sizes for various variants.
    New stack recursion limits:
    64: c++ dbg: 1200   DEBUGGING + DEBUG_LEAKING_SCALAR non-threaded
        c   dbg: 3000
        c -O3:   34000 (tested: 34500)
    32: c -O3:   30000 (tested: 32600)
        c   dbg: 750   (tested: 1500)
    asan: 254
    
    Note that the result has to be int, as the value is then right shifted by the
    pre-processor, >> 1, for hashes (i.e. divide by 2).
    
    TonyC:
     - Storable.o fails to build, but the offending code is removed in the
       next commit
    
    (cherry picked from commit a7aff4921e16004c42e40914914e5f3320238e12)
    
    Conflicts:
    	dist/Module-CoreList/lib/Module/CoreList.pm
    	dist/Storable/Storable.pm
    	dist/Storable/t/blessed.t
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit 686f83d50caaa7f5ab3495acf455dbd364441a71
Author: Reini Urban <rurban@cpan.org>
Date:   Sun Mar 5 11:29:54 2017 +0100

    Storable 3.05_07: update documentation from CPAN
    
    from the CPAN version.
    
    (cherry picked from commit 81259118dd8e16b10dfbdcfe1e2355bae507ac51)
    
    Conflicts:
    	.git-rr-cache
    	dist/Storable/Storable.pm
    	pod/perlcdelta.pod

commit 3225050c3063ac7dc18a285acd75fe3003dba4d2
Author: Reini Urban <rurban@cpan.org>
Date:   Sun Mar 5 11:09:01 2017 +0100

    Storable: improve recursion depth check
    
    Store each recursive SV and only ++depth when recursing
    into this same SV, not nested into 2 levels, for performance reasons.
    (We'd really need to store a hash, but this would be slow.)
    So it only protects from the simpliest stack exhaustion attacks,
    others still will segfault.
    Decrease the max depth numbers: 2000 for RV and AV, 1000 for HV,
    experimentally tested for normal stack sizes.
    
    At least it doesnt falsely error with an arrayref nested into another
    big array, as with the CPAN write_metadata_cache.
    Check now also refs recursion into each other.
    
    Closes #257.
    
    (cherry picked from commit cd2b11a42ef9c6829960039382a06622d7248755)
    
    Conflicts:
    	dist/Storable/Storable.pm
    	pod/perlcdelta.pod

commit f072440c61cffd89e0573e2bb92400be562c5664
Author: Reini Urban <rurban@cpan.org>
Date:   Sat Mar 4 12:42:36 2017 +0100

    Storable: add testcase for #257
    
    detected by CPAN,
    wrong recursion warning with CPAN write_metadata_cache.
    There's no recursion involved, just nesting a hash into a big
    array will fail.
    
    (cherry picked from commit 2804828cb8c402649cc89f1c40fda63932ccae44)

commit 7dbd1f3e4d768bb52556c05fe8926839792ae45c
Author: Reini Urban <rurban@cpan.org>
Date:   Tue Feb 28 23:34:45 2017 +0100

    Fix rurban email address
    
    use the generic cpan.org
    
    (cherry picked from commit 90875988463bbf4b10af59633e23a6a2b2a2cfbe)
    
    TonyC:
     - at this point dist/Storable/t/recurse.t crashes with a stack
       overflow, presumably fixed by the later "tuning" commits
    
    Conflicts:
    	.travis.yml
    	AUTHORS
    	Porting/do-conf-cperl-release
    	Porting/do-make-cperl-release
    	Porting/release_cperl.pod
    	appveyor.yml
    	cpan/CPAN-Meta-Requirements/lib/CPAN/Meta/Requirements.pm
    	cpan/CPAN-Meta/lib/CPAN/Meta.pm
    	cpan/Config-Perl-V/t/28_plv522c.t
    	cpan/Cpanel-JSON-XS/XS.pm
    	cpan/Scalar-List-Utils/lib/Sub/Util.pm
    	cpan/YAML-LibYAML/lib/YAML/XS.pod
    	dist/CPAN-Meta/lib/Parse/CPAN/Meta.pm
    	ext/Config/Makefile.PL
    	pod/cperl.pod
    	pod/perl.pod
    	t/porting/customized.dat

commit 55fc029d7f2c2b76c6538dfa6a01f0b7196c32c8
Author: Reini Urban <rurban@cpanel.net>
Date:   Mon Jan 30 22:16:44 2017 +0100

    Storable: Update to 3.05_03
    
    Appveyor win64 fails to create nested hash.
    Need to repro it on a failing machine. Maybe Win64
    uses a much bigger stack for its threads. But 5000 should
    still be doable, as other machines can do 22_000.
    
    (cherry picked from commit 81786bf3f6be1f6326b588eca9ae3ccc4824b5a8)
    
    Conflicts:
    	.git-rr-cache
    	Porting/Maintainers.pl
    	dist/Storable/Storable.pm
    	pod/perlcdelta.pod

commit 3566e5428844866968df115cc06661c2d3929171
Author: Reini Urban <rurban@cpanel.net>
Date:   Mon Jan 30 17:52:24 2017 +0100

    Storable: Update to 3.05_02
    
    Protect against stack overflows with nested arrays and hashes
    [cpan #97526]. This imposes a new limit to your nested structures,
    but JSON::XS has a limit of 512. We use a max_depth of 3000 for the
    typical stack limit of 8k.
    You can still overflow the call stack with nested scalar refs.
    
    (cherry picked from commit 63a5b7f922c2900e328ce97b57d0a54fbc763a98)
    
    Conflicts:
    	.git-rr-cache
    	Porting/Maintainers.pl
    	dist/Storable/Storable.pm
    	pod/perlcdelta.pod

commit ab7f4bb5f24cd5fddca956c5c1aa75a00b882812
Author: Reini Urban <rurban@cpanel.net>
Date:   Sun Jan 29 12:43:18 2017 +0100

    Storable: Upgrade to 3.05 from CPAN
    
    See https://github.com/rurban/Storable/
    
    (cherry picked from commit 17a1797c711ed6de48985b0746ae59282f634b12)
    
    Conflicts:
    	Porting/Maintainers.pl
    	dist/Storable/Storable.pm
    	dist/Storable/Storable.xs
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit 81a4d44b5dc1a3db1cf4b8a93d7a348566ae23bb
Author: Reini Urban <rurban@cpanel.net>
Date:   Fri Jan 27 17:10:17 2017 -0600

    Storable: re-indent from 8 hard tabs to soft 4
    
    (cherry picked from commit a5b8bb11df1a50b585a1b07965c860c234877ce3)
    
    Conflicts:
    	dist/Storable/Storable.xs
    	t/porting/customized.dat

commit 614ede3f2c676515466f5f6494bf559604ee17cc
Author: Reini Urban <rurban@cpanel.net>
Date:   Fri Jan 27 10:45:53 2017 -0600

    Storable: skip LOBJECT on 32bit
    
    croak there.  There is no way to store 64bit objects, and when reading them
    we need to croak.  We check the len though (at least on little-endian, on
    big-endian this is broken.)
    
    (cherry picked from commit d6e38371a2997e9546cbf340148a41439091b3c2)
    
    Conflicts:
    	.git-rr-cache
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit e7ee3ee02871826cc3ac505b4300dfd79e9111e0
Author: Reini Urban <rurban@cpanel.net>
Date:   Thu Jan 26 17:31:35 2017 -0600

    Storable: fixup huge
    
    followup to 67a5186ac1aee4b63 with 3.00c.
    MBUF_XTEND and more internal sizes, esp. the dclone size,
    needs to use long, not int.
    Improve TRACEME to cut off printing overlong strings.
    
    (cherry picked from commit d987f810b5f285b075103f58ce43e54d181643bc)
    
    Conflicts:
    	pod/perlcdelta.pod
    	pod/perlcperl.pod
    	t/porting/customized.dat

commit 95a531c7af47a8443aae1385e65ff42d33615275
Author: Reini Urban <rurban@cpanel.net>
Date:   Wed Jan 25 11:27:07 2017 -0600

    Storable: protect against classname len overflow
    
    name lenghts can be max. I32 (hek_len), but are read from
    system size integers. e.g. -1 you can cause a malloc fail => exit.
    
    Even worse len > LG_BLESS didn't detect that so you could overwrite
    the stack by malcrafted Storable files.
    Found out by JD. RT #130635. No CVE since p5p believes local Storable
    files are not exploitable.
    
    (cherry picked from commit c82e80f6d88891738e2b5329723606b48347fa31)
    
    Conflicts:
    	.git-rr-cache
    	Porting/Maintainers.pl
    	dist/Storable/Storable.xs
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit 670c8d22f016eef0c1bba2edb40e7844e19fe13c
Author: Reini Urban <rurban@cpanel.net>
Date:   Sat Jan 7 09:01:29 2017 +0100

    Storable 3.04c: fix printf types
    
    esp. for 32bit use64bitint:
    Storable.xs:2348:4: warning: shift count >= width of type \
[-Wshift-count-overflow]  STORE_PV_LEN((const char *)mg->mg_ptr, len
    
    cast printf args to the right type.
    
    (cherry picked from commit c08d0a10791ec59b04354a1fbd2ed07b3681c703)
    
    Conflicts:
    	.git-rr-cache
    	dist/Storable/Storable.pm
    	t/porting/customized.dat

commit 392e85709fae9331a025c7195dcf9442928b4550
Author: Reini Urban <rurban@cpanel.net>
Date:   Sun Nov 20 18:06:45 2016 +0100

    Storable:  Update to 3.02c
    
    Fix -Wc++11-compat warnings
    
    (cherry picked from commit 852424577630848b6ed6faef3f3a0396f2e91bb8)
    
    Conflicts:
    	dist/Storable/Storable.pm
    	dist/Storable/Storable.xs
    	pod/perlcdelta.pod
    	t/porting/customized.dat

commit 43f29de5e606fffb7d6c0dd791ba9a80e35b0ea2
Author: Reini Urban <rurban@cpanel.net>
Date:   Mon Oct 10 12:14:49 2016 +0200

    Storable: fix -Wchar-subscripts
    
    array subscript is of type char. in DEBUGGING code only.
    
    (cherry picked from commit 07af5b27a799f0b88a5368d81fd57c7643e2edff)
    
    Conflicts:
    	t/porting/customized.dat

commit 59a8414e21b457d70a68afc854a7bd5ee5359668
Author: Reini Urban <rurban@cpanel.net>
Date:   Fri Sep 16 01:20:42 2016 +0200

    Storable 3.01 security: detect CVE-2015-1592
    
    warn and test against this published metasploit attack vector.
    See GH #199
    
    Conflicts:
    	dist/Storable/Storable.pm
    
    TonyC:
     - backported parts of 17a1797 to make it compatible with blead
     - updated MANIFEST

commit 9fa63991967f5cfa3167aa6c664f00409f05c3cc
Author: Reini Urban <rurban@cpanel.net>
Date:   Fri Sep 16 12:01:48 2016 +0200

    Storable: silence cast warnings

commit 98c88df92ef12ad05a46bfd052898a3ae4aa4826
Author: Reini Urban <rurban@cpanel.net>
Date:   Mon Jun 20 08:29:27 2016 +0200

    Storable: comments

commit 2229630b65184c53069685e067455498ccf01e48
Author: Reini Urban <rurban@cpanel.net>
Date:   Wed Oct 4 15:26:37 2017 +1100

    Storable: throw exception on huge values
    
    The Storable data format is incapable of representing lengths of 2**31 or
    greater; and if you try, you can get segfaults or corrupt data or other fun
    and games.
    
    Though it would be undeniably good to fix this properly, this is just a
    simple starting point: the limitation is documented, and an exception is
    thrown when such data is encountered.
    
    Signed-off-by: Reini Urban <rurban@cpanel.net>
    
    Conflicts:
    	dist/Storable/Storable.pm
    	dist/Storable/Storable.xs

commit 8d36a0f301b92af62443d0bd08b170ce07d420a9
Author: Reini Urban <rurban@cpanel.net>
Date:   Sun May 8 20:28:51 2016 +0200

    Release cperl-5.22.2
    
    Conflicts:
    	INSTALL
    	META.json
    	dist/Module-CoreList/lib/Module/CoreList.pm
    	dist/Module-CoreList/lib/Module/CoreList/Utils.pm
    	pod/perlhist.pod
    	t/porting/customized.dat
    
    TonyC:
     - this was largely a core commit, with a minor change to Storable.
       Only the change to Storable has been included.
    
    Cherry-picked from 5d23481d9dc73edc8b59e3ad1ea9f7da164fcfd3

commit e3e0b3992c0443a17a1850838e2af3f356e3d4c6
Author: Reini Urban <rurban@cpanel.net>
Date:   Fri Apr 29 12:26:47 2016 +0200

    Storable: fix win32, missing INT32_MAX

commit 68e1c992a4879ed4d3522f337cd37d2f1ff9b6d4
Author: Reini Urban <rurban@cpanel.net>
Date:   Fri Apr 1 09:42:41 2016 +0200

    parser: expand tokenbuf from 256 to 1024
    
    This should speed up parsing,
    and changes the "Identifier too long" limitation from max 256 to 1024.
    See [cperl #124]
    
    TonyC:
     - this was largely a core change, with an incidental change to Storable,
       only the Storable change has been included for compatibility with cperl

commit 079ab090a3a5a394aa7bc4a0150dfaf30629e11e
Author: Reini Urban <rurban@cpanel.net>
Date:   Tue Mar 29 17:50:09 2016 +0200

    Storable 3.00: u64 strings, arrays and hashes >2G
    
    via a new LOBJECT tag. This is for 32bit systems and lengths
    between 2GB and 4GB (I32-U32), and 64bit (>I32).
    Use SSize_t array and hash lengths, see [cperl #123].
    
    Even for hashes, which we cannot iterate over.
    This is a upstream limitation in the HvAUX struct and API.
    We can store >2G keys though, which is fully supported
    in subsequent cperl commits for #123, but not perl5 upstream.
    
    Add several helper functions for strings and hash entries,
    removed a lot of duplicate code.
    
    Reformat consistently (tabs: 8)
    
    Modernize:
    * get rid of main'dump
    * get rid of *FILE typeglob, replace with lexical filehandle
    * fix parallel tests, use unique filenames.
    * fixed many instances of 2arg open,
    * keep backcompat default handling for XS functions, handle the flag
      default there.
    * remove default $Storable::flags settings in the tests
    * fix some too short I32 len types in the XS
    
    Conflicts:
    	dist/Storable/Storable.pm
    	dist/Storable/Storable.xs
    	dist/Storable/t/attach_errors.t
    	dist/Storable/t/blessed.t
    	dist/Storable/t/destroy.t
    	dist/Storable/t/testlib.pl

commit bb254c57bb4b093c95f1dd4b0f331224e19879df
Author: Aaron Crane <arc@cpan.org>
Date:   Fri Mar 18 15:22:12 2016 +0000

    Storable: throw exception on huge values
    
    The Storable data format is incapable of representing lengths of 2**31 or
    greater; and if you try, you can get segfaults or corrupt data or other fun
    and games.
    
    Though it would be undeniably good to fix this properly, this is just a
    simple starting point: the limitation is documented, and an exception is
    thrown when such data is encountered.
    
    Signed-off-by: Reini Urban <rurban@cpanel.net>
    
    Conflicts:
    	dist/Storable/Storable.pm
    	dist/Storable/Storable.xs

commit a2a95cf2d4544145fc099d5c9ae08dda261a4a85
Author: Reini Urban <rurban@cpanel.net>
Date:   Tue Mar 29 14:59:02 2016 +0200

    Storable: document, reformat and fix for DEBUGGING
    
    fix t/blessed.t: we do try to auto-load modules
    for bless, and avoid regressions. One security flag
    BLESS_OK is enough to disable this.
    
    fix all DEBUGGING 64bit warnings, with TRACEME.
    
    add asserts from blead perl 5.24.
    
    update hints/linux.pl for the known gcc -O3 bug.
    Not repro with gcc 4 nor clang.
    
    fix documentation: SECURITY WARNING, Large data
    on 64-bit platforms
    
    Conflicts:
    	dist/Storable/Storable.xs
    	dist/Storable/t/blessed.t
    
    Cherry-picked from fe00be04fba2ec29f6d0c897a21d0c2771954def

commit 650d9d932a542f9185bdfed6a8b27ad0e206d7d3
Author: Todd Rinaldo <toddr@cpanel.net>
Date:   Tue Oct 3 12:49:07 2017 +1100

    cPanel Storable 2.53_03: don't bless [security]
    
    Optional flags arg to disable bless|tie on retrieve/thaw
    
    Signed-off-by: Reini Urban <rurban@cpanel.net>
    and added documentation, reformat, compute CAN_FLOCK at compile-time.
    See [cperl #120]
    
    TonyC:
    
     - removed pod/perlcdelta.pod changes
     - this commit removed auto-loading modules for overloading, which
       was reinstated in a later commit.
    
    cherry-picked from 04b58ce1b1c391d04efb2c0a3da108603b8cafc6

commit bd45608735a1093c9b94f1755314f040d077f547
Author: Reini Urban <rurban@cpanel.net>
Date:   Thu Mar 24 17:49:07 2016 +0100

    Storable: bump to 2.53_02
    
    enable STORABLE_DEBUGME with -DEBUGGING.
    add split debugging trace messages.
    improve canonical store_hash pre-allocation.
    
    Conflicts:
    	dist/Storable/Storable.pm
    	dist/Storable/Storable.xs
    	dist/Storable/t/restrict.t

-----------------------------------------------------------------------

-- 
Perl5 Master Repository


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic