Skip to content

GitLab

I
iotivity-classic
Switch branch/tag
  1. 21 Nov, 2017 2 commits
  3. 20 Nov, 2017 2 commits
    • George Nash's avatar
      IOT-1375 Use mbedtls base64 implementation · 3b21b046
      George Nash authored 
      Maintaining only one copy is easier, and may have security
benefits since the input to base64 decode is often untrusted
input (e.g., a peer certificate).

Comparing the implementation of base64 from mbedtls the output
follows the rules specified in RFC 1521 for doing base64
encoding.

As best I can tell IoTivity's implementation follows the rules
specified in RFC 4648.

The major difference is that RFC 1521 has a limit on line length
of 76 characters. While RFC 4648 does not have the line length
limitation and will typically encode the data as one long
string.

Originally there was a lot of concern that if the base64 encoded
string were stored anywhere changing to the mbedtls
implementation could cause backward compatibility problems. For
that reason unit tests were added that encoded using IoTivity
base64 and decoded using mbedtls as well as encoding using
mbedtls and decoding base64. Both implementations were able to
handle data encoded by the other implementation.

JniSecureUtils::convertUUIDtoStr was removed after discovering it
was not use anywhere in the code.  Also there was no clear use case to convert a 128 bit UUID to a base64 string.

Bug: https://jira.iotivity.org/browse/IOT-1375
Change-Id: If7f178ff550c5d529452593ed7998a082ec1fab3
Signed-off-by: George Nash's avatarGeorge Nash <george.nash@intel.com>
      3b21b046
    • Philippe Coval's avatar
      build: Ship IPCA in Linux RPM · b7ef662e
      Philippe Coval authored 
      This was needed for fedora-24 for ARTIK7

Bug: https://jira.iotivity.org/browse/IOT-1745
Change-Id: I177a277a07a0684e58f5935b5785de50b3d78af1
Signed-off-by: default avatarPhilippe Coval <philippe.coval@osg.samsung.com>
      b7ef662e
  5. 18 Nov, 2017 5 commits
  7. 17 Nov, 2017 1 commit
  9. 15 Nov, 2017 2 commits
    • Mats Wichmann's avatar
      Continue improving libcoap build script · cd1cde97
      Mats Wichmann authored 
      * The variable-substitution section in building the coap.h
  config file (for the "upstream" version) not working, repaired.
* Move the coap.h comment down to where the work is done for
  easier reading.
* Use "with" statement for file handling (conventions)
* Clean up the glob handling to generate the file lists: use
  scons internal Glob.
* Save the correct coap path into a construction var LIBCOAP_INC.
  Other scripts will later be modified to use this, but as of
  this patch it has no active effect.

Along the way, found build script in plugins was using
WITH_UNFORKED_LIBCOAP (which is never set in the environment)
rather than WITH_UPSTREAM_LIBCOAP - this is adjusted.

Change-Id: I0398b440c5318516578426253a653024f3277fe4
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      cd1cde97
    • Mats Wichmann's avatar
      Improve on test/valgrind setup · 4176027f
      Mats Wichmann authored 
      Problem: when Jenkins runs the unit_test configuration on Linux,
it looks for files suffixed .xml in the top directory, but it
does not know where they come from, and in a multi-stage run (as
unit_test currently is), since the collection happens only at the
end, there can be some confusion about which results apply to the
"failure count".

As a first stage in cleanup, to avoid programmer errors when
calling run_tests, the filename for the valgrind run is now
generated from the pathname of the test.  Until further cleanup,
the passed filename is ignored and just used as a boolean (that
aspect was already documented - empty string meaning do not
use valgrind).

Whether or not valgrind runs happen was selected based on platform.
An environment flag is added to allow it to be turned of for
small-memory platforms, or for testing whether valgrind is adding
problems (that is, if unit tests fail, can try again with valgrind
disabled to help narrow down where the problem is).

As a note, to combat the "overwrite" effect when unit_test
builder runs non-secure followed by secure build+test, was
attempting to separate those two builds by putting them in
distinct paths, but apparently the path is computed other places
than build_common/SConscript.  android, darwin and tizen all found
some existing instance of the current path style even after it
was changed and so broke.  So as of this commit, this topic is
not addressed.

Change-Id: I57213dce98a9a0f8ced3a18e82d0a51691b024bd
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      4176027f
  11. 14 Nov, 2017 1 commit
  13. 13 Nov, 2017 1 commit
  15. 10 Nov, 2017 1 commit
    • Mats Wichmann's avatar
      Adapt gcc version-compare to deal with gcc7, py3 · 8cb1a53a
      Mats Wichmann authored 
      cherry-pick because this is causing problems for me.

For gcc starting with 7, gcc -dumpversion returns a single (non
dotted) number. This is actually an illegal version to distutils'
version.StrictVersion, so use LooseVersion instead, where that is a
legal number but the comparison still works fine.

For Python 3.x, subprocess.check_output returns a byte string,
which needs to be decoded before it can be passed to the version
comparator function. Instead of bothering with the decoder, which is
hard to get right so it works for both Py2 and Py3 case, call the new
subprocess.getoutput() method, falling back to check_output if not
available.

Change-Id: I29e1f43f8fbde130103099be1972b574a23442cf
Bug: https://jira.iotivity.org/browse/IOT-2862Signed-off-by: default avatarMats Wichmann <mats@linux.com>
(cherry picked from commit 754d84d2)
      8cb1a53a
  17. 09 Nov, 2017 1 commit
  19. 08 Nov, 2017 1 commit
    • Mats Wichmann's avatar
      Build gtest output paths correctly · 0d010e4b
      Mats Wichmann authored 
      Currently, when the run_tests function is called twice from the
the same scons script (that is, the script has more than one unit
test binary to register), the GTEST_OUTPUT environment variable
becomes malformed.  This is because the string to add is added
to a list instead of just being appended as a string.  The result
is that while all the test output binaries are expected to go to
BUILD_DIR/test_out, in these cases they go deep down underneath
that directory.  Here are the unexpected paths in an unmodified
testing run:

out/linux/x86_64/debug/test_out/:xml:
out/linux/x86_64/debug/test_out/:xml:/home
out/linux/x86_64/debug/test_out/:xml:/home/mats
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out/linux
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out/linux/x86_64
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out/linux/x86_64/debug
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out/linux/x86_64/debug/test_out
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out/linux/x86_64/debug/test_out/unittest.xml
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out/linux/x86_64/debug/test_out/stacktests.xml
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out/linux/x86_64/debug/test_out/cbortests.xml
out/linux/x86_64/debug/test_out/:xml:/home/mats/iotivity.work/out/linux/x86_64/debug/test_out/provisiontests.xml

The :xml: is intended as a tag used to signal gtest, it is never
supposed to be part of the real filesystem path.

Note fix was already proposed as part of
https://gerrit.iotivity.org/gerrit/#/c/22275/ but since it's a
distinct error with a very simple fix, wanted to get it pushed
through by itself while that one is under consideration.

Change-Id: I05c57d54034686a7c77c783eab758e7f501e86ea
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      0d010e4b
  21. 07 Nov, 2017 1 commit
    • Ibrahim Esmat's avatar
      Windows: Enable UWP to be built on master · 031a247d
      Ibrahim Esmat authored 
      If you are building for UWP, then you can't build and run a regular
desktop program/exe. Therefore, needed tools like json2cbor will
fail to run and the build will fail to generate the .dat files that
are needed.
- Change run.bat to build the win32 version of the security tool
(resource/csdk/security/tool) which will be copied to the uwp output
directory to use for the build.
- Change the security tool SConscript file to check for this when
building for UWP.

Change-Id: I2d83cdf3d78cc73a9e31be2741251d533c1ae93a
Signed-off-by: default avatarIbrahim Esmat <iesmat@microsoft.com>
      031a247d
  23. 06 Nov, 2017 1 commit
  25. 05 Nov, 2017 1 commit
    • Mats Wichmann's avatar
      builds: stop defeating Variant dir Part 2/3 · 0763dd6f
      Mats Wichmann authored 
      This intends to pick up only three stray misplaced files from resource/
which were actually also being built in normal sequence in the expected
places and added to their respective libraries there; thus the problem
was a reference from elsewhere in the tree - which turned out to be the
Zigbee wrapper. The files in question are oic_malloc.c, oic_string.c
and logger.c.  There are no executables built in this tree, only some
libraries.  In the original form these files are just built in to the
libraries as follows:

$ ar t out/linux/x86_64/debug/plugins/zigbee_wrapper/telegesis_wrapper/src/libtelegesis_wrapper.a
oic_string.o
logger.o
twsocketlist.o
telegesis_socket.o
telegesis_wrapper.o
$ ar t out/linux/x86_64/debug/plugins/zigbee_wrapper/src/libzigbee_wrapper.a
oic_malloc.o
logger.o
zigbee_wrapper.o
$ ar t out/linux/x86_64/debug/plugins/src/libplugin_interface.a
logger.o
pluginlist.o
plugininterface.o

Binaries should just get these interfaces by linking with libc_common
(for oic_string and oic_malloc) and liblogger (for logger). The unit
test here is the only binary built, and it doesn't seem to need either.

Meanwhile, all the build scripts in plugins were cleaned up a bit.
They now use the SCons #-at-start-of-string reference to refer to
the top of the tree, instead of fetching saved src_dir and joining it
to paths, and a bit of other cleanup also done.

Bug: https://jira.iotivity.org/browse/IOT-1745
Change-Id: I01d95a757aea8e955fd5af4951e1ba3ad52228d3
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      0763dd6f
  27. 03 Nov, 2017 1 commit
  29. 31 Oct, 2017 1 commit
  31. 30 Oct, 2017 1 commit
  33. 28 Oct, 2017 1 commit
  35. 26 Oct, 2017 1 commit
    • Rami Alshafi's avatar
      [IOT-2837] Enable IoTivity build on Raspbery pi · 7bf01477
      Rami Alshafi authored 
      cherry-pick from 1.3-rel

The default arch for the raspberry pi board is either armv6l or
armv7l depending on board hardware version. Neither of them are
included in the valid values for the TARGET_ARCH build option.
The current workaround is to pass TARGET_ARCH=arm to the build
command. This change will enable the default arch.

Change-Id: I7f07734f5e06d79d13275254fb01f924227e229a
Signed-off-by: default avatarRami Alshafi <ralshafi@vprime.com>
(cherry picked from commit 7ee4eee5)
      7bf01477
  37. 25 Oct, 2017 7 commits
    • George Nash's avatar
      IOT-2838 Fix javadoc warnings · 5cfded4d
      George Nash authored 
      Documented all the functions referencing the native code.

Note the OcProvisioning setPinType method had a return value
int. The was returning the return value of the native call
that was the status. Due to the way the code was writen the
only value that could be returned was when things worked as
expected. All other values were thrown so the return value
was un-needed. The function was changed to have a return type
of void.

Bug:https://jira.iotivity.org/browse/IOT-2838
Change-Id: I3b5955a336661574dde9f70c87b6ead3dcd5ea7b
Signed-off-by: George Nash's avatarGeorge Nash <george.nash@intel.com>
      5cfded4d
    • George Nash's avatar
      IOT-2539 Enable the -Werror build flag · 418ccc66
      George Nash authored 
      The coding standard states:
Code must compile with no warnings. Without flags
forcing warnings off.
see:
https://wiki.iotivity.org/iotivity_c_coding_standards

Its possible that using an untested version of gcc could
result in build warings that are not yet fixed. For this
reason the build option ERROR_ON_WARN was added to make
it possible to turn off the -Werror flag. This should
only be used locally an not changed on the CI build.

Due to some bugs in older version of gcc some warnings
are forced off when using an older version of gcc.

This change will force code to follow the coding
standard of building with no warnings.

The coapHttpParser code produces a build warning
that currently is not solved. When building the
coap_http_proxy library the -Werror build flag is
removed.

Don't use the -Werror build option for extlib yaml
code.

Don't use the -Werror build option for coap library

Change-Id: Ifcc25ed7e5b8637ac4383a7bfa51ace105ed9458
Signed-off-by: George Nash's avatarGeorge Nash <george.nash@intel.com>
      418ccc66
    • Mats Wichmann's avatar
      Update security .dat files · 58592f94
      Mats Wichmann authored 
      After recent changes to either the json2cbor tool or to the source
security files, the checked-in .dat files no longer match what
is being generated. Check in the ones that show changes.

Change-Id: I78a1e3032057261630f54b8dc608863c1b6dc216
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      58592f94
    • Mats Wichmann's avatar
      Changes to support Python 3 · 223a1449
      Mats Wichmann authored 
      SCons 3 works with Python 3.x.  Try to eliminate places where the
scons scripts don't work with Py3.  The most "interesting" one is that
subprocess calls to run an external system command do not return a
string, so if we need to do "if substring in string" type queries on
the subprocess return, we need to call a decoder method to turn it into
a string. SCons provides SCons.Util.to_String for this purpose.

Also on strings, there is no longer a 'string_escape' encoder, Py3
strings are unicode so 'unicode_escape' is available. This is handled
with a try block.

Another change is in lambda usage: Python 3 abolished tuple argument
unpacking, and since lambdas only take a single argument usages which
look like multiple arguments (but are actually a tuple), this has an
effect in a couple of places.  The 2to3 tool suggested the changes here.

The local imports in build_common/iotivityconfig were changed to use
the relative-import syntax (a preceding dot). This has been around for
a long time, so causes no problem for Python 2 (in since 2.4).

Python 3 eliminates the cmp method, so the call to sort the help
message by argument name generated a syntax error.  It turns out
the sort named argument can also take a boolean value (undocumented;
scons3 docs will fix that for next release), so instead set sort=True.

Change-Id: I0582e99a83f6ca5246dc566727c0b04b5ed4199b
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      223a1449
    • Mats Wichmann's avatar
      build: variant-dir fix in IPCA · b39469d1
      Mats Wichmann authored 
      One more place turned up where build happens in src dir instead of
in variant dir, which impacts parallel builds of different flavors.
It seems that placing a source file from another part of the
project into the source list defeats the variant dir.  This proposal
takes it out and linked to the library it appears in instead.

Change-Id: I73283fb854fd899e5609017f2bb8a52fc8c00675
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      b39469d1
    • Ashok Babu Channa's avatar
      Merge "Merge branch '1.3-rel' (9cff3985) into 'master'" · 7126aa1b
      Ashok Babu Channa authored
      7126aa1b
    • Nathan Heldt-Sheller's avatar
      [IOT-2830] add PSK callback logging · b1659ae0
      Nathan Heldt-Sheller authored 
      See JIRA IOT-2830 for more information.

Change-Id: If043f6705ccdede4630b469c13e1933a2b53af16
Signed-off-by: Nathan Heldt-Sheller's avatarNathan Heldt-Sheller <nathan.heldt-sheller@intel.com>
      b1659ae0
  39. 24 Oct, 2017 3 commits
  41. 23 Oct, 2017 4 commits
  43. 21 Oct, 2017 1 commit