San Francisco, Santa Cruz, King City, Paso Robles, Santa Maria, Lompoc,
Ventura, Los Angeles. For the better part of seven days, I sat on a bicycle
with over 2,200 cyclists and 650 volunteers riding from one part of California
to another to raise money for HIV/AIDS services as part of
AIDS/LifeCycle. In perspective, 545 miles is
further than the distance from Boston to Washington D.C., further than Brussels
to Berlin, further than Tokyo to Hiroshima. It is countless hills, steep
descents, farm fields, supportive on-lookers, packets of chamois butter,
potholes, water bottles, and sliced bananas. Based on this, my first year’s
experience, it is also six inner tubes, one bike tire, and an entire bike frame
long.
Offlineimap has been a major part of my desktop
computing environment for many years, indulging my use of mutt for all work and
personal email. My work email has unfortunately been stored in Gmail, which
does support IMAP but tends to do a few wacky things with files and folders.
For a myriad of reasons the only video-news I consume tends to be
German-language news out of Germany. Local or national American news is usually
lower quality, setting aside the abhorrent
monopolies,
it always trends towards an insular world view, missing many major
international events. One such event skirting under radar of American media has
been the disintegration of the Austrian parliament after the deputy chancellor,
a member of a far-right party, was caught on video soliciting bribes from a woman posing as a relative to a
Russian
oligarch.
JRuby/Gradle is one of the few open source projects
which I created that actually resonates with people. One that I find myself
continuing to work on, despite not using it in my day-to-day work. JRuby/Gradle is a
collection of Gradle plugins which make it easy to build, test, manage and
package Ruby applications. By combining the portability of JRuby with Gradle’s
excellent task and dependency management, JRuby/Gradle provides high quality
build tooling for Ruby and Java developers alike. With my fellow maintainer,
Schalk
Crojné, I started working towards the 2.0
milestone.
For years the Jenkins project has published anonymous usage statistics to
stats.jenkins.io. Despite its warts, the system has
ultimately proven useful for determining which plugins are most frequently
installed, big coarse-grained changes in growth, and providing various
marketing departments with the validation they so desperately crave. Like many
of the tucked away corners of the Jenkins project, being an infrastructure
maintainer affords me an understanding of how the system works, and sometimes
doesn’t. As I promised to the CDF Technical Oversight
Committee many weeks ago, in this post I will attempt to describe how this
system works.
Making changes safely to an application like Jenkins is
incredibly tricky. Jenkins is distributed to hundreds of thousands of
independently owned and operated servers and is used in a myriad of ways.
Our changes with the best intentions, can still result in confounding bugs and errors
for users with different configurations, or different combinations of plugins. Over on
the Jenkins project blog, Daniel wrote about the first
use of “telemetry” by Jenkins
core, a project on which
we collaborated. I ended up building the backend service for receiving this
telemetry, Uplink, and I hope it
paves the way for making smarter changes across Jenkins core in the future.
Today marks one month until the beginning of AIDS/LifeCyle
2019 (ALC)! Which means I am one month
away from starting a bicycle journey with thousands of other riders from San
Francisco to Los Angeles as part of our effort to raise money for AIDS/HIV
related services. As of this writing, my fundraising is at $3,377 which is
still short of my fundraising goal: $5,000. If you appreciate my work in the
Jenkins project, the JRuby/Gradle
project, or if you have enjoyed my sass on
Twitter, please convert your appreciation into
a donation to AIDS/LifeCYcle. :)
Continuous integration and continuous delivery (CI/CD) projects might just be
one of the hardest to lock down and secure. As system designers and
implementors we must enable developers to automate their builds, tests, and
deployments. And yet, in doing so, we also give those same developers the
ability to bypass many of the boundaries we may have set up to secure our
environments. If you give me the ability to automate my deployment with a
script, I can think of a number of ways in which that ability can lead to
information disclosure or other types of breaches. Jenkins
Pipeline is filled with any number of
problematic examples here the same feature can be looked at as empowering or
as compromising. I believe the immense flexibility of Jenkins Pipeline also gives us
a path to provide automation which is inherently more secure than some
competitors. In this post, I’ll outline one such idea: a pipeline secure
enclave.
If you were to draw a coordinate system for software, where the x-axis was
“important to use” and the y-axis was “enjoyable to use”, x509 certificates
would be at the extreme edge of the bottom right of quadrant four. Much as I
dislike them, they are absolutely critical to securing practically everything
we do. As is the case with most companies, Scribd uses
custom root certificates to establish a controlled chain of trust for internal
resources. A sensible practice, but can be a great learning exercise, causing
you to discover all the various ways in which trust is defined and managed in a
modern development environment.
When waiting for containers to build, or dependencies to download, my mind
tends to wander. Yesterday it wandered to the plight of new contributors to
modern free and open source projects; how much they must do before even
attempting to collaborate! I started a Twitter
poll, asking: