I use SIP in MapsEvolved to generate bindings for interfacing Python
with C++. I really like SIP due to its straight-forward syntax that mostly
allows just copying class definitions over from C++. Further, it's really
well thought out and contains support for a number of advanced use cases.

One such feature is implementing a C++ interface in Python. The resulting class
can then even be passed back to C++, and any methods called on it will be
forwarded to the Python implementation. Sweet!

Here, the C++ function visit_graph_nodes() calls the Python method
pnv.OnNode() for every node in its (internal) graph. A zip file with the full
working source code of this example can be downloaded
here.

The subclassing capabilities of SIP don't stop at interfaces, either. It's
possible to derive from any C++ class, abstract or not, inheriting (or
overriding) existing method implementations as needed. This gives a lot of
flexibility and makes it easy to have classes with some parts implemented
in C++, and others being in Python.

Configuring a modern web server to employ strong encryption and forward secrecy
doesn't have to be hard. There is excellent documentation from Mozilla and
from the OWASP.

Obtaining an SSL certificate

One major stumbling block is where to obtain an SSL certificate. In the
future, this should hopefully be easy with Let's Encrypt. Until that is
actually functional, StartSSL offers free SSL certificates. The process
takes a bit of patience, but it's not difficult. There's also a StartSSL
HOWTO from h-online.com.

While I've used StartSSL in the past, I had some trouble with them because 10
years after I registered greek0.net, someone grabbed greekO.net and
StartSSL was alleging I was trying to mislead users?! So that was the end of
my business with them...

The process of getting the cert from them was super easy, simpler than
StartSSL. About 3 hours from going to their website to having the certificate
installed on my server, with most of it waiting email verifications. Credit
card payment was quick and easy. 10/10, would buy again :-)

Apache configuration

With the certificate acquisition out of the way, here are the juicy bits from
my Apache config.

mod_ssl config:

# Enable only cyphers that support forward secrecy.# See these two links for reference:# https://stackoverflow.com/questions/17308690# https://wiki.mozilla.org/Security/Server_Side_TLS#Non-Backward_Compatible_CiphersuiteSSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
# Use server priorities for cipher algorithm choice.SSLHonorCipherOrderon# With Apache 2.4, SSLv2 is gone and only SSLv3 and TLSv* are supported.# Disable SSLv3, all TLS protocols are OK.SSLProtocolall -SSLv3
# Enable OCSP stapling# With this, the client can verify that our certificate isn't revoked# without having to query an external OCSP service.SSLUseStaplingOnSSLStaplingCache shmcb:${APACHE_RUN_DIR}/ssl_stapling(32768)

The per-site configuration:

SSLEngineOnSSLCertificateKeyFile/path/to/serverkey.key # The private server key.
SSLCertificateFile/path/to/certificate.crt # The certificate provided by CA.
SSLCertificateChainFile/path/to/cert-bundle # A separate download from your CA.
# Use a customized prime group for DH key exchange (vs Logjam attack).# Generate a DH group file with:# openssl dhparam -out dhparams.pem 2048## Newer Apache versions support the following command to set the dhparams:SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"# If Apache reports an error for the above line, remove it and include# the dhparams in the certificate:# cat <CERT>.crt dhparams.pem > cert-with-dhparams.crt# SSLCertificateFile cert-with-dhparams.crt# HSTS: Force browsers to require SSL for this domain for the next year.# Down-grade to HTTP will cause browsers to abort with a security error.Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"# HPKP: Pin the current key for the next two months.# Generate hash using:# openssl rsa -in <serverkey>.key -outform der -pubout | \# openssl dgst -sha256 -binary | openssl enc -base64## You ideally want to generate a backup key and include that here as well,# in case the primary key is lost or compromised.# Also note the implications for key rollover.# See: https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_PinningHeader always set Public-Key-Pins "pin-sha256=\"<HASH>\"; max-age=5184000; includeSubDomains"# Disable compression to avoid BREACH HTTPS/SSL attack.<Location/>SetEnv no-gzip
</Location>

That should cover the basics.

Testing

As for SSL connection testing, I found the Qualys SSL Labs Test helpful.
It shows what browsers (browser versions) will get which
encryption quality (forward secrecy or not) and highlights common problems such
as certificate chain issues.

Docker doesn't delete old/unused images or containers by itself, even if they
weren't used for a long time or were only intermediary steps on the way to
another image. This leads to an image sprawl that eats up a lot of disk space
if not kept in check.

The right way to solve this would be to parse the output of docker inspect and
remove containers and images based on certain policies. Unfortunately, a quick
internet search did not turn up a script that does this.

Since I didn't want to spend the time to write such a thing myself, I resorted
to what – sadly – seems to be state-of-the-art docker image management: a
cronjob running those two lines:

The first line removes containers that are older than two weeks and are not
currently running (docker rm simply will not remove running containers).
The second line removes images that are not used by any container and are not
tagged (i.e. don't have proper repository name).

Docker is a virtualization solution that's been gaining a lot of momentum
over the last few years. It focuses on light-weight, ephemeral containers that
can be created based on simple config files.

Docker's main target platform is amd64, but it also works on x86. However,
practically all official container images in the Docker registry are amd64
based, which means they can't be used on an x86 machine. So, it's necessary to
manually create the required base images. As you might have guessed, my server
runs Docker on x86, so I've had to find a solution for that problem.

Fortunately, creating images from scratch is really easy with the mkimage.sh
script that comes bundled with Docker. On Debian systems, its installed in
/usr/share/docker.io/contrib/mkimage.sh, on Fedora it has to be
obtained from the Docker git repository:

This command will create a minimal Debian Jessie image using Debootstrap,
and import it into Docker with the name debootstrap/minbase. Further options
can set a specific Debian mirror server and a list of additional packages to
install:

mkimage.sh has backends to bootstrap Arch Linux, Busybox, Centos, Mageia, and
Ubuntu. Fedora images doesn't seem to be supported directly, but they can be
generated by following
instructions
compiled by James Labocki.

Finally, it's worth mentioning that this should only be used to generate
base images. You'd then use Docker itself (cf. Dockerfile) to create images
that actually do something interesting, based on these base images. This will
save both time and memory, due to Docker's caching and copy-on-write mechanisms.

I bought my Samsung Galaxy S2 in 2011, and it's still going strong. It really
was a great phone for the time and held up incredibly well. Unfortunately,
Samsung's support has ended long ago, and users are stranded with an obsolete
(and insecure) firmware.

Fortunately, CyanogenMod still provides relatively recent images for the
device. As of this writing, snapshots of CM11 (based on Android 4.4) are
available, but there are no images of CM12.

Here is how I flashed CM11 to my phone. This is based on the official
CyanogenMod wiki page for the SGS2 and on this
xda-developers post. Since you can brick your phone if you don't
know what you are doing, I suggest reading both of these pages.
Note that you will need to factory-reset your phone, so backup all
your data (files, apps, SMS, contacts, ...).

All the following steps have to be performed on a root shell on Linux.

To start from a clean slate, create a new Debian Jessie chroot (you may need to
install debootstrap first). Don't use LXC/Docker/VMWare here, you need raw
hardware access:

Disconnect the USB cable and hold POWER until the phone shuts down. Reboot into
recovery (VOLUP + HOME + POWER, let go of POWER after 5 seconds or
you'll trigger a reboot). Then reconnect the USB cable.

Again, in recovery, select "install from zip files", first install the CM
image, then the GApps package. Select "reboot" to boot into CyanogenMod. Shut
down again, reboot into recovery, wipe cache and perform factory reset, reboot
into CM (avoid factory reset with stock kernel due to the "super brick"
problem).

Done. You should now have a not-so-shiny-anymore Galaxy S2 running a
new-and-shiny CyanogenMod 11. Enjoy :-)