Petter Reinholdtsen: Public Trusted Timestamping services for everyone
Did you ever need to store logs or other files in a way that would
allow it to be used as evidence in court, and needed a way to
demonstrate without reasonable doubt that the file had not been
changed since it was created? Or, did you ever need to document that
a given document was received at some point in time, like some
archived document or the answer to an exam, and not changed after it
was received? The problem in these settings is to remove the need to
trust yourself and your computers, while still being able to prove
that a file is the same as it was at some given time in the past.
A solution to these problems is to have a trusted third party
"stamp" the document and verify that at some given time the document
looked a given way. Such
notarius service
have been around for thousands of years, and its digital equivalent is
called a
trusted
timestamping service. The Internet
Engineering Task Force standardised how such service could work a
few years ago as RFC
3161. The mechanism is simple. Create a hash of the file in
question, send it to a trusted third party which add a time stamp to
the hash and sign the result with its private key, and send back the
signed hash + timestamp. Both email, FTP and HTTP can be used to
request such signature, depending on what is provided by the service
used. Anyone with the document and the signature can then verify that
the document matches the signature by creating their own hash and
checking the signature using the trusted third party public key.
There are several commercial services around providing such
timestamping. A quick search for
"rfc 3161
service" pointed me to at least
DigiStamp,
Quo
Vadis,
Global Sign
and Global
Trust Finder. The system work as long as the private key of the
trusted third party is not compromised.
But as far as I can tell, there are very few public trusted
timestamp services available for everyone. I've been looking for one
for a while now. But yesterday I found one over at
Deutches
Forschungsnetz mentioned in
a
blog by David M ller. I then found
a
good recipe on how to use the service over at the University of
Greifswald.
The OpenSSL library contain
both server and tools to use and set up your own signing service. See
the ts(1SSL), tsget(1SSL) manual pages for more details. The
following shell script demonstrate how to extract a signed timestamp
for any file on the disk in a Debian environment:
#!/bin/sh
set -e
url="http://zeitstempel.dfn.de"
caurl="https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt"
reqfile=$(mktemp -t tmp.XXXXXXXXXX.tsq)
resfile=$(mktemp -t tmp.XXXXXXXXXX.tsr)
cafile=chain.txt
if [ ! -f $cafile ] ; then
wget -O $cafile "$caurl"
fi
openssl ts -query -data "$1" -cert tee "$reqfile" \
/usr/lib/ssl/misc/tsget -h "$url" -o "$resfile"
openssl ts -reply -in "$resfile" -text 1>&2
openssl ts -verify -data "$1" -in "$resfile" -CAfile "$cafile" 1>&2
base64 < "$resfile"
rm "$reqfile" "$resfile"
There was quite the torrential downpour overnight. It woke me up, and it woke
Zoe up too, and at about 1:45am she ended up in bed with me. I think she
managed to invent a new 
As you can see the configuration also includes a launch script. This script ensures that slaves are set up as needed (provide all the packages and scripts that are required for building) and always get the latest configuration and scripts before starting to serve as Jenkins slave.
Now your setup should be ready for launching Jenkins slaves as needed:
NOTE: you can use the Instance Cap configuration inside the advanced Amazon EC2 Jenkins configuration section to place an upward limit to the number of EC2 instances that Jenkins may launch. This can be useful for avoiding surprises in your AWS invoices. 
Notice though that the cap numbers are calculated for all your running EC2 instances, so be aware if you have further machines running under your account, you might want to e.g. further restrict your IAM policy then.
Reduce build time
Using a plain Debian AMI and automatically installing jenkins-debian-glue and further jenkins-debian-glue-buildenv* packages on each slave startup would work but it takes time. That s why we created our own AMI which is nothing else than an official Debian AMI with the 
I was awarded the 
More information
* 
Core Rendering with Glamor
I ve hacked up the intel driver to bypass all of the UXA paths
when Glamor is enabled so I m currently running an X server that uses
only Glamor for all rendering. There are still too many fall backs, and
performance for some operations is not what I d like, but it s
entirely usable. It supports DRI3, so I even have GL applications
running.
Core Rendering Status
I ve continued to focus on getting the core X protocol rendering
operations complete and correct; those remain a critical part of many
X applications and are a poor match for GL. At this point, I ve got
accelerated versions of the basic spans functions, filled rectangles,
text and copies.
GL and Scrolling
OpenGL has been on a many-year vendetta against one of the most common
2D accelerated operations copying data within the same object, even
when that operation overlaps itself. This used to be the most
performance-critical operation in X; it was used for scrolling your
terminal windows and when moving windows around on the screen.
Reviewing the OpenGL 3.x spec, Eric and I both read the glCopyPixels
specification as clearly requiring correct semantics for overlapping
copy operations it says that the operation must be equivalent to
reading the pixels and then writing the pixels. My CopyArea
acceleration thus uses this path for the self-copy case. However, the
ARB decided that having a well defined blt operation was too nice to
the users, so the current 4.4 specification adds explicit language to
assert that this is not well defined anymore (even in the face of the
existing language which is pretty darn unambiguous).
I suspect we ll end up creating an extension that offers what we need
here; applications are unlikely to stop scrolling stuff around, and
GPUs (at least Intel) will continue to do what we want. This is the
kind of thing that makes GL maddening for 2D graphics the GPU does
what we want, and the GL doesn t let us get at it.
For implementations not capable of supporting the required semantic,
someone will presumably need to write code that creates a temporary
copy of the data.
PBOs for fall backs
For operations which Glamor can t manage, we need to fall back to
using a software solution. Direct-to-hardware acceleration
architectures do this by simply mapping the underlying GPU object to
the CPU. GL doesn t provide this access, and it s probably a good
thing as such access needs to be carefully synchronized with GPU
access, and attempting to access tiled GPU objects with the CPU
require either piles of CPU code to de-tile accesses (ala wfb), or
special hardware detilers (like the Intel GTT).
However, GL does provide a fairly nice abstraction called pixel buffer
objects (PBOs) which work to speed access to GPU data from the CPU.
The fallback code allocates a PBO for each relevant X drawable, asks
GL to copy pixels in, and then calls fb, with the drawable now
referencing the temporary buffer. On the way back out, any potentially
modified pixels are copied back through GL and the PBOs are freed.
This turns out to be dramatically faster than malloc ing temporary
buffers as it allows the GL to allocate memory that it likes, and for
it to manage the data upload and buffer destruction asynchronously.
Because X pixmaps can contain many X windows (the root pixmap being
the most obvious example), they are often significantly larger than
the actual rendering target area. As an optimization, the code only
copies data from the relevant area of the pixmap, saving considerable
time as a result. There s even an interface which further restricts
that to a subset of the target drawable which the Composite
function uses.
Using Scissoring for Clipping
The GL scissor operation provides a single clipping rectangle. X
provides a list of rectangles to clip to. There are two obvious ways
to perform clipping here either perform all clipping in software,
or hand each X clipping rectangle in turn to GL and re-execute the
entire rendering operation for each rectangle.
You d think that the former plan would be the obvious choice; clearly
re-executing the entire rendering operation potentially many times is
going to take a lot of time in the GPU.
However, the reality is that most X drawing occurs under a single
clipping rectangle. Accelerating this common case by using the
hardware clipper provides enough benefit that we definitely want to
use it when it works. We could duplicate all of the rendering paths
and perform CPU-based clipping when the number of rectangles was above
some threshold, but the additional code complexity isn t obviously
worth the effort, given how infrequently it will be used. So I haven t
bothered. Most operations look like this:
Installing fresh hot 
