(released on 14.12.2017)
Unsurprisingly, 0.9.5 came out eventually. Today.2017-09-14 20:25:28
Themis 0.9.4 is out now!2016-11-22 18:09:17
Themis 0.9.3 is released!2016-05-24 16:59:33
TL;DR: OpenSSL 1.1 support.
- Significant update of the Contributing section in Wiki.
- Removed support for Ubuntu Precise.
.rpmpackage versioning (#240).
- Added a handy command for preparing and running of all the tests
- Added small changes and updates into Makefile to make it even better and fixed the installing dependencies (#236, #239, #250).
- added OpenSSL 1.1 support (#208).
- Android wrapper:
- fixed Secure Cell in token protect mode (#251);
- fixed casting warnings in JNI code (#246).
- iOS wrapper:
- updated wrapper to be compatible with Swift4 (#230);
- added nullability support (#255);
- made the NSError autoreleasing (#257, #259) from @valeriyvan;
- fixed warnings that appeared due to renaming
- updated and refactored tests (#231, #232).
- added compatibility with old Go (1.2) (#253);
- fixed tests (#261).
- fixed installation path for macOS (#237, #238).
- fixed compatibility with version 0.9.5 (#241), pushed as a separate package 0.9.5.1.
Mostly usability fixes for wrappers.
- You can now download pre-built Themis packages from our package server.
- Enhanced building process for MacOS (working now!) (https://github.com/cossacklabs/themis/issues/215).
- Enhanced building process for Debian 9.x (working even better now!).
- Updated documentation and examples to make it easier to understand.
- Now we use Bitrise as a separate CI for iOS wrapper.
- Test and code coverage are automagically measured now!
- Core: disabled SHA1 support.
- Secure Comparator: magically improved code readability (https://github.com/cossacklabs/themis/issues/196, https://github.com/cossacklabs/themis/issues/195).
- iOS wrapper: added support of dynamic frameworks and bitcode (https://github.com/cossacklabs/themis/issues/222, https://github.com/cossacklabs/themis/issues/219, https://github.com/cossacklabs/themis/issues/205).
- Go wrapper: refactored custom error (
- PHP wrapper: updated tests.
- PyThemis: considerably improved example projects.
This is tiny intermediary release to lock ongoing changes in stable form for all languages:
- BoringSSL support on Android and Linux
- Fixed some leaks and code styling problems (thanks to @bryongloden)
- Memory management updates for stability in languages, which rely on sloppy GC
- Fix Themis build errors under certain conditions
- Secure Comparator examples for many languages
- Swift3 support + numerous enhancements from @valeriyvan, thanks a lot!
- GoThemis: fixed rare behavior in Secure Session wrapper
- GoThemis examples
- JsThemis syntax corrections and style fixes
- JsThemis Nan usage to enhance compatibility
- More and better Themis Server examples
- Enhanced error messages (now with proper spelling!)
- Corrections for RD_Themis
Updating podspec to be compatible with CocoaPods 1.0
74b8b8d6ba83bcba...2018-12-12 14:08:17 ilammy
Ignore ldconfig failures when installing on Linux (#346) * Ignore ldconfig failures when installing on Linux Currently `make install PREFIX=$HOME/lib/themis` fails on Linux when run without superuser privileges. Installation to non-system directories should not require superuser privileges. This does not work because of an unconditional `ldconfig` invocation. Linux systems generally require an `ldconfig` invocation after installing shared libraries in order to refresh ld.so's library cache. Themis' "make install" target does that unconditionally when building on Linux. It's not necessary for static libraries or when installing into non-system locations that require special configuration of the dynamic loader (rpath, LD_LIBRATY_PATH, etc.) Note that `ldconfig` requires superuser privileges as it writes multiple files in /etc. However, "make install" is not always run with superuser privileges. There are two basic use-cases for installing Themis: - Installation into the system directory Typically this is used when packaging Themis library by itself. This installation requires superuser privileges anyway to copy the libraries into system locations. Usually shared libraries are installed together with static libraries. This is typically invoked as `sudo make install` - Installation into a temporary directory Typically this is used to build a local copy of Themis for use inside another project. Themis is installed into some non-system location by setting the PREFIX variable accordingly. Usually only static libraries are used. No superuser privileges needed. This is typically invoked as `make install PREFIX=$somewhere` The first use-case works fine now, but the second one is broken by `ldconfig` failing the build without superuser privileges. Let's fix it in a simple and lazy way by ignoring any errors caused by `ldconfig`. (They are still printed out to stderr though.) Strictly speaking, we should invoke `ldconfig` only after installing shared libraries. And it's only needed when installing into system locations. However, it's too complex for us to analyze EUID and PREFIX values. And it's certainly easier for the users to simply run "make install" all the time. Though, it's definitely possible to add a new target which will not call `ldconfig`: install_static: install_soter_headers install_themis_headers \ install_static_libs install_pkgconfig install: install_static install_shared_libs ifdef IS_LINUX @ldconfig endif However, there may be cases when shared libraries need to be installed into non-system locations as well. So it should be more easy to simply ignore `ldconfig` failures. * Ignore ldconfig failures only for non-root users Actually, do check that we are running as root by looking at our EUID. If we're a non-root user then ignore ldconfig failures. Otherwise exit with the status code returned by ldconfig and propagate the error.
bbfa9f40990a2a8e...2018-11-26 23:13:46 ilammy
Install pkg-config files (#343) * Install pkg-config files pkg-config is an amazing tool for locating installed libraries and generating linkage information. It makes it trivial to link any program to a library. In the simplest case of a C program building with make one just adds these lines to their Makefile: CFLAGS += $(pkg-config --cflags libthemis) LDFLAGS += $(pkg-config --libs libthemis) And it just works. No need for CMake to probe for libraries, etc. pkg-config is also able to generate correct flags for static linkage. Static linkage is not trivial because of transitive dependencies. For example, when linking to Themis dynamically it is sufficient to add just `-lthemis` to linker's command line. However, for static linkage one needs to tell `-static -lthemis -lsoter -lcrypto`, explicitly including Soter (dependency of Themis) and SomethingSSL (dependency of Soter) into the command line. pkg-config tracks library dependencies and outputs correct flags as necessary. Output of pkg-config is pretty straighforward so it may be used not only via directly embedding into makefiles for C programs, but by other ecosystems as well. It provides a consistent way to locate native libraries, portable across all major operating systems (yes, pkg-config is available on Windows as well). Therefore it would be nice for Themis to include *.pc files for its libraries. Each library binary should have its own pkg-config file. These files are usually installed into "pkgconfig" directory under the "lib" directory with library binaries. System directories like /usr/lib/pkgconfig and /usr/local/lib/pkgconfig are usually in the default search path of pkg-config. The *.pc files are installed during "make install" phase and are included into DEB and RPM packages. We generate *.pc files during the build to include the PREFIX value and version information there. For Soter we also include the exact library set that's used by the selected cryptographic engine. It's different for OpenSSL/LibreSSL and BoringSSL. Note that for OpenSSL we could have used `Requires` directive as OpenSSL is usually available via pkg-config as "libcrypto". However, Themis build system does not use pkg-config to locate OpenSSL so we do not rely on pkg-config for resolving dependencies. This is actually important for builds on macOS with Homebrew which should ensure that Homebrew's OpenSSL is used which is not present in the default search path of pkg-config. Also note that we do not include CFLAGS for Soter. That's because Soter public header files do *not* expose the dependency on OpenSSL which is really good design and separation of concerns, promoting stability of Soter's ABI. We use sed to perform template substitution. It's good enough (until someone tries using exclamation marks `!` in their paths, but let's not think about those weirdos). Note that we use shell pipes, not `-i` flag of sed. That's because `-i` is actually GNU sed specific, BSD systems usually do not have it. * Make sure the output directory exists BIN_PATH is normally created when building object files (grep "$(@D)" in Makefiles), but *.pc files do not have any dependencies and thus make decides to build these targets early. Well, create the output directories early then.
0761eb4a69635efc...2018-11-26 21:11:49 ilammy
Use Bash as shell in Makefile (#345) This issue has been bugging me for a while and I was finally triggered enough to do something about it. If one runs make on macOS then "echo" ignores the "-n" flag which suppresses newline output. Then instead of a nice output: link soter_static [OK] link themis_static [OK] link soter_shared [OK] link themis_shared [OK] 0.10.0 one sees the following monstrosity: -n link soter_static [OK] -n link themis_static [OK] -n link soter_shared [OK] -n link themis_shared [OK] 0.10.0 This is caused by multitude of factors. First of all, GNU make uses /bin/sh by default to execute shell commands. This can be overridden by setting the SHELL make variable (*environment* variable is ignored). Usually on UNIX systems /bin/sh is a symlink or a drop-in replacement to some 'maximally portable POSIX shell' which resembles the original Bourne shell. On macOS /bin/sh is renamed Bash binary. I believe some other UNIX systems do so as well. When Bash is invoked as "sh" it enables Bourne shell compatibility mode: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. -- man 1 bash "echo" is normally a shell built-in (so that the shell does not execute actual /bin/echo all the time), so its options are determined by the shell and its compatibility mode. The "-n" option is supported by Bash and by most of echo binaries, but not by Bourne shell's echo builtin. So, set SHELL to Bash in order to have nice behavior of the "echo" builtin. A more correct way would be to disable the builtin and make sure that the shell runs /bin/echo, but that's much harder to do. This can be offensive towards POSIX compatibility purists, but if they run Themis builds on a system where Bash is not available they can comment out that line and get their /bin/sh back. While we're gonna enjoy nice progress reports with correct newlines.
161e544869e5d439...2018-11-02 14:25:36 secumod
Fix themis_gen_rsa_key_pair return logic (#335) * Fix themis_gen_rsa_key_pair return logic The function is "overoptimised": even if the private key export fails with "buffer too small", the overall return value will be success because of the incorrect return logic. Make the logic same as in themis_gen_key_pair, which works. * Add missing ctx NULL check in themis_gen_rsa_key_pair
1a86f536ee2be3c3...2018-11-01 22:20:51 secumod
soter: make sure we have the RSA private key before trying to decrypt data (#334) Some OpenSSL versions do not handle gracefully, when you try to do RSA decryption with a public key (no private part in the RSA structure) and just crash the whole process. So we add an explicit check we have the private part before attempting the decryption.