Our Blog

Subversion or CVS metadata exposure

By Jon Jensen
August 20, 2008

At the talk “Rails Security” by Jonathan Weiss at LinuxTag 2008, he mentioned (among other things) a possible security problem for sites being run out of a Subversion (or CVS or even RCS) working copy, where the metadata inside the .svn/ or CVS/ directories may be exposed to the world. This post by someone else explains it nicely.

Interchange appears not to be vulnerable to this by default as it will only serve files that end in .html, and all the .svn/ and CVS/ filenames have no suffix, or end with .svn-base, so are not served by Interchange.

But if the docroot is served from a Subversion or CVS checkout, its metadata files are likely served to the world—​relatively harmless, but can reveal internal file paths, hostnames, and OS account names.

For PHP or SSI, on the other hand, this could be a disaster, as the complete source to all files could be revealed, since the .svn-base suffix will cause Apache not to parse the code as PHP but pass through the source.

If you use Subversion, CVS, or RCS on any project, I recommend you look into how your files are being served and see if there’s anything being exposed. Checkouts from Git, Mercurial, or Bazaar are not likely to be a problem, …

Some handy cryptography/networking tools

By Jon Jensen
August 19, 2008

Here’s a list of some nifty cryptography/networking tools Kiel’s pointed out lately:

• socat — multipurpose relay; think netcat gone wild—​we used this recently to tunnel UDP DNS queries over ssh
• cryptcat — netcat with twofish encryption (the Debian package adds a man page)
• rsyncrypto — partial transfer-friendly encryption (modified CBC for smaller change windows similar to gzip; less secure than regular CBC)

And a pretty unrelated but useful Red Hat Magazine article on the new yum-security plugin.

Alaska Basin

By Jon Jensen
August 18, 2008

From Thursday to Saturday I backpacked with a friend and some of our kids into Alaska Basin (in the Tetons, in Wyoming), saw some beautiful scenery, and became reacquainted with the other kind of bugs for a while.

The lake is Sunset Lake, where we went Friday night. I frolicked in the snowmelt water and lost my new glasses in the silt, but came back the next morning and found them after wading out 20 feet or so. It was a great trip.

On “valid” Unix usernames and one’s sanity

By Jon Jensen
August 13, 2008

Today poor Kiel Christofferson ran into an agonizing bug. A few weeks ago, building a custom RPM of perl-5.10.0 (that is, the Perl distribution itself) wasn’t a problem. The unit tests passed with nary a care.

But today it no longer worked. I’ll omit details of the many false paths Kiel had to go down in trying to figure out why an obscure test in the Module::Build package was failing. Eventually I took a look and noted that he’d tried all the logical troubleshooting. Time to look at the ridiculous. What if the test was failing because the last time he built it successfully it was under the user “rpmbuild”, while he was now trying with user “rpmbuild-local”?

That was exactly the problem. Module::Build’s tilde directory (~username) parser was of the (false) opinion that usernames consist only of \w, that is, alphanumerics and underscores. The reality is that pretty much anything is valid in a username, though some characters will cause trouble in various contexts (think of / : . for example).

I explained in more detail in CPAN bug #33492 which reports someone else’s experience with the test failing when the username had a backslash in it, such as the Active Directory name …

OpenAFS Workshop 2008

By Steven Jenkins
August 13, 2008

This year’s Kerberos and OpenAFS Workshop was very exciting. It was the first I’ve attended since the workshop was large enough to be held separately from USENIX LISA, and it was encouraging to see that this year’s workshop was the largest ever, with well over 100 in attendance, and over 10 countries represented. Jeff Altman of Secure Endpoints did a great job on coordinating the workshop. Kevin Walsh and others at New Jersey Institute of Technology did a fantastic job in hosting, providing the workshop with a good venue and great service.

My summary of the workshop is “energy and enthusiasm” as several projects that have been in the development pipeline are starting to bear fruit.

On the technical side, the workshop keynote kicked off the week with a presentation from Alistair Ferguson from Morgan Stanley, where he noted that the work on demand attach file servers has reduced their server restart times from hours, down to seconds, greatly easing their administrative overhead while making AFS even more highly-available.

Of particular technical note, Jeff Altman reported that the Windows client has had lots of performance and stability changes, with major strategic changes being …

RPM --nodeps really disables all dependency logic

By Jon Jensen
August 12, 2008

I was surprised about something non-obvious in RPM’s dependency handling for the second time today, the first time having been so many years ago that I had completely forgotten.

When testing out an RPM install without having all the required dependencies installed on the system, it’s natural to do:

rpm -ivh $package --nodeps

The –nodeps option allows RPM to continue installing despite the fact that I’m missing a handful of packages that $package depends on. This shouldn’t be done as a matter of course, but for a quick test, is fine. So far so good.

However, I found out by confusing experience that –nodeps not only allows otherwise fatal dependency errors to be skipped, but it also disables RPM’s entire dependency tracking system!

I was working with 3 RPMs, a base interchange package and 2 ancillary interchange-* packages which depend on the base package, such as here:

interchange-5.6.0-1.x86_64.rpm
interchange-standard-5.6.0-1.x86_64.rpm
interchange-standard-demo-5.6.0-1.x86_64.rpm

Then when I installed them all at once:

rpm -ivh interchange-*.rpm --nodeps

I expected interchange to be installed first, followed by either of the interchange-standard-* packages that …

Listing installed RPMs by vendor

By Jon Jensen
August 9, 2008

The other day I wanted to see a list of all RPMs that came from a source other than Red Hat, which were installed on a Red Hat Enterprise Linux (RHEL) 5 server. This is straightforward with the rpm –queryformat (short form –qf) option:

rpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -v 'Red Hat, Inc\.' | sort

That instructs rpm to output each package’s name and vendor, then we exclude those from “Red Hat, Inc.” (which is the exact string Red Hat conveniently uses in the “vendor” field of all RPMs they pacakge).

By default, rpm -qa uses the format ‘%{NAME}-%{VERSION}-%{RELEASE}’, and it’s nice to see version and release, and on 64-bit systems, it’s also nice to see the architecture since both 32- and 64-bit packages are often installed. Here’s how I did that:

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH} %{VENDOR}\n' | grep -v 'Red Hat, Inc\.' | sort

With that I’ll see output such as:

fping-2.4-1.b2.2.el5.rf.x86_64 Dag Apt Repository, http://dag.wieers.com/apt/
git-1.5.6.5-1.x86_64 End Point Corporation
iftop-0.17-1.el5.x86_64 (none)

There we see the fping package from the excellent DAG RPM repository, along with a few …

End Point’s Spanish website

By Jon Jensen
August 8, 2008

We’ve had a Spanish version of our website at es.endpoint.com for about a year now, and we keep the content there current with our main English website. We haven’t promoted it much, so I figured I’d mention it here and see if any English speakers feel like checking it out. :) We currently have only a few Spanish speakers at End Point, and if a non-English-speaker calls our main office, it may take a bit of shuffling to route the caller to the right person.

But more to the point, we’ve done a few interesting multilingual projects. One of them is a private business-to-business website localized in US English, UK English, French, Canadian French, German, Italian, Japanese, Simplified Chinese, Traditional Chinese, Portuguese, Brazilian Portuguese, and Spanish. We’re experienced with popular character set encodings and Unicode in web protocols, Postgres and MySQL databases, Perl, and Ruby. We’re always interested in taking on more such projects as they tend to be challenging and fun.