Tuesday, December 30, 2014

Installing Nemiver on Centos 7

I recently heard about Nemiver, a standalone C/C++ debugger for GNOME, and wanted to give it a try.

My current Linux development box is running CentOS 7. While Nemiver packages exist for CentOS 6, the same cannot be said for CentOS 7. So I proceeded to build it from source.

First, I went ahead and cloned the Git repository: git clone git://git.gnome.org/nemiver

After running the ./autogen.sh script, it was clear that I was in for several iterations of dependency installation. I'll save you the trouble:

sudo yum install gnome-common intltool yelp-devel yelp-tools boost-devel sqlite-devel GConf2-devel libgtop2-devel glibmm24-devel gtkmm30-devel gtk3-devel gtksourceview3-devel vte3 vte3-devel

Note that I do have the EPEL repository enabled, so I'm not sure if some of those packages came from EPEL or not.

Unfortunately, there seems to be no gtksourceviewmm-3.0 package for CentOS 7 either! Sure, why not install that one from source, too?

First, download gtksourceviewmm-3.2.0.tar.xz (or later). By default, configure defaults to PREFIX=/usr/local. If you don't change this, pkg-config won't know where do find it. So ./configure --prefix=/usr --libdir=/usr/lib64 seems to be what we want. Then make, sudo make install as usual.

Now, you should be able to finish configuring and making Nemiver!

Note that there also seemed to be a build issue in src/confmgr/nmv-gconf-mgr.cc. The following patch took care of it for me - not sure how this went unnoticed.

--- a/src/confmgr/nmv-gconf-mgr.cc
+++ b/src/confmgr/nmv-gconf-mgr.cc
@@ -32,6 +32,7 @@
 NEMIVER_BEGIN_NAMESPACE (nemiver)
 
 using nemiver::common::GCharSafePtr;
+using nemiver::common::GErrorSafePtr;
 
 class GConfMgr : public IConfMgr {
     GConfMgr (const GConfMgr &);

Until this is fixed, you can use my fork at git@github.com:JonathonReinhart/nemiver.git

Thursday, October 23, 2014

GitLab time zone issues

GitLab is a great open source GitHub clone, which I've started using for tracking my personal Git repos.

One frustrating thing I've found with GitLab however, is its handling of time zones.

Read:

Apparently GitLab doesn't detect the user's timezone (or store it in their profile) and display times accordingly.  Everything outside of the Git timestamps appears to be tracked in UTC.

To fix this for my local server, I edited
    /opt/gitlab/embedded/service/gitlab-rails/config/application.rb
and specified
    config.time_zone = 'Eastern Time (US & Canada)'

Update:

In version 7.5.0, this configuration option was moved to gitlab.yml. Now you don't have to re-set this option after every upgrade. Instructions for how to set it for an Omnibus install (in /etc/gitlab/gitlab.rb) are here.

Wednesday, May 28, 2014

TrueCrypt-end

Today, the TrueCrypt website and SourceForge project page suddenly changed, indicating the end of TrueCrypt development. truecrypt.org now redirects to their SourceForge project page, and the content has been replaced with a surprising message:


Not only has development officially ceased, but TrueCrypt is being declared "not secure", and the official webpage is suggesting that people migrate to BitLocker!  (BitLocker is the drive encryption solution built in to some versions of Windows Vista and later.)  Furthermore, a new version 7.2 had been released, which warns users that TrueCrypt is insecure. The repository had been scrubbed, and all previous binaries had been deleted.

I'm sure you could almost hear the collective WTF?! from everyone in the InfoSec community.

A series of edits indicating that the software had been discontinued were even posted to the TrueCrypt Wikipedia page by a user with the handle Truecrypt-end.

At first, it seemed like some pranksters had managed to take over the TrueCrypt website, and poke fun by suggesting users migrate to their inferior commercial competitor, BitLocker.  Well, the DNS records had not changed, so everything was good there. And SourceForge indicated that there was no suspicious behavior on the account (ya know, aside from closing everything down!)

Of course there are rumors abound at all of the tech watering holes, from Slashdot to the /r/sysadmin subreddit  to the InfoSec Stack Exchange site and of course Twitter.  While many still believe that the project was hacked, others are pondering the possibility that the devs were asked to insert a back-door, and subject to a gag-order preventing them from disclosing the requirement.  The TrueCrypt development team has remained behind the big black curtain for most of its development which makes the situation even more curious. Perhaps a vulnerability had been discovered and the developers simply didn't want to be involved with the product any more. There is certainly no shortage of opinions on the matter. The most interesting theory I've heard is that this is a sort of warrant canary.


So what about this new version 7.2?

The binaries were signed with the same GPG key as all previous releases, indicating that this release was "official", or at least produced by someone with access to the private key.

Internally, the TrueCrypt.exe executable and the truecrypt(-x64).sys drivers were signed (a la Microsoft Authenticode) with a different certificate than 7.1.1, but that certificate expired shortly after the last release. This new certificate was issued (to the same named entity) shortly before the previous certificate expired. It's very unlikely that someone was able to spoof a new certificate in this manner, and had planned it two years ago.  [Screenshots tomorrow.]

The changes to the latest version's source code were posted to GitHub.  This paints probably the most confusing picture of all.  

First, the code has been littered with warning messages and error codes indicating that "Using TrueCrypt is not secure".  Next, we see that pretty much all of the code related to creating encrypted volumes has been removed, and replaced with AbortProcess ("INSECURE_APP");. We also notice that all code related to updates, error reporting, user's guide/help, or anything pointing back to the TrueCrypt website has been removed.  Clearly, the developers consciously made the decision to burn all bridges, and carefully executed a plan to do so.

What's very bizarre however, is that while there were 4112 deletions, there were also 1760 additions to the code. Along with other minor bugfixes, it appears that in-place decryption was newly implemented.  It looks as if this was code that was part of an upcoming release that brought some improvements after a two-year break. Unfortunately, it also came with mass deletions that rendered the software useless for anyone seeking to create encrypted content.

What are you thoughts?