1. 21 Nov, 2017 2 commits
  2. 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
  3. 18 Nov, 2017 5 commits
  4. 17 Nov, 2017 1 commit
  5. 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
  6. 14 Nov, 2017 1 commit
  7. 13 Nov, 2017 1 commit
  8. 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
  9. 09 Nov, 2017 1 commit
  10. 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
  11. 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
  12. 06 Nov, 2017 1 commit
  13. 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
  14. 03 Nov, 2017 1 commit
  15. 31 Oct, 2017 1 commit
  16. 30 Oct, 2017 1 commit
  17. 28 Oct, 2017 1 commit
  18. 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
  19. 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
    • 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
  20. 24 Oct, 2017 3 commits
  21. 23 Oct, 2017 4 commits
  22. 21 Oct, 2017 1 commit