WinPT Portable 1.4.2 Dev Test 6

WinPTPortable\Data\Settings\WinPT.reg

REGEDIT4

[HKEY_CURRENT_USER\Software\WinPT]
"Install Directory"="G:\\PortableApps\\WinPTPortable\\App\\WinPT"
"nKeys"="1"
"KMColumnSize"=hex:ee,00,4e,00,34,00,42,00,3c,00,42,00,3a,00,48,00
"KMSortBy"=hex(5):00,00,00,00
"KM_Pos_X"="283"
"KM_Pos_Y"="307"
"KM_Size_Width"="409"
"KM_Size_Height"="713"
"AlwaysOnTop"="0"
"WipeClipboard"="1"

[HKEY_CURRENT_USER\Software\WinPT\Keyserver]
"Default_Port"="11371"
"Default"="http://subkeys.pgp.net"

WinPTPortableSettings.ini

[WINPTPortableSettings]
LastDriveLetter=G:

Yes. 0.2.2.0 is the value in WinPTPortable\Other\Source\PortableApps.comInstaller.nsi

Regedit when WinPTPortable not running

gpgProgram: C:\Program Files\GNU\GnuPG\gpg.exe
Installer Language: 1033
Lang: en
Start Menu Folder: GNU Privacy Guard

Regedit when WinPTPortable running

gpgProgram: G:\PortableApps\CommonFiles\GnuPG\App\gpg.exe
HomeDir:
OptFile: \gpg.conf

HKCU\Software\GnuPGPortable has ClientCount set to 1 when running and is deleted when app is closed.

Hope this helps.

Have you thought about using gpg.conf as the thing to search for to find the keyring directory?

Actually, we should have an interim WinPT release that uses ThunderbirdPortable\Data\gpg for its default until John does another release. I don't think TBP will use CommonFiles at all, in its current incarnation, so people using WinPT will end up moving their keyrings to TBP directory.

In experimenting with GpaPortable, I found that the following would set up the GnuPGhome directory with empty files -- as a way to make the default directory work if it hasn't been set up yet.

CreateDirectory $GNUPGHOME
FileOpen $0 "$GNUPGHOME\gpa.conf" r
FileClose $0
FileOpen $0 "$GNUPGHOME\gpg.conf" r
FileClose $0
FileOpen $0 "$GNUPGHOME\pubring.gpg" r
FileClose $0
FileOpen $0 "$GNUPGHOME\secring.gpg" r
FileClose $0
FileOpen $0 "$GNUPGHOME\trustdb.gpg" r
FileClose $0

It would work with the gnupghome in TBP too -- just makes sure there's something there for the various programs to detect. Once the programs run, they'll populate the files with appropriate things.

You may have found another way already, but I figured I'd drop this in for the record.

The basic problems with winpt on my side are not in fact with detached sig on files as such. This part seems to work, howevewer winpt will tell you wrong key ID number when verifying such sig. Probably reading the output of the gpg somehow shifted or what. (gpg on cmd will display correct key ID).

Problem is more that when signing text either in clipbord or via the current window, such sig will later fail when vrified. The key is recognised, the user ID displayed correctly, the key ID displayed incorrectly, but all that does not matter so much, simply the text in the clipbord seems to be once more modified after the sig was created and inserted around the text.
Little hint: when let say signed a text in notepad, the clipboard can be flushed, the signed text selected again, but will still give sig =ok.

When such file is closed and opened again, the sig will turn bad.

Same will come up if such text is sent by mail or newsreader etc. Yes I am aware of the line length etc, but in this case all line lenghts are set so that messages and sigs will not be disturbed.
Eg: text with lines of not more then 60 chars, winpt set to 70 and mailclient to 74.
Such text will not be changed, nor will be the sig when passing via the same mailclient in and out (sent to myself)

I am using it with the defoult installation of TB/GPG, the gpg was fould well, so were the keyrings etc. But when I observed why the TB/GPG can also not verify such text, I have seen that apparently the winpt is beside other things asking:
gpg.exe --charset ut8 .....
I have not found the command charset in the manual of gpg (147 and 149) so it could be that there are some commands inserted or applied to gpg which do not exist any more. Should not disturb, but who knows.
I have informed the original author, (TIM) but somehow he has no stright answer and apparently no time to search the problem.

BTW, I checked the functions again some pgp 658, 658ckt, 7.11. When the sig is bad, it will be bad there too, which means not the sig check itself is wrong, but the text was modified after the sig done.

No problems at all when encrypting&signing or enc alone with clipboard functions.