A lot of the Dockerfiles I write use the same template and tricks. I decided to write a ruby script to generate my Dockerfiles for me based on a minimal amount of input. I did this for a couple reasons:
I wanted my images to be as small as possible
I wanted consistent and readable Dockerfiles
I wanted to make it easy to update my images
I wanted all my images to be easy to port to the Raspberry Pi
One of the security concepts of Qubes is that all work is done in separate VMs. The “admin console” for the Xen hypervisor is known as dom0 and is responsible for managing the desktop environment. dom0 is never supposed to interact with the other VMs, usb devices, or the network.
However, when taking a screenshot, they are inevitably stored inside dom0. What can be done about this?
I have recently switched to Qubes OS and I really like it. It has some very handy tools that make working with a secure system seamless.
I decided I wanted to write about my setup and how to fix the minor problems I encountered.
As a test, this entire post was written using Qubes, as a way for me to prove to myself that I could still be productive and have an easy-to-use system while remaining secure.
The Singleton pattern is a design pattern that restricts the instantiation of a class to one object.
It is typically used for solving the problem of resource contention, such that you need to manage a single instance of a resource.
Singletons are misunderstood and difficult to implement correctly, hopefully this post can clear things up.
This post presents a lightweight generic object counter in C++. Object counters count the number of objects that have been created, as well as how many bytes they are utilizing.
They are a handy way to get a sense of application health programatically as well as detect memory leaks with unit tests.
C++11 introduced the possibility of “perfect forwarding” and “variadic templates”. This allows a function to pass all of its parameters to another function seamlessly. Such abilities are very useful for wrapper classes and factories.
Fortunately, this ability can be emulated in C++03 with the power of Boost and the preprocessor. This post is a guide on how to do parameter forwarding. This concept will be used as a tool in a future post about creating a generic factory class.
For this walkthrough, you will need the following installed:
To start, let’s define a simplistic factory class as an example. Our factory for this example will not do much, except return the built object as a smart pointer.
The problem with this is that it only supports building objects with the default constructor. Hence, we want to use parameter forwarding to pass parameters from the create method to the constructor of the object.
Thats better! Now that we know our code works, we can start to condense the pattern and let the preprocessor expand it out for us.
Boost::Preprocessor is a handy library that makes interacting with the preprocessor much easier. It introduces a bunch of macros and conventions that we can build upon to emulate features like variadic templates. And despite how it sounds, the final result is rather compact and readable.
First, lets identify the patterns we want to condense. The first is the template parameter list:
template<typename A0, typename A1>
Boost has a macro specifically designed for this purpose: BOOST_PP_ENUM_PARAMS. It takes in a number and some text, and replicates the text by appending increasing numbers. For example:
BOOST_PP_ENUM_PARAMS(3, typename A)
Outputs (using the preprocessor cpp main.cpp):
typename A0 , typename A1 , typename A2
Simply wrap the template brackets around this to achieve our first piece:
Remember that C++ does not care about whitespace. The preprocessor macros will tend to insert whitespace in odd places. Likewise, the preprocessor will output everything on one line without line breaks.
The second pattern we see is the function parameters:
BOOST_FWD_REF(A0) a0, BOOST_FWD_REF(A1) a1
This one is slightly trickier, because it doesn’t fit the above enumeration pattern. For this case, we will use a different macro: BOOST_PP_REPEAT. This macro operates by convention; it will repeat a specified macro N times as long as that macro takes arguments in a certain way. In addition, we will use BOOST_PP_CAT to concatenate strings together. By treating N as one of the strings, we can create an enumeration with the freedom of controlling the output format.
What is going on here? The (Z, N, D) represents state, number, and data, respectively. Boost uses this convention to pass around the “state” of the macro (analogous to how the this pointer is the implicit first parameter to any method call), the iteration value, and any extraneous data. For our case, we don’t need to pass any data into the macro, so we use the conventional placeholder ~ to denote “void”. On each call of our defined macro, N is updated with the iteration count, and we can concatenate that to the letters A and a to form our type and value.
But what about the commas? Boost has us covered here as well with BOOST_PP_COMMA:
Hmm, not quite. There is a trailing comma that we need to get rid of. I’ll admit that at this point I was pretty confused, until I learned the trick; Boost also provides BOOST_PP_COMMA_IF, which takes a condition argument and will only expand to a comma if the condition is not 0.
Here is the trick: Instead of trying to eliminate the trailing comma, prepend the comma!
It is always a good idea to undefine any macros you define after you are finished with them, since macros pollute the global namespace and you never know how they will interact with complex baselines.
There is one thing left to do; expand out the macro. Unsurprisingly, Boost also provides a way to do this. This method involves setting up a loop and iteratively calling #include on the result, which will cause the preprocessor to literally paste the results inline with the code:
Notice that the loop iterates from 1 to N, instead of starting at 0. This is because putting 0 in the template parameter expansion will result in template<>, and the compiler will interpret this as template specialization. To get around this, the “base case” for a default constructor is coded outside of the macro.
Sometimes you need to perform a task in a secure way that leaves no trace on your computer.
The traditional way of accomplishing this is to boot from a live CD like Tails.
The problem with this is that you might need the software, drivers, or setup you have on your main operating system to accomplish the task.
An example of this might be creating a Bitcoin Paper Wallet with a proprietary printer; it might be too difficult to set up the printer on a live CD for a one-off task.