The Altruist

The Altruist’s position presents him with opportunities not normally present. He shares the benefits, so that the lives of those whom he protects will be enriched.

Page 1 of 5

 Go to the next page. Go to the last page.

Written by Adrian Goins on Mar 13, 2011 in Arces

When uploading files to a project it's nice that the system identifies the file type and shows the corresponding icon for the file.  We upload Word documents as well as PDF versions, so our clients can quickly choose the version that's most appropriate for their need.

ProjectPier 0.8.6 ships with a bug in its SQL load that sets "xls" files to "xsl" as the extension and "doc.png" as the icon.  It's also missing newer "xlsx" and "docx" types.  These things are easy to fix from the MySQL shell.

mysql> insert into pp086_file_types (extension, icon) values ('docx', 'doc.png');
Query OK, 1 row affected (0.00 sec)
mysql> update pp086_file_types set extension='xls', icon='xls.png' where extension='xsl';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
mysql> insert into pp086_file_types (extension, icon) values ('xlsx', 'xls.png');
Query OK, 1 row affected (0.00 sec)
Written by Adrian Goins on Mar 13, 2011 in Arces

After spending 2 days kicking RailsCollab around the room, I'm even more impressed with ProjectPier than I expected I would be.  RailsCollab is clearly a low-budget clone of ProjectPier, and given the hassle it takes to install and the low functionality it provides after installation, skip the effort and go right for the winner.

Written by Adrian Goins on Mar 11, 2011 in Ruby

RailsCollab is an open-source project management application inspired by Basecamp.  Of the available OSS apps it looked to be the most mature, but it has some hurdles to overcome if you want to install it.  After the jump I'll go through each of the items I encountered during the install and what had to happen to put the issues to bed.

Written by Adrian Goins on Feb 9, 2011 in IPv6, Arces

The next generation of Internet addresses, called IPv6, has been around for a long time, but only in recent months has the effort to adopt IPv6 begun to pick up steam.  IANA has allocated the last of the IPv4 space and in a matter of weeks there will be no more IPv4 space available for businesses to use.  In anticipation of this, Arces has joined with Google, Sesame Workshop, Bing, Yahoo, and others for World IPv6 Day on June 8th.

Many sites on the Internet already have their systems running on both IPv4 and IPv6 addresses, but they've been running them in parallel.  Facebook has and  Google has and  They've been offering IPv6 services to those people connected to the IPv6-enabled Internet, but they've been keeping IPv4 as the primary means of accessing their site.  The reason for this is that a computer may have an IPv6 address already but not have IPv6 connectivity outside of the local network.  Systems which run in dual-stack mode (having both types of addresses) are designed to connect with IPv6 before IPv4.  If there is no IPv6 connectivity to the Internet, then it would appear to the user that the site isn't responding.  After some period of time it will fail over to IPv4 for that request, but then the next request will also time out.  For Google or Facebook, this perception is negative for their business, so they won't cut their services over to IPv6 for the main sites.

No one doubts that IPv6 is important or that the transition has to happen in order for the Internet to continue to operate and for businesses to continue to grow.  However, there is a Catch 22 involved.  No one wants to transition to IPv6 for the client-side communication because the majority of destination sites on the Internet are available over IPv4.  None of the businesses want to make the leap to IPv6 because all of their clients are on IPv4.  This stalemate will not break on its own, which brings us to World IPv6 Day.

World IPv6 Day is being promoted by the Internet Society and is backed by ISPs, integrators, portals, and others on the business side.  The plan is that on June 8th, for 24 hours, participants will convert their main websites to be IPv6-enabled and serve them along with IPv4.  This will expose the delays mentioned above, but it will also expose a great deal of information about the readiness of IPv6 for the mainstream.  Where problems appear, businesses will know what they must fix in order to offer IPv6 services.

The idea is bold, but necessary.  In a matter of months people will have to know what to do when their ISP gives them a network that looks like 2600:C206:A:0100::/64.  This is a paradigm shift in the operation of the Internet, and we're moving into the last leg of the race to implement it.  The more businesses that play rabbit and sleep while the turtle of IPv4 exhaustion waddles toward the finish line, the more horrific the great transition to global IPv6 services will be when it hits.  A project like World IPv6 Day is audacious and will succeed because it breaks through the inertia of the stalemate.  Once the ball starts moving, inertia will hopefully keep it in play.

Written by Adrian Goins on Dec 15, 2010 in Security

This email was published to the OpenBSD mailing list earlier today.  Although being reported elsewhere, it has not been vetted, and may very well be a joe job.  It needs to be discussed, and if true, the ramifications are staggering.  If the FBI paid open source developers to install backdoors into the OpenBSD crypto layer as far back as 2000 and 2001, then it's possible that those leaks have spread to all areas of cryptographic security through derivative products.

I have received a mail regarding the early development of the OpenBSD
IPSEC stack. It is alleged that some ex-developers (and the company
they worked for) accepted US government money to put backdoors into
our network stack, in particular the IPSEC stack. Around 2000-2001.

Since we had the first IPSEC stack available for free, large parts of
the code are now found in many other projects/products. Over 10
years, the IPSEC code has gone through many changes and fixes, so it
is unclear what the true impact of these allegations are.

The mail came in privately from a person I have not talked to for
nearly 10 years. I refuse to become part of such a conspiracy, and
will not be talking to Gregory Perry about this. Therefore I am
making it public so that
(a) those who use the code can audit it for these problems,
(b) those that are angry at the story can take other actions,
(c) if it is not true, those who are being accused can defend themselves.

Of course I don't like it when my private mail is forwarded. However
the "little ethic" of a private mail being forwarded is much smaller
than the "big ethic" of government paying companies to pay open source
developers (a member of a community-of-friends) to insert
privacy-invading holes in software.


From: Gregory Perry <>
To: "" <>
Subject: OpenBSD Crypto Framework
Thread-Topic: OpenBSD Crypto Framework
Thread-Index: AcuZjuF6cT4gcSmqQv+Fo3/+2m80eg==
Date: Sat, 11 Dec 2010 23:55:25 +0000
Message-ID: <8D3222F9EB68474DA381831A120B1023019AC034@mbx021-e2-nj-5.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Status: RO

Hello Theo,

Long time no talk. If you will recall, a while back I was the CTO at
NETSEC and arranged funding and donations for the OpenBSD Crypto
Framework. At that same time I also did some consulting for the FBI,
for their GSA Technical Support Center, which was a cryptologic
reverse engineering project aimed at backdooring and implementing key
escrow mechanisms for smart card and other hardware-based computing

My NDA with the FBI has recently expired, and I wanted to make you
aware of the fact that the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF, for the express
purpose of monitoring the site to site VPN encryption system
implemented by EOUSA, the parent organization to the FBI. Jason
Wright and several other developers were responsible for those
backdoors, and you would be well advised to review any and all code
commits by Wright as well as the other developers he worked with
originating from NETSEC.

This is also probably the reason why you lost your DARPA funding, they
more than likely caught wind of the fact that those backdoors were
present and didn't want to create any derivative products based upon
the same.

This is also why several inside FBI folks have been recently
advocating the use of OpenBSD for VPN and firewalling implementations
in virtualized environments, for example Scott Lowe is a well
respected author in virtualization circles who also happens top be on
the FBI payroll, and who has also recently published several tutorials
for the use of OpenBSD VMs in enterprise VMware vSphere deployments.

Merry Christmas...

Gregory Perry
Chief Executive Officer
GoVirtual Education

"VMware Training Products & Services"

540-645-6955 x111 (local)
866-354-7369 x111 (toll free)
540-931-9099 (mobile)
877-648-0555 (fax)

While everyone is thinking about how far a security compromise such as this may extend in the open source cryptographic software stack, there are other questions which one might ask, questions which actually lead back to the viability of the source:

  1. Why was the code not audited before being accepted by the maintainers?  Are the backdoors so slick and fancy that they look like normal software routines?
  2. Why has no subsequent code derived from the OpenBSD crypto layer been audited or otherwise revealed the backdoors in the 10 years since?

All of the places where these questions end are bad.  Either the source is lying (which isn't so bad) or people haven't paid attention, and the latter of these painfully highlights one of the great shortcomings of open source community programming in general.  If the community can be infiltrated by those with nefarious intent, then the community can't be trusted.  If the community can't be trusted, then it's not a community.

This software used to be on the Department of Defense export restrictions list.  It's not restricted anymore, which means that the trojaned code could be deployed in secure areas used by other countries.  VPNs are secure, right?  TrueCrypt?  IPSec?  SSL?  If you consider the cost of someone watching the traffic flowing through any of these supposedly-safe technologies, and add to that the known processing power of systems like Echelon, then you can imagine just what the FBI has been hanging out and reading for a decade.

Does this count as espionage?  If you're spying on your enemies, then you're doing good.  What about when you're spying on your friends, or worse, just spying on everyone?

What happened to the concept of privacy, or the right to be excluded from onerous law enforcement scrutiny until you've actually come under suspicion for doing something wrong?  Oh snap!  I forgot - we're all under suspicion by default now.