Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
This posted for your amusement, since I KNOW none of you would dare run the international version while being a resident of the US ;-) MEG Matt Galster mattg at world.std.com PGP Key ID 54 A5 FA 5D FingerPrint 86 75 9F 46 C8 16 41 3C 25 8F D0 EA 42 C3 41 D7 In alt.security.pgp, JYoungman at vggas.com (James Youngman) wrote: > I have uploaded my source and binary RPMS of the >"International" version of PGP to >ftp://ftp.hacktic.nl:/pub/replay/pub/redhat > I have also uploaded to ftp.funet.fi, but the >files are still in the incoming directory. >Below is a message I posted to Usenet a while back about it:- >-----BEGIN PGP SIGNED MESSAGE----- > This file contains a few tips on how to get started with PGP on >Red Hat Linux. It explains how to install but not how to use the RPM for >the International version of PGP. It in no way replaces the excellent >documentation already available. I am not, after all, an expert in any >way on PGP or encryption. >* Where to Get It > I prepared this document before uploading the RPM, so I don't know >if it will be accepted and (if it will) where it will go on the archive >site(s). I intend to upload it to the FTP site ftp.pgp.net and also to >put it on ftp.vggas.com, which is a local machine for me. It may well not >be possible to put the RPM on the latter machine; my employer may be >somewhat nervous (I work for a UK company owned by a US one). As soon as >I know where you can FTP the RPM from, I'll post announcements to Usenet >and the Red Hat mailing lists. You will need version 2 of the RPM utility >in order to install this RPM; users of versions of Red Hat earlier than >3.0.3 will need to upgrade (the new version is much improved anyway). See >http://www.redhat.com/ for instructions. >* Background and Waffle > Because of the difficult legal situation in the USA surrounding >encryption, Red Hat cannot provide archive facilities for programs >containing encryption facilities. This includes PGP, and also other >packages for example SSH. This means that ftp.redhat.com can not carry >PGP. > PGP is available, however, from MIT. The simplest way to obtain >it wherever you are in the world is by FTP to ftp.pgp.net. You will be >directed to versions of the software appropriate for your location. For >example, US users will be directed towards the US version, which uses the >RSAREF library. Non-US users will be directed toward the international >version, which does not. I do not know what happens for those who live in >countries such as France where the right to privacy is completely >suppressed. I strongly urge you not to break either US export regulations >or your own national laws. It is possible to use PGP legally in many >countries -- if you obtain it in the right way. In Philip Zimmerman's own >words:- > "Some foreign governments impose serious penalties > on anyone inside their country for merely using > encrypted communications. In some countries they > might even shoot you for that. But if you live in > that kind of country, perhaps you need PGP even > more." > Red Hat Linux users benefit greatly from the Red Hat Package >Manager, which installs and keeps track of packages and their contents. >Although making an RPM package is fairly easy, none has existed until now, >mainly because of the legal difficulties. > I recently downloaded the international (non-US) version 2.6.3i >and some patch files. It turns out that the patch files posted on Usenet >News are inappropriate for this version; support for ELF on Linux is >already present. The whole thing compiles beautifully without patching >(this is under Red Hat 2.1). > I then prepared the RPM of pgp (pgp-2.6.3i-1). The RPM itself >bears my PGP signature. Here we have a chicken-and-egg situation; you >will need PGP installed to verify the RPM. See the "Authenticity" section >for more information. >The RPM is signed with my 1024-bit PGP public key, which is this:- >Type Bits/KeyID Date User ID >pub 1024/64A95EE5 1996/04/04 James Youngman <JYoungman at vggas.com> >- -----BEGIN PGP PUBLIC KEY BLOCK----- >Version: 2.6.3i >mQCNAzFkVGEAAAEEAMsmvW+yEzxc4h7LuEQmUYQcZSvU978BgdkWVYfEMjp44W7v >UMZsIoy7PfLu9jHLn4n/syv44AmhwnbZ67xuHEZuEo4v/2woM4Gq/1R/kCAfIdH1 >7+ESy2lqx+UQavckgOOGSRkUojUHgL9MUmsJJP0qahhWaROUXaFbcllkqV7lAAUX >tCRKYW1lcyBZb3VuZ21hbiA8SllvdW5nbWFuQHZnZ2FzLmNvbT6JAJUDBRAxZFRh >oVtyWWSpXuUBAfxCA/410MRngpBjFzzNaVfyK+Nr0ir6Y8h10FGoxUB9eyO6rYOj >NY9fwVarQovVyk6D/EbUo18Sa7kVF/IdpTO3X7xJIfDA3SglmFSfYHCx4eOw6WiT >6yxC6mKN+Ps1BHGb2tPjq03yz5blc8s3czxJOm11t3Rgpq8o9Wgh0d68jxashQ== >=K9Qw >- -----END PGP PUBLIC KEY BLOCK----- >* Configuration > The out-of-the-box configuration works fine, but I soon added >these lines to my config.txt:- >CharSet = latin1 >Armor = on # Use -a flag for ASCII armor whenever applicable >TextMode = on # Attempt to use -t option where applicable >BakRing = "/mnt/floppy/secring.pgp" > The intent of these is to make signed files readable ASCII, that >is, "pgp -s /etc/motd" will produce a file that is still readable with a >PGP signature appended. Since I use an xterm or Linux console for using >PGP, I can use the latin1 CharSet. Lastly, as with most Red Hat systems, >my floppy disk is mounted on /mnt/floppy. Your usage may differ from >mine, and so these options may be inappropriate for you. > > These modifications were not presented as patches, because >patching PGP is a sensitive issue and I wanted conspicuous authenticity, >as far as that was possible. > >* Authenticity > This RPM was created using (unpatched) the pristine source code >for version 2.6.3i, as digitally signed by Stale Schumacher. You can >verify its intactness yourself by installing the source RPM. >You will also need a copy of my public key in order to verify the RPM. My >public key appears above. You can go through the verification process by >using "rpm -bc" to build but not install PGP, and then use the compiled >binary (which is /usr/src/redhat/BUILD/pgp-2.6.3i/src/pgp) to import my >public key; you can then verify the RPM (using "rpm -K -vv" on the source >*AND* binary RPMs) and if the signature is valid you can execute the >install stage or install the binary RPM. Alternatively you could install >the binary RPM and then verify it afterwards, but the big question then is >what to do if the package then fails to verify... Seriously, I suggest >that you examine the output of the "rpm -K -vv" command to find out if the >verification failed because it had never seen my public key before (in >which case you feed it the one above) or the package had indeed been >signed with a different signature. In either case, it is also a good idea >to check the signature on the pristine source archive in >/usr/src/redhat/BUILD/pgp-2.6.3i/ against the signature certificate in the >same directory. Read the PGP documentation about how to do this. > To a large extent this is a very strange RPM; the idea of RPM is >that you can install and uninstall them painlessly and with some >expectation that they will work well on a Red Hat system. To further this >end, Red Hat have provided the functionality for you to assure yourself of >the authenticity of the package you're considering installing. Unhappily, >the software in *this* RPM is what you need to verify it with. That's why >the above paragraph outlines a weird verification approach -- it verifies >the RPM using itself without actually performing an installation. Future >RPMs -- including future versions of this RPM -- can simply be verified by >using an already installed version of this RPM. > > Since the authenticity of versions of PGP is a delicate matter, I >suggest that you install PGP by installing the source RPM whenever >possible. In the build directory is the file pgp263ii.tar, and the file >pgp263ii.asc, which is the source code archive and a detached signature >certificate for it, which matches the key given for "Stale Schumacher ><stale at hypnotech.com>". His public key has not been introduced to me, so >I am not *absolutely* certain that the tar file is "authentic" (whatever >that means). I'm merely pretty sure. However, *you* can take steps to >verify it for yourself. Read the manual to find out how to do this. > It's no good getting the RPM and the public key to verify it >against at the same time in the same way unless you trust absolutely >the integrity, source, and distribution method. It's better to use >separate channels. This document will be posted -- signed -- to >Usenet and several mailing lists and you could use the key it provides >to verify the separately-obtained RPM. >* What To Do Now > Read the manual. > Read the documentation in the /usr/doc/pgp* directory. > Verify the RPM and the source archive inside it in the > build directory, if only for practice. > Read the PGP newsgroups, or the Cypherpunks mailing list. > Look out for a second, signed, RPM. > Read the manual. > Look out for an RPM of extra PGP documentation, probably "pgpinfo". > Read the manual. > >* About Me > All I've done is produce the RPM; all kudos for the software goes, >of course, to Philip Zimmerman. I send and receive personal email on an >account provided by my employer; however, my employer in no way endorses >any action or statement of mine. Further, if the RPM does turn up on >ftp.vggas.com (which is soon to come into being) then that also implies no >endorsement of PGP or its use by my employer. >* Afterword > This document is signed by me (James Youngman ><JYoungman at vggas.com>), but my public key has almost certainly not been >introduced to you. Therefore, the signature certificate is not currently >much use to you. However, you can take steps to obtain my public key >later, and *then* verify it. >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3i >Charset: latin1 >iQCVAwUBMWZlmqFbcllkqV7lAQG/EgP8DE5H66ip5MoozrhmHxCXrkjNv7BSzZ/g >tHQK0jkRzvj7piJ8/jzeIaxxPk+9fOCkztW0yWtG7oo5t3rXXDPwqd/1eyzPoENI >JO7WBxaz2MpUNldP5HG//WZLX8ex1Wpw3c/6g8rsUNWXJf7pMOO4Os6FRtm0PHY+ >6dS/wYiRd24= >=NleI >-----END PGP SIGNATURE-----
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |