Very Newbie Questions

[Henry Hertz Hobbit]

John Clizbe <JPClizbe at tx.rr.com> wrote:

Please be warned that this is a LONG response.  If you don't
care, please hit the delete button.  I don't see any way of
making it shorter right now. In fact I may be misinterpreted
and that means it isn't long enough.  I think that is what
just happened.

Some of this should probably be in the Developer's forum.
I am loathe to do that because most Windows users are also
their own System Administrators.

> Henry Hertz Hobbit wrote:
> 
>>I don't know what you are using to install GnuPG itself.  Make
>>sure that you have a copy of iconv.dll (zip that contains it if
>>doing separately is libiconv-1.9.1.dll.zip) is in your
>>%SystemDrive%\windows\system32 folder After the install.  I don't
>>know whether they put the following values in the registry with
>>what you are using but you can check it after installing GnuPG
>>with regedit:
> 
> 
> Manual registry editing is not needed - the installer handles all
> the entries GnuPG needs.

First, what if you put your keys on one of the crypto cards, or on
a USB stick?  What value are your automated HKEY_CURRENT_USER keys
now?  I think what I gave them they can easily extrapolate to the
new location without me even saying one word.  Novice Windows users
may have problems - experienced ones will tell me to shut up and go
about doing things without me saying anything more.  That middle
ground was what I was aiming at.

Your install does not handle my needs.  It may now handle all of them
for the user doing the install, but hhhobbit is NOT doing the install
on my machine since hhhobbit is only an ordinary user and is thus
unable to put anything into %WinDir% or %WinDir%\system32 (same for
%ProgramFiles%, because with the Windows DACLs I run, my systems are
pretty tight). The super user on my systems when they are running MS
Windows is somebody else other than me (hhhobbit). NO, YOU MAY NOT KNOW
THEIR NAME!  I use the accounts other than hhhobbit only for
administering the system (primarily making sure the AV is up to date
every time I run Windows).  My hhhobbit user account is what I normally
use and also when encryption is usually required. But there are times
the other accounts also need access to the keys on the key ring
(verifying downloads, etc.).  For these special cases it is nice to
specify where the key files are for ALL of the accounts that use the
same key-ring if you CAN share them among multiple users.  In other
words, you can't completely automate all of this.  What you probably
have is geared around people that run their accounts as the
administrator of the machine. That is NOT how I run my machines. That
is why I am giving what I have to people.  The end user *MUST* take
some of the responsibility.  The best way to do that, IMHO, is to lay
it all out for them and allow them to make their own decisions.  I
believe the DropMyRights program only goes so far. Every time some
other program is messaged into existence by a program that runs with
dropped rights, the other program attains ALL of the privileges of the
logged in user, not the privileges of the program which messaged it
(which is running in diminished capacity because it was started with
DropMyRights). I much prefer to log in as a less privileged user for
most Internet stuff. This IS in accordance with Microsoft policy.
I encourage all other users to do the same thing (NO, you don't have
to adopt my draconian settings - less than an Internet server but not
as loose as most people's machines either).  My machines are closer to
the Internet server than to most people's machines.  It only takes one
system compromise to wise you up as to how loosey-goosey Microsoft out
of the box is.  I have seen hundreds of compromises of Windows machines,
thankfully all on machines I didn't have control over.  I consider that
more a matter of SHEER LUCK than any brilliance on my part.

If you are not the user doing the install of GnuPG AND the install
puts in the HKEY_LOCAL_MACHINE settings, you can modify what I have
given by deleting all of the HKEY_LOCAL_MACHINE KEYS, keeping all of
the HKEY_CURRENT_USER (all but the first three) and modifying them
for your user name.  You will need them! You will also have to use
YOUR user name.  This is really important since even if the person
that did the install is also the end user, since MS Windows does that
wonderful shift from your account being named hhhobbit to
hhhobbit.MACHNAME. Hopefully it was much shorter than "Gene & Denine's
wonderfull awesome computer", and YES I AM QUOTING THE ACTUAL NAME!
For the love of what ever, let your machine have its OWN SHORT NAME.
This account name shift frequently occurs after some of the update
patches or for some other reason.  When that happens you may want
to alter the HKEY_CURRENT_USER data values again unless you want to
keep your GnuPG keys in the old folder.  If you don't you may want
to enter the new Registry settings. You will also need to change them
if you move your keyring files to a USB stick or a crypto card. I
prefer moving my key files to my new folder (for what ever reason
and that includes moving the keys to a USB stick I can carry around
with me) when the name change happens. I also do NOT trust Microsoft
to get it correct (yes the folder where my keys are at is protected
from access by other users, including all of the other Sys Admins).
That is also why these pluggable cards that have your encrypting
keys on them are such a good idea. Why Microsoft changes the account
name in the first place is a mystery to me.  But the fact Microsoft
does stuff like this is why they have thousands of administrators out
there keeping machines running MS Windows shops going.  WHEN YOU ARE
ON MICROSOFT WINDOWS PROTECT YOUR KEY FILES!  It is best when your
OpenPGP key files  aren't even on the machine unless you are using
it.  A crypto card or a USB stick is wonderful for that.

> Likewise, there is no need to copy or do anything else with
> iconv.dll. As a general rule of thumb, copying things into
> %systemroot%\system32 is to be avoided. The iconv library is only
> needed for NLS support. If gpg needs it and cannot find it, it will
> issue a warning and continue executing.

I wouldn't even make that statement.  The correct place for every
piece of software I have used is for them to usually install their
DLL files IN the the %SystemRoot%\system32 folder.  The only
other real alternative that is rarely taken is for them to put
their DLL file in their own %ProgramFiles% folder. In the
README.iconv.dll file it states: "To install this dll simply copy
the file 'iconv.dll' to a directory where you usually keep the
DLLs."  At least Windows people are spared the Macintosh OS-X,
Sun Solaris, etcetera, etcetera, etcetera, /opt (or what ever)
versus /usr/local argument.  There IS NO OTHER "STANDARD" folder
for DLL files on Windows that is well known other than the
%SystemRoot%\system32 folder.  That is why over 90% of the software
I have installed (Lexmark Scanner / Printer, HP scanner / Printer
with HP ethernet card, Minolta PagePro 1350W printer with access
through Zonet printer server, Office 2003, etc.) puts their DLL
files there.  They MUST put their driver files in the %SystemRoot%
area anyway, and since they may have 10 or more models of their
printers, etc. that use the same DLL, it is natural for them to also
install it in the %SystemRoot%\system32 folder as well. Why have
multiple copies of the same DLL for each piece of their software
especially if it never changes?  It is best to put just one DLL on
the machine. I would wager that over 85% of Windows software does
put their DLL files in the %SystemRoot%\system32 folder rather than
in their own folder in the %ProgramFiles% area.  The piece that is
missing is if what you are installing is actually older than what
ever you currently have for a given DLL file.  I HATE to have older
files replacing newer ones.

> Werner posted that the installer correctly handles iconv; ie if the DLL is found
> in your path, the installer does nothing; if not found or too old, it places a
> copy of iconv.dll into the GnuPG program directory. [GnuPG-Devel 2005-03-17]

Okee-dokee.  If you have more than one software package using that
DLL, it is usually best to just have one copy of that DLL file in the
%SystemRoot%\system32 folder instead of in each %ProgramFiles folder.
Further, I STRONGLY suggest some way of automating (you hinted
you did it) that they have the latest and greatest.  I am saying this
only because almost EVERY piece of Microsoft Windows software does NOT
DO THIS.  I can't count the times that the more current DLL file I have
*intentionally* *installed* has been wiped out by some well meaning
bozo who doesn't think I don't keep the Adobe Reader or several dozen
other programs up to date that almost everybody uses.  If you have a
magical means of making sure iconv.dll is kept thoroughly up to date
FOR GOD'S SAKE PLEASE USE IT!  And put the iconv.dll file that all FSF
(Gnu) software that uses it in the system folder.  The only valid reason
I see for the same DLL having multiple versions is if each piece of
software is tailor made to use only that version of the DLL.  When that
happens - put it in the relevant %ProgramFiles% folder.  PLEASE!  I am
just telling you the best way to do it according to the Microsoft way
of doing things.  I don't make the rules - they do!  Okay, maybe it is
only my take on it but please tell me where I am going wrong. In the
*.exe code I would search first for the relevant file in the relevant
%ProgramFiles% folder, then look for it in %SystemRoot%\system32. Why?
If you are dependant on something that is specific you get it.  If it
is enough to get what every other program uses, then you still get what
you need.  Specific first, generic second is the order of the day.

I also gave the newbie user my advice for what I do for command line use
of gpg (using cmd.exe - ALL OF WHICH IS NON-STANDARD AND WHY I USUALLY
DON'T POST IT - ***ANYWHERE*** - I am finally making an exception):

mkdir %SystemDrive%\bin
cd \progra~1\GNU\GnuPG
copy *.exe %SystemDrive%\bin
REM in all of this both %SystemDrive% and %HomeDrive% are usually
REM "C:".  If you type set you can see all of your environment vars

I also have \util (my own separate compiled utilites) and \Scripts
(for my own scripts *.bat, *.vbs, *.js, etc.) folders.  They were all
meant to be used in cmd.exe.  Now some of this (primarily the bin) may
conflict with CygWin, MinGW, or something else like that.  Since I only
need two or three things though, when I go into Control Panel ->
System -> Advanced -> Environment Variables it is nice to just have
to add those three folders to %PATH%.  The only thing is you have to
remember to copy files every time you upgrade a package.  If Microsoft
would have made it simply "Programs", or even better yet "Progs", I
would be happy to keep adding those paths for command line use until
I arrive at too many and run out of path space.  Don't laugh - it HAS
happened to me more times than I want to count!  That includes both
'NIX and Windows systems!  That is why I have taken to modifying even
SYSTEM files on 'NIX to *SET* the path the way I want it, not to just
add to it. That is also good advice on the perms on files, etc. on 'Nix
when you do install  SET IT!  DO NOT ADD TO THE DEFAULT (which assumes
it is going to be thus and thus). What is needed on MS Windows is a
%SystemDrive%\Extras folder for all of these things, and THAT *IS*
beyond the scope of this News Group.  I do suggest that Microsoft should
do that itself and as soon as possible to avoid this /opt versus
/usr/local problem 'nix people face.  I already gave them one suggested
name.  BUT THEY should NOT make the darn thing have a SPACE in it! I
have had to combat that space character in my scripts far longer than
I want to!  Telling me that it will be sdhfjy~1 isn't going to cut it.
I have been bit by that one too.  Sometimes it is ~2 or ~3. The only
way around that accursed space character (which can be avoided with
proper casing despite Windows being case insensitive) is to quote
EVERYTHING.  Sometimes even that becomes very difficult when you do
not know in advance what is going to be tacked on.

*ALL* of this IS in harmony with the GNU / FSF philosophy.  We
empower people to make their *OWN* decisions on what is appropriate
for them.  "Very Newbie" no longer needs my help.  He is smart!
So you are you John - I am just letting you know that what was
provided that works with perhaps over 90% of the users doesn't
work for me and may not work for others.  Now you and they know
why it does not work and WHY I gave the advice I did.  If you don't
like the format, distill it handle almost all of the rest of the
cases. They can promptly ignore my suggestions if they run as an
administrative user all the time(which is what your install probably
handles).  I am just as loathe to run as an Administrative user on
Microsoft Windows when interacting with the Internet as I am on 'nix
machines.  Perhaps I am even more reluctant on MS Windows. Now they
have what is needed to handle they can handle ANY situation.  As an
aging Mathematician (yes I have the degree for the statement) I ask
them only one thing - BE CONSISTENT.  If you aren't consistent it
will kill you.  Sloppy control of any system will kill you.


HHH