Fine-tune the readme

Clean up the python2/python3 string type handling

Merge pull request #170 from kylemanna/travis-ci

Add Travis CI Support

Merge pull request #169 from kylemanna/python3

Add proper Python3 support to the generator

Setting version to 0.3.5-dev

Publishing nanopb-0.3.4

Add initialization to examples/simple

Merge pull request #171 from kylemanna/misc

decode: Fix compiler issue with gcc-5

decode: Fix compiler issue with gcc-5

* gcc 5.0 and 5.1 appear to take issue with this line and generates the
  following error:

    /home/nitro/tmp/nanopb/pb_decode.c: In function ‘pb_decode_noinit’:
    /home/nitro/tmp/nanopb/pb_decode.c:889:60: error: conversion to ‘uint8_t {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion]
                 fields_seen[iter.required_field_index >> 3] |= (uint8_t)(1 << (iter.required_field_index & 7));
                                                                ^
* This seems like a compiler bug, but this workaround is harmless.

travis-ci: Use protobuf v3 as it adds python3

* Still in testing currently.

travis-ci: Build C/C++/Python matrix

* Test a number of C compilers
* Travis CI can't handle three languages (C, C++, Python)
* Add support for swapping python2/3 binaries
* Scons has made no attempts to support python3 yet:
* Build the matrix manually
* Scons doesn't inherit $CC/$CXX from parent environement,
  so pass compiler flags directly

generator: Use search $PATH for python

* Search $PATH for the python binary so that this works better with
  things like virtualenv as used on Travis CI

travis-ci: Initial working build

* Initial working build for Travis CI build system.

generator: Fix strange unicode/str issue in python2

* Work around this by checking the appropriate class for the given
* environment.

generator: Attempt to simplify the str/unicode madness

* This is a shot in the dark.

generator: Strings are utf-8 by default in python3

* Not sure how to handle this case in python2, seems to work
* Python 3 doesn't need this since all strings are utf-8

generator: Remove cmp() to work with Python3

* Python3 ignores cmp() and __cmp__() and only needs __lt__() for
  sorting.  Delete and update as appropriate.
* Ref: https://docs.python.org/3.0/whatsnew/3.0.html#ordering-comparisons

generator: More exhaustive field size checking

Create a FieldMaxSize class that:
* Accumlates all C assertions
* Handles the checking of the longest simple field
* Also python3 doesn't support max(None)

generator: Use python2/3 binary read/write method

* This works with python2 and python3

generator: Run python's 2to3 converter

* Invoked with `2to3 -w nanopb_generator.py`
* No other changes.

cmake: Don't explicitly look for python2

* Use the system python binary and make sure the generator works with
  both instead.

generator: Don't force python2

Python2 is being phased out of the default python interpreter.  Arch
Linux has moved some time ago and upcoming Debian realeases will follow.

My distro, Arch, doesn't have a python2-protobuf version, but does have
a python3 version.  With a python 2 & 3 compatible generator the exact
interpreter can be ignored and can use the system default as most users
expect.

Update issue #155

Update changelog

Add syntax specification to .proto files (issue #167)

Eliminates a warning on protoc 3.0.

Fix maximum encoded size for negative enums (issue #166).

Make the generator understand included files (issue #165).

This will allow message sizes and enum options to be available
across the include files.

Currently searching for .options files for included files may
not work for all path combinations, this is related to issue #116.
Should probably make a pull request to protoc about that.

Refactor the generator logic into a ProtoFile class.

In preparation for multi-file support in generator.
No functional changes yet.

Expand the multiple_files test case to include oneofs and enums

Fix handling of unsigned 8- or 16-bit enums.

Previously unsigned enums would throw errors on decoding if the value
went outside the signed range (issue #164).

Currently only helps for enums defined within the same file, but solving
issue #165 will make it work for multiple files also.

Add testcase for issue #164

Add packed_enum option to generator.

This can be generally useful for saving RAM, but also makes
it easier to test for issue #164.

Add note about running tests on Mac OS X

Add link to forum to the readme

Merge pull request #157 from ivankravets/patch-1

Specify additional fields for @PlatformIO Registry

Specify additional fields for @PlatformIO Registry

Merge pull request #156 from ncolomer/master

PlatformIO Library Registry manifest file

PlatformIO Library Registry manifest file

Add download link to readme

Fix for previous (issue #155)

Prefer python2 in generator/protoc-gen-nanopb.

Update issue 155
Status: FixedInGit

Setting version to 0.3.4-dev

Publishing nanopb-0.3.3

Switch to .tar.gz format for Mac OS X packages.

Update issue 154
Status: FixedInGit

Fix problem with plugin options on Python 2.7.2 and older.

Update issue 153
Status: FixedInGit

Update changelog

Clear callbacks for union fields.

Update issue 148
Status: FixedInGit

Fix for test case build rules

Improve comment support in .options files.

Update issue 145
Status: FixedInGit

Always define enum long names so that cross-file references work.

Update issue 118
Status: FixedInGit

Add basic docs for msgid functionality

Generate #defines for plain message ids

Add simple test case for message ids

Use make_identifier() to create the name for FOO_MESSAGES define.

This handles special charaters like in "my-file.proto" properly.
Also use headerbasename instead of full path, so that compiling files
with relative path doesn't create symbols like FOO/BAR/BAZ_MESSAGES.

nanopb_generator.py: emit macros for msgid message type id use

nanopb.proto: add msgid message-level option

Fix oneof submessage initialization bug.

Update issue 149
Status: FixedInGit

Better error messages for syntax errors in .options file

Fix generator error when long_names:false is combined with Oneofs.

Update issue 147
Status: FixedInGit

Include libprotobuf in linux binary package.

Previously this got included by bbfreeze, but apparently no more.

Update issue 146
Status: FixedInGit

Lower required CMake version in example

Update cmake_simple example readme

Add simple example built with CMake

Fix search for Python 2 with CMake

Do not assume that Python has already been found by CMake. Fix value of
CMake variable PYTHON_EXECUTABLE if Python 3 was found. Change minimum
supported Python version to 2.6.

This fixes a bug introduced by this commit:
d8d3b75e2e3b348d016f48cebc1be764061975d2

Updates for the CMake rule file.

1) Search explicitly for python2.7

In systems where python3 is default or in build cases where the user has
already searched for and found python3 in CMake, store the python3
executable and search for python2.7.

2) Generate nanopb core protobuf files with CMake

Generate python output files used in turn by the nanopb generator
script. This removes the requirement of manually calling 'make' in the
nanopb/generator/proto directory.

3) Use nanopb options file if it exists

Look for nanopb options file and use in protobuf source and header
generation if it exists. The options file must have the same name and
path as the proto file, excluding the extension.

Fix generator bug when oneof is first field in a message.

Added test case for the same.

Update issue 142
Status: FixedInGit

Setting version to nanopb-0.3.3-dev

Publishing nanopb-0.3.2

Fix encoded_size #defines for oneof messages.

The sizes are represented as EncodedSize() instances, which cause
max() operation to sort them by address instead of value. This caused
pretty much random item to be selected for the maximum.

Update issue 141
Status: FixedInGit

Update changelog

Fix clang compiler warning in intsizes unit test.

Release memory when overwriting oneof fields.

Update issue 131
Status: FixedInGit

Add oneofs to AllTypes test case

Bugfixes for oneof support.

Fixes crashes / memory leaks when using pointer type fields.
Also fixes initialization of which_oneof fields.

New generator options for oneofs: allow skipping or generating as normal 'optional' fields.

The behaviour with no_unions:true is the same as of nanopb 0.3.1 and earlier.

Fix generator error with OneOfs

Allow using 8/16/32/64 as values in int_size setting

Actually make the protoc version check work

Only run oneof test when protoc >= 2.6 is available

Fix build failure

Implement support for oneofs (C unions).

Basic test included, should probably add an oneof to the AllTypes test also.

Update issue 131
Status: Started

Detect too large varint values when decoding.

Because Issue #139 now allows limiting integer fields, it is good
to check the values received from other protobuf libraries against
the lower limits.

Add int_size option for generator.

This allows overriding the integer field types to e.g. uint8_t for
saving RAM.

Update issue 139
Status: FixedInGit

Change PB_RETURN_ERROR() macro to avoid compiler warnings.

Update issue 140
Status: FixedInGit

Fix build failure due to missing dependency in SConscript

Fix memory leaks with PB_ENABLE_MALLOC and certain submessage type combinations.

There was a memory leak when:

1) A statically allocated submessage or
2) an extension field submessage

contained

A) a pointer-type field or
B) a submessage that further contained a pointer-type field.

This was because pb_release() didn't recurse into non-pointer fields.

Update issue 138
Status: FixedInGit

Initialize also extension fields to defaults in pb_decode().

This makes the behaviour more consistent with non-extension fields,
and also makes sure that all 'found' fields of extensions are initially
false.

Fix bug in backwards_compatibility test case.

The memset() filled also the extensions field, which was just
waiting for a crash to happen.

Add testcase for releasing memory in submessages/extensions

Add support for POINTER type in extensions

Include the field type in a comment for extension fields

Move malloc support to tests/common directory

Move malloc_wrappers.c to tests/common

Verify build with protobuf-3.0.0, fix problems.

Also updated descriptor.proto from protobuf-3.0.0.

Add compilation option to disable struct packing.

Update issue 136
Status: FixedInGit

Set version to nanopb-0.3.2-dev

Publishing nanopb-0.3.1

Update changelog

Add a fuzz testing stub for ability to use external generators also

Protect against size_t overflows in pb_dec_bytes/pb_dec_string.

Possible consequences of bug:
1) Denial of service by causing a crash
   Possible when all of the following apply:
      - Untrusted data is passed to pb_decode()
      - The top-level message contains a static string field as the first field.
   Causes a single write of '0' byte to 1 byte before the message struct.

2) Remote code execution
   Possible when all of the following apply:
      - 64-bit platform
      - The message or a submessage contains a static/pointer string field.
      - Decoding directly from a custom pb_istream_t
      - bytes_left on the stream is set to larger than 4 GB
   Causes a write of up to 4 GB of data past the string field.

3) Possible heap corruption or remote code execution
   Possible when all of the following apply:
      - less than 64-bit platform
      - The message or a submessage contains a pointer-type bytes field.
   Causes a write of sizeof(pb_size_t) bytes of data past a 0-byte long
   malloc()ed buffer. On many malloc() implementations, this causes at
   most a crash. However, remote code execution through a controlled jump
   cannot be ruled out.

--

Detailed analysis follows

In the following consideration, I define "platform bitness" as equal to
number of bits in size_t datatype. Therefore most 8-bit platforms are
regarded as 16-bit for the purposes of this discussion.

1. The overflow in pb_dec_string

The overflow happens in this computation:

uint32_t size;
size_t alloc_size;
alloc_size = size + 1;

There are two ways in which the overflow can occur: In the uint32_t
addition, or in the cast to size_t. This depends on the platform
bitness.

On 32- and 64-bit platforms, the size has to be UINT32_MAX for the
overflow to occur. In that case alloc_size will be 0.

On 16-bit platforms, overflow will happen whenever size is more than
UINT16_MAX, and resulting alloc_size is attacker controlled.

For static fields, the alloc_size value is just checked against the
field data size. For pointer fields, the alloc_size value is passed to
malloc(). End result in both cases is the same, the storage is 0 or
just a few bytes in length.

On 16-bit platforms, another overflow occurs in the call to pb_read(),
when passing the original size. An attacker will want the passed value
to be larger than the alloc_size, therefore the only reasonable choice
is to have size = UINT16_MAX and alloc_size = 0. Any larger multiple
will truncate to the same values.

At this point we have read atleast the tag and the string length of the
message, i.e. atleast 3 bytes. The maximum initial value for stream
bytes_left is SIZE_MAX, thus at this point at most SIZE_MAX-3 bytes are
remaining.

On 32-bit and 16-bit platforms this means that the size passed to
pb_read() is always larger than the number of remaining bytes. This
causes pb_read() to fail immediately, before reading any bytes.

On 64-bit platforms, it is possible for the bytes_left value to be set
to a value larger than UINT32_MAX, which is the wraparound point in
size calculation. In this case pb_read() will succeed and write up to 4
GB of attacker controlled data over the RAM that comes after the string
field.

On all platforms, there is an unconditional write of a terminating null
byte. Because the size of size_t typically reflects the size of the
processor address space, a write at UINT16_MAX or UINT32_MAX bytes
after the string field actually wraps back to before the string field.
Consequently, on 32-bit and 16-bit platforms, the bug causes a single
write of '0' byte at one byte before the string field.

If the string field is in the middle of a message, this will just
corrupt other data in the message struct. Because the message contents
is attacker controlled anyway, this is a non-issue. However, if the
string field is the first field in the top-level message, it can
corrupt other data on the stack/heap before it. Typically a single '0'
write at a location not controlled by attacker is enough only for a
denial-of-service attack.

When using pointer fields and malloc(), the attacker controlled
alloc_size will cause a 0-size allocation to happen. By the same logic
as before, on 32-bit and 16-bit platforms this causes a '0' byte write
only. On 64-bit platforms, however, it will again allow up to 4 GB of
malicious data to be written over memory, if the stream length allows
the read.

2. The overflow in pb_dec_bytes

This overflow happens in the PB_BYTES_ARRAY_T_ALLOCSIZE macro:

The computation is done in size_t data type this time. This means that
an overflow is possible only when n is larger than SIZE_MAX -
offsetof(..). The offsetof value in this case is equal to
sizeof(pb_size_t) bytes.

Because the incoming size value is limited to 32 bits, no overflow can
happen here on 64-bit platforms.

The size will be passed to pb_read(). Like before, on 32-bit and 16-bit
platforms the read will always fail before writing anything.

This leaves only the write of bdest->size as exploitable. On statically
allocated fields, the size field will always be allocated, regardless
of alloc_size. In this case, no buffer overflow is possible here, but
user code could possibly use the attacker controlled size value and
read past a buffer.

If the field is allocated through malloc(), this will allow a write of
sizeof(pb_size_t) attacker controlled bytes to past a 0-byte long
buffer. In typical malloc implementations, this will either fit in
unused alignment padding area, or cause a heap corruption and a crash.
Under very exceptional situation it could allow attacker to influence
the behaviour of malloc(), possibly jumping into an attacker-controlled
location and thus leading to remote code execution.

Add just-to-be-sure check to allocate_field().

This check will help to detect bugs earlier, and is quite lightweight
compared to malloc() anyway.