The project I work on uses X509 certificates with custom extensions to manage content access on the Red Hat CDN. The basic idea is that Candlepin issues X509 certificates with an extension saying what content the certificate is good for. Client systems then use that certificate for TLS client authentication when connecting to the CDN. If the content they are requesting (deduced from the request URL) matches the content available to them in the certificate, then access is granted.
This system works well in practice except for one problem: every time content for a particular product changes, the content data in the X509 extension becomes obsolete. We have to revoke the obsolete certificates and issue new ones. The result is an extremely large certificate revocation list (CRL).
For our cryptography needs, Candlepin uses the venerable Legion of the Bouncy Castle Java library. This library anticipates normal CRL usage so when building a CRL object from an existing file, the entire structure is read into memory at once. This approach doesn’t scale well with the numbers of revoked certificates we are dealing with, so we needed to devise a way to stream the CRL. Moreover, the only thing we really care about for our purposes is the revoked certificate’s serial number.
Streaming the CRL means we need to dissect the ASN1 that describes the CRL one piece at a time. RFC 5280 to the rescue! Looking at the description of the ASN1 for a CRL reveals that before the sequence containing the revocation entries, there will be a thisUpdate
and optionally nextUpdate
field of either type UTCTime or GeneralizedTime. We need to descend in the ASN1 until we get to the thisUpdate
field, look for and discard the optional nextUpdate
field and then walk through the revokedCertificates
sequence reading the serial numbers.
That procedure is not exactly a walk in the park, so in the hope that someone else may find it useful, here is the solution I came up with. Keep in mind that the code does not check the signature on the CRL so this code should not be used for any CRL that you do not trust implicitly.
The end results are pretty dramatic. The benchmarking toolkit I’m using shows an improvement in execution time by an order of magnitude (from around 7 seconds to .7 seconds) and memory usage drops by about 30%. You can see the GC statistics in the graph below.
and the benchmarking results are
Benchmark Mode Cnt Score Error Units CRLBenchmark.inMemory avgt 20 7493.602 ± 941.592 ms/op CRLBenchmark.stream avgt 20 669.084 ± 91.382 ms/op
In writing this, A Layman’s Guide to a Subset of ASN.1, BER, and DER was of invaluable assistance to me as was the Wikipedia page on X.690. I recommend reading them both.
Dear Internet,
As I noted in an earlier post, Eclipse on Fedora 22 has some usability problems with the colors it uses. Eclipse uses GTK 3 for a lot of the theming of the interface. With the Gnome Adwaita theme, several of the drop-down dialogs (like Content Assist) have very little contrast between the background and foreground of a selected item. The result is the highlighted text is extremely difficult to read. Your only recourse is to mess with GTK settings.
I had managed to address an issue with the Content Assist drop-down only to run into another issue with the Quick Outline drop-down. Finally I gave up and said, “to heck with it, I’m going to redo the whole thing.” To check out the result I came up with, head over to the Eclipse Graphene repo.
Here’s an example:
When I write Java, I use Eclipse. It does what I need it to do, but there are a few things about it that bother me. One of them is that Eclipse allows very limited control over the color scheme. Most of the color settings are inherited from the desktop theme that you’re using. I recently upgraded to Fedora 22 and with the Adwaita theme under XFCE, this is what the Eclipse content assist dropdown looks like:
Notice how close the foreground and background colors are for the selected item. I find that intolerable. I’m not sure exactly why Eclipse is picking that color combination, because the content assist object is a GtkTreeView which has the selected item background color set to cerulean blue in Adwaita. In any case, to fix it create ~/.config/gtk-3.0/gtk.css
with the following contents:
GtkTreeView:selected {
background-color: @theme_selected_bg_color;
}
That snippet will override whatever weirdness is going on with the content assist dropdown and set the background color back to the theme’s default background color for selected items. You can also just set it to a hex value. Note that this setting will apply to any GTK3 application, but that should be all right since you’re just asking the theme to do what it is already doing.
bitmath-1.0.8-1 was published on 2014-08-14.
Added Functionality
Tests
Last week I wrote about bitmath, a Python module I made for working with (prefix) units commonly used to represent file sizes, e.g., kB, GiB, Byte, TB. I can now happily say that python-bitmath has passed the review process and has been officially accepted into Fedora!
Need more proof?
References: