--- CBOR-XS/XS.pm	2017/06/27 02:03:24	1.66
+++ CBOR-XS/XS.pm	2019/11/09 07:30:36	1.70
@@ -40,6 +40,9 @@
 data later and speed is less important you might want to compare both
 formats first).
 
+The primary goal of this module is to be I<correct> and the secondary goal
+is to be I<fast>. To reach the latter goal it was written in C.
+
 To give you a general idea about speed, with texts in the megabyte range,
 C<CBOR::XS> usually encodes roughly twice as fast as L<Storable> or
 L<JSON::XS> and decodes about 15%-30% faster than those. The shorter the
@@ -54,9 +57,6 @@
 (see C<allow_sharing> and C<allow_cycles>), string deduplication (see
 C<pack_strings>) and scalar references (always enabled).
 
-The primary goal of this module is to be I<correct> and the secondary goal
-is to be I<fast>. To reach the latter goal it was written in C.
-
 See MAPPING, below, on how CBOR::XS maps perl values to CBOR values and
 vice versa.
 
@@ -66,7 +66,7 @@
 
 use common::sense;
 
-our $VERSION = 1.7;
+our $VERSION = 1.71;
 our @ISA = qw(Exporter);
 
 our @EXPORT = qw(encode_cbor decode_cbor);
@@ -217,7 +217,7 @@
 
 Detecting shared values incurs a runtime overhead when values are encoded
 that have a reference counter large than one, and might unnecessarily
-increase the encoded size, as potentially shared values are encode as
+increase the encoded size, as potentially shared values are encoded as
 shareable whether or not they are actually shared.
 
 At the moment, only targets of references can be shared (e.g. scalars,
@@ -455,7 +455,8 @@
 
 This is useful if your CBOR texts are not delimited by an outer protocol
 and you need to know where the first CBOR string ends amd the next one
-starts.
+starts - CBOR strings are self-delimited, so it is possible to concatenate
+CBOR strings without any delimiters or size fields and recover their data.
 
    CBOR::XS->new->decode_prefix ("......")
    => ("...", 3)
@@ -1059,7 +1060,8 @@
 =head1 SECURITY CONSIDERATIONS
 
 Tl;dr... if you want to decode or encode CBOR from untrusted sources, you
-should start with a coder object created via C<new_safe>:
+should start with a coder object created via C<new_safe> (which implements
+the mitigations explained below):
 
    my $coder = CBOR::XS->new_safe;
 
@@ -1091,7 +1093,7 @@
 
 So, if you are not sure about the security of all the modules you
 have loaded (you shouldn't), you should disable this part using
-C<forbid_objects>.
+C<forbid_objects> or using C<new_safe>.
 
 =item CBOR can be extended with tags that call library code
 
@@ -1100,9 +1102,9 @@
 third-party modules (see the C<filter> method).
 
 If you don't trust these, you should configure the "safe" filter function,
-C<CBOR::XS::safe_filter>, which by default only includes conversion
-functions that are considered "safe" by the author (but again, they can be
-extended by third party modules).
+C<CBOR::XS::safe_filter> (C<new_safe> does this), which by default only
+includes conversion functions that are considered "safe" by the author
+(but again, they can be extended by third party modules).
 
 Depending on your level of paranoia, you can use the "safe" filter:
 
@@ -1127,8 +1129,9 @@
 crash safely). The size of a CBOR string in octets is usually a good
 indication of the size of the resources required to decode it into a Perl
 structure. While CBOR::XS can check the size of the CBOR text (using
-C<max_size>), it might be too late when you already have it in memory, so
-you might want to check the size before you accept the string.
+C<max_size> - done by C<new_safe>), it might be too late when you already
+have it in memory, so you might want to check the size before you accept
+the string.
 
 As for encoding, it is possible to construct data structures that are
 relatively small but result in large CBOR texts (for example by having an
@@ -1151,10 +1154,10 @@
 =item Resource-starving attacks: CPU en-/decoding complexity
 
 CBOR::XS will use the L<Math::BigInt>, L<Math::BigFloat> and
-L<Math::BigRat> libraries to represent encode/decode bignums. These can
-be very slow (as in, centuries of CPU time) and can even crash your
-program (and are generally not very trustworthy). See the next section for
-details.
+L<Math::BigRat> libraries to represent encode/decode bignums. These can be
+very slow (as in, centuries of CPU time) and can even crash your program
+(and are generally not very trustworthy). See the next section on bignum
+security for details.
 
 =item Data breaches: leaking information in error messages