Installing GNUPG on a USB Flash drive

David Champion dgc at
Mon May 2 17:37:19 CEST 2005

* On 2005.05.02, in <3c8e7d2c0505020654319a2032 at>,
*	"daveb" <davebgimp at> wrote:
> looking around and have noticed that others have done this. What I'm
> looking for is links to possibly a tutorial or any instructions. I'm

I don't have this, I'm afraid.  However:

> mainly an end-user, so this is unfamiliar territory. I understand that
> I'll be needing to partition the Flash drive for the different OS's.

I've not needed to partition the drive.  I made some efforts early on
to partition it with both a Mac and a PC partition table.  I believe
this should be possible as they occupy different parts of the disk, and
one can craft the ptables so as to avoid one another, but in the end it
just wasn't worth the effort.  The Mac can read the USB drive if it's
partitioned as a single FAT32/VFAT pratition, so I just do that.  This
has the advantage also of allowing me a single keystore for all the
operating systems.

I've set up my USB drive with some subdirectories:

["..." is the mountpoint of the USB drive on whatever system I'm using.]

Inside each of the arch/* directories are gpg executables for each
system type, as well as whatever shared libraries (*.so or *.dylib) the
executable needs to run.  In general I've compiled the gpg executables
statically, so they don't need shared libs, but in some cases I did not.

In .../bin I have a script called "wrapper".  There are also files named
"gpg", "gpgsplit", and "pgpring".  These are copies of "wrapper", since
FAT32 doesn't support symbolic links.  I've attached the "wrapper"
script to this mail.

The effect of all this is that if I call .../bin/gpg with its path,
it figures out where it is and what system type it's on, adds the
arch/${SYSTEM} directory to LD_LIBRARY_PATH or DYLD_LIBRARY_PATH, and
runs the "real" gpg executable from the same location.  This has gotten
me all the multiplatform function I wanted from the USB drive, with a
single keystore also residing on the drive.  I also don't need to depend
on the integrity of the gpg executables or libraries on the host system.

This isn't perfect, and I'm sure someone out there is happy to point out
some of the flaws in this system.  They're correctible, if you're really
worried -- the problems are in the implementation, not the concept.  If
I get worried I'll rewrite the wrapper.

 -D.    dgc at        NSIT    University of Chicago
-------------- next part --------------

## Get system type
uname=${UNAME-`uname -s`}

## Find my directory's parent directory
dir=`dirname $0`
if [ "$dir" = "." ]; then
	parent=`dirname ${dir}`

## If asked to link programs, link them to wrapper -- but don't
## link wrapper to wrapper, that could be trouble on some planets.
if [ "$1" = "link" ]; then
	for file in "$@"; do
		[ ! "${file}" = "wrapper" ] && cp -fp "$0" "${dir}/${file}"

## Find the basename being executed. If it's "wrapper", then shift
## ahead to the next word and use that. So you can run "gpg --list-keys"
## either by linking/copying "wrapper" to "gpg", or by executing
## "wrapper gpg --list-keys".
exec=`basename $0`
if [ "${exec}" = "wrapper" ]; then

## Force in preloading library paths, in case we have shared libraries
## in arch directory we favor over native ones. DYLD_* is for BSDish
## things, including Darwin/MacOS X.  LD_* is for other things.
if [ -n "${LD_LIBRARY_PATH}" ]; then

## Finally, exec the real program.
exec ${arch}/${exec} --homedir=`pwd` --lock-never --no-permission-warning "$@"

More information about the Gnupg-users mailing list