[Tor-BSD] Call for BSD Tor Packagers
George Rosamond
george at ceetonetechnology.com
Wed Oct 26 21:21:53 EDT 2016
On 10/26/16 12:56, nusenu wrote:
>>> since you are the OpenBSD tor maintainer, would you like to get
>>> pre-release information in case of upcoming security fixes in tor?
>>
>> I suppose this was a follow-up to what I posted on tor-relays@ about
>> MTier having delays on net/tor updates in OpenBSD.
>
> No my email is unrelated to that. I just routed teor's email to Pascal.
> (From the timeline on openports.se one can see that there has never been
> a big delay between release and port update)
Yes, and pascal@ sent this to the OpenBSD ports list 20161019, so I
think he's in the loop. Although I still see:
Update candidates: tor-0.2.7.6p1 -> tor-0.2.7.6p1
...when updating 6.0 stable ports:
> Patch below fixes https://trac.torproject.org/projects/tor/ticket/20384
> for 6.0-stable. Tested on powerpc.
>
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/net/tor/Makefile,v
> retrieving revision 1.90
> diff -u -p -r1.90 Makefile
> --- Makefile 18 May 2016 10:14:07 -0000 1.90
> +++ Makefile 19 Oct 2016 12:16:44 -0000
> @@ -5,7 +5,7 @@ COMMENT= anonymity service using onion r
> DISTNAME= tor-0.2.7.6
> CATEGORIES= net
> HOMEPAGE= https://www.torproject.org/
> -REVISION= 1
> +REVISION= 2
>
> MAINTAINER= Pascal Stumpf <pascal at stumpf.co>
>
> Index: patches/patch-src_or_buffers_c
> ===================================================================
> RCS file: patches/patch-src_or_buffers_c
> diff -N patches/patch-src_or_buffers_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_or_buffers_c 19 Oct 2016 12:16:44 -0000
> @@ -0,0 +1,86 @@
> +$OpenBSD$
> +
> +From: Nick Mathewson <nickm at torproject.org>
> +Date: Fri, 14 Oct 2016 09:38:12 -0400
> +Subject: [PATCH] Add a one-word sentinel value of 0x0 at the end of each buf_t
> + chunk
> +
> +This helps protect against bugs where any part of a buf_t's memory
> +is passed to a function that expects a NUL-terminated input.
> +
> +It also closes TROVE-2016-10-001 (aka bug 20384).
> +
> +--- src/or/buffers.c.orig Fri Nov 13 14:33:26 2015
> ++++ src/or/buffers.c Wed Oct 19 13:52:55 2016
> +@@ -69,13 +69,34 @@ static int parse_socks_client(const uint8_t *data, siz
> +
> + #define CHUNK_HEADER_LEN STRUCT_OFFSET(chunk_t, mem[0])
> +
> ++/* We leave this many NUL bytes at the end of the buffer. */
> ++#define SENTINEL_LEN 4
> ++
> ++/* Header size plus NUL bytes at the end */
> ++#define CHUNK_OVERHEAD (CHUNK_HEADER_LEN + SENTINEL_LEN)
> ++
> + /** Return the number of bytes needed to allocate a chunk to hold
> + * <b>memlen</b> bytes. */
> +-#define CHUNK_ALLOC_SIZE(memlen) (CHUNK_HEADER_LEN + (memlen))
> ++#define CHUNK_ALLOC_SIZE(memlen) (CHUNK_OVERHEAD + (memlen))
> + /** Return the number of usable bytes in a chunk allocated with
> + * malloc(<b>memlen</b>). */
> +-#define CHUNK_SIZE_WITH_ALLOC(memlen) ((memlen) - CHUNK_HEADER_LEN)
> ++#define CHUNK_SIZE_WITH_ALLOC(memlen) ((memlen) - CHUNK_OVERHEAD)
> +
> ++#define DEBUG_SENTINEL
> ++
> ++#ifdef DEBUG_SENTINEL
> ++#define DBG_S(s) s
> ++#else
> ++#define DBG_S(s) (void)0
> ++#endif
> ++
> ++#define CHUNK_SET_SENTINEL(chunk, alloclen) do { \
> ++ uint8_t *a = (uint8_t*) &(chunk)->mem[(chunk)->memlen]; \
> ++ DBG_S(uint8_t *b = &((uint8_t*)(chunk))[(alloclen)-SENTINEL_LEN]); \
> ++ DBG_S(tor_assert(a == b)); \
> ++ memset(a,0,SENTINEL_LEN); \
> ++ } while (0)
> ++
> + /** Return the next character in <b>chunk</b> onto which data can be appended.
> + * If the chunk is full, this might be off the end of chunk->mem. */
> + static INLINE char *
> +@@ -131,6 +152,7 @@ chunk_new_with_alloc_size(size_t alloc)
> + ch->memlen = CHUNK_SIZE_WITH_ALLOC(alloc);
> + total_bytes_allocated_in_chunks += alloc;
> + ch->data = &ch->mem[0];
> ++ CHUNK_SET_SENTINEL(ch, alloc);
> + return ch;
> + }
> +
> +@@ -140,18 +162,20 @@ static INLINE chunk_t *
> + chunk_grow(chunk_t *chunk, size_t sz)
> + {
> + off_t offset;
> +- size_t memlen_orig = chunk->memlen;
> ++ const size_t memlen_orig = chunk->memlen;
> ++ const size_t orig_alloc = CHUNK_ALLOC_SIZE(memlen_orig);
> ++ const size_t new_alloc = CHUNK_ALLOC_SIZE(sz);
> + tor_assert(sz > chunk->memlen);
> + offset = chunk->data - chunk->mem;
> +- chunk = tor_realloc(chunk, CHUNK_ALLOC_SIZE(sz));
> ++ chunk = tor_realloc(chunk, new_alloc);
> + chunk->memlen = sz;
> + chunk->data = chunk->mem + offset;
> + #ifdef DEBUG_CHUNK_ALLOC
> +- tor_assert(chunk->DBG_alloc == CHUNK_ALLOC_SIZE(memlen_orig));
> +- chunk->DBG_alloc = CHUNK_ALLOC_SIZE(sz);
> ++ tor_assert(chunk->DBG_alloc == orig_alloc);
> ++ chunk->DBG_alloc = new_alloc;
> + #endif
> +- total_bytes_allocated_in_chunks +=
> +- CHUNK_ALLOC_SIZE(sz) - CHUNK_ALLOC_SIZE(memlen_orig);
> ++ total_bytes_allocated_in_chunks += new_alloc - orig_alloc;
> ++ CHUNK_SET_SENTINEL(chunk, new_alloc);
> + return chunk;
> + }
> +
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20161026/227547b1/attachment.bin>
More information about the Tor-BSD
mailing list