April 2017 - tor-commits - lists.torproject.org

[tor/master] Test odd-sized base64 decodes
by nickm＠torproject.org 10 Apr '17

10 Apr '17

commit 00ffefb41bc63d17ff68b7af2c9e8253715c12f3 Author: Taylor Yu <catalyst(a)torproject.org> Date: Fri Apr 7 16:33:22 2017 -0400 Test odd-sized base64 decodes Test base64_decode() with odd sized decoded lengths, including unpadded encodings and padded encodings with "right-sized" output buffers. Convert calls to base64_decode_nopad() to base64_decode() because base64_decode_nopad() is redundant. --- src/test/test_crypto.c | 2 +- src/test/test_util_format.c | 32 +++++++++++++++++++------------- 2 files changed, 20 insertions(+), 14 deletions(-) diff --git a/src/test/test_crypto.c b/src/test/test_crypto.c index 7a20150..ec9d4e2 100644 --- a/src/test/test_crypto.c +++ b/src/test/test_crypto.c @@ -1470,7 +1470,7 @@ test_crypto_formats(void *arg) tt_int_op(i, OP_GE, 0); tt_int_op(i, OP_EQ, strlen(data2)); tt_assert(! strchr(data2, '=')); - j = base64_decode_nopad((uint8_t*)data3, 1024, data2, i); + j = base64_decode(data3, 1024, data2, i); tt_int_op(j, OP_EQ, idx); tt_mem_op(data3,OP_EQ, data1, idx); } diff --git a/src/test/test_util_format.c b/src/test/test_util_format.c index 96ebada..dd52e4b 100644 --- a/src/test/test_util_format.c +++ b/src/test/test_util_format.c @@ -133,48 +133,54 @@ test_util_format_base64_encode(void *ignored) } static void -test_util_format_base64_decode_nopad(void *ignored) +test_util_format_base64_decode_oddsize(void *ignored) { (void)ignored; int res; int i; char *src; - uint8_t *dst, *real_dst; - uint8_t expected[] = {0x65, 0x78, 0x61, 0x6D, 0x70, 0x6C, 0x65}; + char *dst, real_dst[7]; + char expected[] = {0x65, 0x78, 0x61, 0x6D, 0x70, 0x6C, 0x65}; char real_src[] = "ZXhhbXBsZQ"; + char expected40[] = "testing40characteroddsizebase64encoding!"; + char src40[] = "dGVzdGluZzQwY2hhcmFjdGVyb2Rkc2l6ZWJhc2U2NGVuY29kaW5nIQ"; + char pad40[] = "dGVzdGluZzQwY2hhcmFjdGVyb2Rkc2l6ZWJhc2U2NGVuY29kaW5nIQ=="; src = tor_malloc_zero(256); dst = tor_malloc_zero(1000); - real_dst = tor_malloc_zero(10); for (i=0;i<256;i++) { src[i] = (char)i; } - res = base64_decode_nopad(dst, 1, src, SIZE_T_CEILING); - tt_int_op(res, OP_EQ, -1); - - res = base64_decode_nopad(dst, 1, src, 5); + res = base64_decode(dst, 1, src, 5); tt_int_op(res, OP_EQ, -1); const char *s = "SGVsbG8gd29ybGQ"; - res = base64_decode_nopad(dst, 1000, s, strlen(s)); + res = base64_decode(dst, 1000, s, strlen(s)); tt_int_op(res, OP_EQ, 11); tt_mem_op(dst, OP_EQ, "Hello world", 11); s = "T3BhIG11bmRv"; - res = base64_decode_nopad(dst, 9, s, strlen(s)); + res = base64_decode(dst, 9, s, strlen(s)); tt_int_op(res, OP_EQ, 9); tt_mem_op(dst, OP_EQ, "Opa mundo", 9); - res = base64_decode_nopad(real_dst, 10, real_src, 10); + res = base64_decode(real_dst, sizeof(real_dst), real_src, 10); tt_int_op(res, OP_EQ, 7); tt_mem_op(real_dst, OP_EQ, expected, 7); + res = base64_decode(dst, 40, src40, strlen(src40)); + tt_int_op(res, OP_EQ, 40); + tt_mem_op(dst, OP_EQ, expected40, 40); + + res = base64_decode(dst, 40, pad40, strlen(pad40)); + tt_int_op(res, OP_EQ, 40); + tt_mem_op(dst, OP_EQ, expected40, 40); + done: tor_free(src); tor_free(dst); - tor_free(real_dst); } static void @@ -402,7 +408,7 @@ struct testcase_t util_format_tests[] = { { "unaligned_accessors", test_util_format_unaligned_accessors, 0, NULL, NULL }, { "base64_encode", test_util_format_base64_encode, 0, NULL, NULL }, - { "base64_decode_nopad", test_util_format_base64_decode_nopad, 0, + { "base64_decode_oddsize", test_util_format_base64_decode_oddsize, 0, NULL, NULL }, { "base64_decode", test_util_format_base64_decode, 0, NULL, NULL }, { "base16_decode", test_util_format_base16_decode, 0, NULL, NULL },

1 0

[tor/master] Make base64_decode() check actual decoded length
by nickm＠torproject.org 10 Apr '17

10 Apr '17

commit f15818f280a6773e41b45a1a45cdb749ce7d611b Author: Taylor Yu <catalyst(a)torproject.org> Date: Fri Apr 7 16:01:40 2017 -0400 Make base64_decode() check actual decoded length base64_decode() was applying an overly conservative check on the output buffer length that could incorrectly produce an error if the input encoding contained padding or newlines. Fix this by checking the output buffer length against the actual decoded length produced during decoding. --- src/common/util_format.c | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/src/common/util_format.c b/src/common/util_format.c index 6e614e9..1033d14 100644 --- a/src/common/util_format.c +++ b/src/common/util_format.c @@ -395,15 +395,9 @@ base64_decode(char *dest, size_t destlen, const char *src, size_t srclen) const char *eos = src+srclen; uint32_t n=0; int n_idx=0; - char *dest_orig = dest; + size_t di = 0; - /* Max number of bits == srclen*6. - * Number of bytes required to hold all bits == (srclen*6)/8. - * Yes, we want to round down: anything that hangs over the end of a - * byte is padding. */ - if (!size_mul_check(srclen, 3) || destlen < (srclen*3)/4) - return -1; - if (destlen > SIZE_T_CEILING) + if (destlen > INT_MAX) return -1; /* Make sure we leave no uninitialized data in the destination buffer. */ @@ -431,9 +425,11 @@ base64_decode(char *dest, size_t destlen, const char *src, size_t srclen) n = (n<<6) | v; if ((++n_idx) == 4) { /* We've accumulated 24 bits in n. Flush them. */ - *dest++ = (n>>16); - *dest++ = (n>>8) & 0xff; - *dest++ = (n) & 0xff; + if (destlen < 3 || di > destlen - 3) + return -1; + dest[di++] = (n>>16); + dest[di++] = (n>>8) & 0xff; + dest[di++] = (n) & 0xff; n_idx = 0; n = 0; } @@ -451,18 +447,21 @@ base64_decode(char *dest, size_t destlen, const char *src, size_t srclen) return -1; case 2: /* 12 leftover bits: The last 4 are padding and the first 8 are data. */ - *dest++ = n >> 4; + if (destlen < 1 || di > destlen - 1) + return -1; + dest[di++] = n >> 4; break; case 3: /* 18 leftover bits: The last 2 are padding and the first 16 are data. */ - *dest++ = n >> 10; - *dest++ = n >> 2; + if (destlen < 2 || di > destlen - 2) + return -1; + dest[di++] = n >> 10; + dest[di++] = n >> 2; } - tor_assert((dest-dest_orig) <= (ssize_t)destlen); - tor_assert((dest-dest_orig) <= INT_MAX); + tor_assert(di <= destlen); - return (int)(dest-dest_orig); + return (int)di; } #undef X #undef SP

1 0

[tor/master] changes file for 17868
by nickm＠torproject.org 10 Apr '17

10 Apr '17

commit aebd72a2f07dbbc102c58639b399451342c4e3ac Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 10 11:27:41 2017 -0400 changes file for 17868 --- changes/17868 | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/changes/17868 b/changes/17868 new file mode 100644 index 0000000..77a8ba1 --- /dev/null +++ b/changes/17868 @@ -0,0 +1,4 @@ + o Code simplification and refactoring: + - Our base64 decoding functions no longer overestimate the output + space that they will need when parsing unpadded inputs. + Closes ticket 17868.

1 0

[tor/master] Remove base64_decode_nopad()
by nickm＠torproject.org 10 Apr '17

10 Apr '17

commit 2b38bb28b470dbca322ae64b7c5eaef9cd7206fa Author: Taylor Yu <catalyst(a)torproject.org> Date: Fri Apr 7 17:54:50 2017 -0400 Remove base64_decode_nopad() Remove base64_decode_nopad() because it is redundant now that base64_decode() correctly handles both padded and unpadded base64 encodings with "right-sized" output buffers. --- src/common/util_format.c | 33 --------------------------------- src/common/util_format.h | 2 -- 2 files changed, 35 deletions(-) diff --git a/src/common/util_format.c b/src/common/util_format.c index 1033d14..1f7b8b0 100644 --- a/src/common/util_format.c +++ b/src/common/util_format.c @@ -313,39 +313,6 @@ base64_encode_nopad(char *dest, size_t destlen, return (int)(out - dest); } -/** As base64_decode, but do not require any padding on the input */ -int -base64_decode_nopad(uint8_t *dest, size_t destlen, - const char *src, size_t srclen) -{ - if (srclen > SIZE_T_CEILING - 4) - return -1; - char *buf = tor_malloc(srclen + 4); - memcpy(buf, src, srclen+1); - size_t buflen; - switch (srclen % 4) - { - case 0: - default: - buflen = srclen; - break; - case 1: - tor_free(buf); - return -1; - case 2: - memcpy(buf+srclen, "==", 3); - buflen = srclen + 2; - break; - case 3: - memcpy(buf+srclen, "=", 2); - buflen = srclen + 1; - break; - } - int n = base64_decode((char*)dest, destlen, buf, buflen); - tor_free(buf); - return n; -} - #undef BASE64_OPENSSL_LINELEN /** @{ */ diff --git a/src/common/util_format.h b/src/common/util_format.h index c928052..adf48c0 100644 --- a/src/common/util_format.h +++ b/src/common/util_format.h @@ -37,8 +37,6 @@ int base64_encode(char *dest, size_t destlen, const char *src, size_t srclen, int base64_decode(char *dest, size_t destlen, const char *src, size_t srclen); int base64_encode_nopad(char *dest, size_t destlen, const uint8_t *src, size_t srclen); -int base64_decode_nopad(uint8_t *dest, size_t destlen, - const char *src, size_t srclen); /** Characters that can appear (case-insensitively) in a base32 encoding. */ #define BASE32_CHARS "abcdefghijklmnopqrstuvwxyz234567"

1 0

[tor/master] Remove SR_COMMIT_LEN workaround
by nickm＠torproject.org 10 Apr '17

10 Apr '17

commit 26dd4d92cfac7a201607caf280accec1b2d7d897 Author: Taylor Yu <catalyst(a)torproject.org> Date: Fri Apr 7 18:06:13 2017 -0400 Remove SR_COMMIT_LEN workaround Now that base64_decode() checks the destination buffer length against the actual number of bytes as they're produced, shared_random.c no longer needs the "SR_COMMIT_LEN+2" workaround. --- src/or/shared_random.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/src/or/shared_random.c b/src/or/shared_random.c index 73b4c1d..25ca061 100644 --- a/src/or/shared_random.c +++ b/src/or/shared_random.c @@ -230,9 +230,7 @@ commit_decode(const char *encoded, sr_commit_t *commit) { int decoded_len = 0; size_t offset = 0; - /* XXX: Needs two extra bytes for the base64 decode calculation matches - * the binary length once decoded. #17868. */ - char b64_decoded[SR_COMMIT_LEN + 2]; + char b64_decoded[SR_COMMIT_LEN]; tor_assert(encoded); tor_assert(commit); @@ -284,9 +282,7 @@ STATIC int reveal_decode(const char *encoded, sr_commit_t *commit) { int decoded_len = 0; - /* XXX: Needs two extra bytes for the base64 decode calculation matches - * the binary length once decoded. #17868. */ - char b64_decoded[SR_REVEAL_LEN + 2]; + char b64_decoded[SR_REVEAL_LEN]; tor_assert(encoded); tor_assert(commit);

1 0

[torspec/master] Prop #278: Describe backwards compatibility for directory servers.
by ahf＠torproject.org 10 Apr '17

10 Apr '17

commit 7401488308ec5de485cdf745199c3ed87dfd930a Author: Alexander Færøy <ahf(a)torproject.org> Date: Fri Apr 7 13:18:44 2017 +0200 Prop #278: Describe backwards compatibility for directory servers. --- proposals/278-directory-compression-scheme-negotiation.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/278-directory-compression-scheme-negotiation.txt b/proposals/278-directory-compression-scheme-negotiation.txt index 93bb4ef..b1f2808 100644 --- a/proposals/278-directory-compression-scheme-negotiation.txt +++ b/proposals/278-directory-compression-scheme-negotiation.txt @@ -120,6 +120,12 @@ Target: N/A using zlib deflate without any prior knowledge of the newly added compression schemes. + If a directory server receives a request to a document with the ".z" + suffix, where the client does not include an "Accept-Encoding" header, + the server should respond with the zlib compressed version of the + document for backwards compatibility with client that does not support + this proposal. + The "Content-Length" header contains the number of compressed bytes sent to the client.

1 0

[torspec/master] Prop #278: Prefix our encoding with "x-" and use LZMA2 instead of xz.
by ahf＠torproject.org 10 Apr '17

10 Apr '17

commit 2dfdc83b11f5b13356ec137a56ab760373676396 Author: Alexander Færøy <ahf(a)torproject.org> Date: Thu Apr 6 20:15:58 2017 +0200 Prop #278: Prefix our encoding with "x-" and use LZMA2 instead of xz. --- proposals/278-directory-compression-scheme-negotiation.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/278-directory-compression-scheme-negotiation.txt b/proposals/278-directory-compression-scheme-negotiation.txt index 4deef3e..93bb4ef 100644 --- a/proposals/278-directory-compression-scheme-negotiation.txt +++ b/proposals/278-directory-compression-scheme-negotiation.txt @@ -85,7 +85,7 @@ Target: N/A For example: GET / HTTP/1.0 - Accept-Encoding: zstd, xz, gzip, deflate + Accept-Encoding: x-zstd, x-lzma2, gzip, deflate When a directory server receives a request with the "Accept-Encoding" header included it must decide on a mutually supported compression @@ -100,11 +100,11 @@ Target: N/A HTTP/1.0 200 OK Content-Length: 1337 Connection: close - Content-Encoding: zstd + Content-Encoding: x-zstd Currently supported compression scheme names includes "identity", "gzip", and "deflate". This proposal adds two additional compression - scheme named "xz" (LZMA2) and "zstd" (Zstandard). + scheme named "x-lzma2" (LZMA2) and "x-zstd" (Zstandard). All compression scheme names are case-insensitive.

1 0

[torspec/master] Prop #278: Be explicit about handling both ".z"-suffixes and "plaintext" files.
by ahf＠torproject.org 10 Apr '17

10 Apr '17

commit c512794f54894b75f3fea0b07a2d5ffc81f3be96 Author: Alexander Færøy <ahf(a)torproject.org> Date: Fri Apr 7 13:19:23 2017 +0200 Prop #278: Be explicit about handling both ".z"-suffixes and "plaintext" files. --- proposals/278-directory-compression-scheme-negotiation.txt | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/proposals/278-directory-compression-scheme-negotiation.txt b/proposals/278-directory-compression-scheme-negotiation.txt index b1f2808..b62c69a 100644 --- a/proposals/278-directory-compression-scheme-negotiation.txt +++ b/proposals/278-directory-compression-scheme-negotiation.txt @@ -88,12 +88,14 @@ Target: N/A Accept-Encoding: x-zstd, x-lzma2, gzip, deflate When a directory server receives a request with the "Accept-Encoding" - header included it must decide on a mutually supported compression - scheme and add the "Content-Encoding" header to its response and thus - notifying the client of its decision. The "Content-Encoding" header - can at most contain one supported compression scheme. If no mutual - compression scheme can be negotiated the server must respond with an - HTTP error status code of 415 "Unsupported Media Type". + header included, to either the ".z" compressed or the uncompressed + version of any given document, it must decide on a mutually supported + compression scheme and add the "Content-Encoding" header to its + response and thus notifying the client of its decision. The + "Content-Encoding" header can at most contain one supported + compression scheme. If no mutual compression scheme can be negotiated + the server must respond with an HTTP error status code of 415 + "Unsupported Media Type". For example:

1 0

[webwml/staging] Add a line break for gpg verify instruction on linux
by hiro＠torproject.org 10 Apr '17

10 Apr '17

commit 657e2ec9abee5be5d7fc2b149125d4fceafd2c2a Author: hiromipaw <hiro(a)torproject.org> Date: Mon Apr 10 14:39:00 2017 +0200 Add a line break for gpg verify instruction on linux --- docs/en/verifying-signatures.wml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/verifying-signatures.wml b/docs/en/verifying-signatures.wml index d019139..485e509 100644 --- a/docs/en/verifying-signatures.wml +++ b/docs/en/verifying-signatures.wml @@ -154,7 +154,7 @@ <pre>gpg --verify ~/Downloads/TorBrowser-<version-torbrowserbundleosx64>-osx64_en-US.dmg{.asc*,}</pre> For Linux users (change 64 to 32 if you have the 32-bit package): - <pre>gpg --verify tor-browser-linux64-<version-torbrowserbundlelinux64>_en-US.tar.xz.asc + <pre>gpg --verify tor-browser-linux64-<version-torbrowserbundlelinux64>_en-US.tar.xz.asc \ tor-browser-linux64-<version-torbrowserbundlelinux64>_en-US.tar.xz</pre> The output should say "Good signature":

1 0

[webwml/master] Make 64bit instructions default for Linux on signature verification page
by hiro＠torproject.org 10 Apr '17

10 Apr '17

commit 39e3fe0954986998952207df909cf289d10cef2e Author: hiromipaw <hiro(a)torproject.org> Date: Mon Apr 10 14:28:23 2017 +0200 Make 64bit instructions default for Linux on signature verification page --- docs/en/verifying-signatures.wml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/en/verifying-signatures.wml b/docs/en/verifying-signatures.wml index 1db3fd9..d019139 100644 --- a/docs/en/verifying-signatures.wml +++ b/docs/en/verifying-signatures.wml @@ -153,9 +153,9 @@ For Mac OS X users: <pre>gpg --verify ~/Downloads/TorBrowser-<version-torbrowserbundleosx64>-osx64_en-US.dmg{.asc*,}</pre> - For Linux users (change 32 to 64 if you have the 64-bit package): - <pre>gpg --verify tor-browser-linux32-<version-torbrowserbundlelinux32>_en-US.tar.xz.asc - tor-browser-linux32-<version-torbrowserbundlelinux32>_en-US.tar.xz</pre> + For Linux users (change 64 to 32 if you have the 32-bit package): + <pre>gpg --verify tor-browser-linux64-<version-torbrowserbundlelinux64>_en-US.tar.xz.asc + tor-browser-linux64-<version-torbrowserbundlelinux64>_en-US.tar.xz</pre> The output should say "Good signature": @@ -214,8 +214,8 @@ file, and the <tt>sha256sums-unsigned-build.txt.asc</tt> signature file. They can all be found in the same directory under <a href="https://www.torproject.org/dist/torbrowser/"> - https://www.torproject.org/dist/torbrowser/</a>, for example in '<version-torbrowserbundlelinux32>' - for Tor Browser <version-torbrowserbundlelinux32>.</li> + https://www.torproject.org/dist/torbrowser/</a>, for example in '<version-torbrowserbundlelinux64>' + for Tor Browser <version-torbrowserbundlelinux64>.</li> <li>In case your operating system is adding the .txt extension automatically to the SHA256 sums signature file strip it again by running <pre>mv sha256sums-unsigned-build.txt.asc.txt sha256sums-unsigned-build.txt.asc</pre>

1 0