Shadowsocks-Qt 3.0

Happy 2018! Shadowsocks-Qt5 3.0 and libQtShadowsocks 2.0 have now been marked as stable and released!

For people who are not familiar with Shadowsocks, it is a lightweight secure SOCKS5 proxy initially developed in China to circumvent the great firewall. I’ve been developing and maintaining the Qt/C++ implementation of this protocol for quite some time. By protocol, it means you can mix and match different implementations (or so called ports in some context) of Shadowsocks. A popular setup is to use shadowsocks-libev as the server, while using the Android app or shadowsocks-windows, shadowsocks-qt5 as desktop clients.

Back to today’s business, after a long and painful period of refactoring and cleaning, I’m happy to announce that the new major update of Shadowsocks-Qt5 and libQtShadowsocks have finally come! The highlights are:

  1. Full support of Shadowsocks AEAD ciphers (requires botan >= 2.3.0)
  2. Full support of Shadowsocks SIP004 URI scheme, which is widely used by other clients for QR code
  3. Complete migration to CMake build system
  4. A compiler that supports C++14 is required (e.g. GCC >= 4.9)

Meanwhile, some of you may also notice a few changes to the project. I will no longer maintain any binary packages except for Fedora and AppImage. Right, that means not even Windows binaries are provided. I had a lot of difficulties compiling all the dependencies and linking them statically on Windows. As for Ubuntu PPA, I don’t use Ubuntu and it makes little sense for me, a non-Ubuntu user, to maintain it since I can’t even test. Time is also part of the reason why I’ve made this decision so that I can focus on coding.

Since I did mention AppImage, yes, this is an exciting new way to try out Shadowsocks-Qt5 on your Linux machines. Especially if you want to use AEAD ciphers since most Linux distributions don’t ship Botan-2, why not downloading the AppImage file and give it a go? It has bundled the latest version of Qt and Botan libraries as of writing.

Before I finish this post, I’d like to mention a few things that I probably will do later in this year (this is not a promise):

  1. Moving further away from Qt libraries in libQtShadowsocks, more and more C++11 and C++14 features will be used instead. The ultimate goal (in the far future) might be to create a “libShadowsocks++” project that doesn’t depend on Qt at all (the alternative for networking library can be asio)
  2. Finish the plug-in support proposed in SIP003
  3. Replace the dependency zbar with something more modern
Advertisements

Shadowsocks-Qt5 AppImage

Applications on Linux tend to be distributed by distributions, managed/packaged by distribution’s package managers. For upstream application developers, one way to ship the software to users is to create binary packages for mainstream Linux distributions. Don’t get me wrong, it is not too difficult, given we’ve now had Launchpad for Ubuntu, Copr for Fedora, OBS for OpenSUSE. Arch Linux has AUR, although that is just recipe collection.

By chance, I’ve seen Krita is shipping their software using AppImage. My attention was drawn over immediately. It looks very promising, given how many upstream apps are packaged in AppImage and how easy-to-use it is. The best part is that AppImage doesn’t require any tools (unlike flatpak which needs OS support). It basically acts similarly to the way how people ship applications on macOS, in bundles! Hence, there you go, my journey to pack Shadowsocks-Qt5 in AppImage.

Since you can easily find well documented procedures in their Wiki pages, I won’t bother logging it step by step but only a few hiccups I got. The tool I’m using is linuxdeployqt along with the vanilla AppImageKit. Both tools are distributed in AppImage format, how convenient! 🙂

As recommended, you should use a relatively old Linux distribution to make your AppImage file as compatible as possible (apps linked against newer GLIBC won’t be able to run with older GLIBC). I’ve chosen Debian Jessie as the host OS which has very similar software suite as Ubuntu Trusty does (so I can use Travis CI in the future to automate AppImage build).

One hiccup I got was a symbol error from libharfbuzz.so, see this issue. After a few days Googling, I found a similar issue which points to freetype and harfbuzz themselves. So I just tried to remove libfreetype.so and libharfbuzz.so from appdir directory, and packed with appimagetool, voila it works! I have to point out that linuxdeployqt will always try to put those necessary libraries into appdir when you use it to pack AppImage. In the end, I had to replace the last step with vanilla appimagetool. In another words, what I did was

linuxdeployqt ./appdir/usr/share/applications/shadowsocks-qt5.desktop -bundle-non-qt-libs
rm -f ./appdir/usr/lib/libharfbuzz.so.0
rm -f ./appdir/usr/lib/libfreetype.so.6
appimagetool ./appdir

An experimental AppImage file has been uploaded to the releases page, please give it try, especially if your Linux distribution doesn’t have Shadowsocks-Qt5 in the repository.

qmake_qt5 macro in rpm spec

I got “Empty %files file /blah_blah_blah/debugfiles.list” errors when I package the same RPMs since I had upgraded my laptop from Fedora 23 to Fedora 24.

A quick Google redirected me into this old mail list. The hint is very important, which reads

That’s an indication that you build with “wrong” compiler flags, which don’t generate debug information in the binaries.

It then turns out there is a hidden macro %{qmake_qt5} that passes correct compiler flags and all those magic arguments. I found out this by checking out Qupzilla’s official spec file on Fedora.

I’m not 100% sure why calling qmake-qt5 directly was OK on pre-F24 systems (RHEL 7, Fedora 21 to Fedora 23). But it’s very likely that the necessary compiler flags that used to be included in global qmake.conf are now gone.

I can also confirm that this macro, %{qmake_qt5}, works on RHEL 7, Fedora 22 and Fedora 23.