Notice: Undefined offset: 68 in /var/www/codoforum/sys/CODOF/Forum/Category.php on line 241

Notice: Trying to get property 'cat_name' of non-object in /var/www/codoforum/sys/CODOF/Forum/Category.php on line 241

Notice: Undefined offset: 68 in /var/www/codoforum/sys/CODOF/Forum/Category.php on line 242

Notice: Trying to get property 'cat_alias' of non-object in /var/www/codoforum/sys/CODOF/Forum/Category.php on line 242

Notice: Undefined offset: 68 in /var/www/codoforum/sys/CODOF/Forum/Category.php on line 238

Notice: Trying to get property 'cat_pid' of non-object in /var/www/codoforum/sys/CODOF/Forum/Category.php on line 238
Some bugs regarding key selection of multiple identities, each with a different PGP key | PMAIL COMMUNITY
Encryption
Some bugs regarding key selection of multiple identities, each with a different PGP key

[quote user="idw"][quote user="rgl"]I have observed two strange behaviors regarding the automatic selection of private keys depending on the current mail identity. Both behaviors seem to be related. 

Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to

PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain

english versions with no internationalization.[/quote]

Ok, tested on Windows 7 with PGP 10.0.3: No such issue, correct key is pre-selected and used. Maybe testing on XP with PGP 8.1 or 6.5.8 will reveal a different result.[/quote]

Testing on XP with PGP 6.5.8 (the regular one) doesn't fail either: It automatically preselects the proper (matching) key in the dialog using the cached passphrase for signing with exactly this (pre)selected key. Nothing I can do, sorry, there must be something else involed: Maybe using non-regular and heavily outdated PGP versions isn't the best idea ...

[quote user="idw"][quote user="rgl"]I have observed two strange behaviors regarding the automatic selection of private keys depending on the current mail identity. Both behaviors seem to be related.  <p>Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain english versions with no internationalization.[/quote]</p><p>Ok, tested on Windows 7 with PGP 10.0.3: No such issue, correct key is pre-selected and used. Maybe testing on XP with PGP 8.1 or 6.5.8 will reveal a different result.[/quote]</p><p>Testing on XP with PGP 6.5.8 (the regular one) doesn't fail either: It automatically preselects the proper (matching) key in the dialog using the cached passphrase for signing with exactly this (pre)selected key. Nothing I can do, sorry, there must be something else involed: Maybe using non-regular and heavily outdated PGP versions isn't the best idea ...</p>
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

Hi,

I have observed two strange behaviors regarding the automatic selection of private keys depending on the current mail identity. Both behaviors seem to be related.

Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to

PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain

english versions with no internationalization.

 

First observation:

In the former versions the selection of the correct private key worked like a charm, but in the

new versions (with same settings) it seems that always the first

available key will be proposed.


Second behavior that is worse, especially in combination to the first one:

When sending an email by one identity with one private key, the

passphrase will be correctly cached like it has been set up in the

options, but when sending an email by another identity with

another private key, the passphrase of the formerly used private key is

used together with the newly proposed private key (see also first

problem above) without any dialog box appearing and even without any

chance to select the key manually.

Since this short description might sound a little bit confusing, here is a step-by-step test case for you to reproduce the scenario:

First the environment:

- There are two Pegasus identies (id1 and id2).

- Each identity has a different email address (user1@domain1.tld and user2@domain2.tld)

- Each email adress has a different private key (key1 and key2) in the PGP keyring, but both with the same passphrase.

-

The first identity (id1) is marked as the main identity inside the PGP

keyring. (I don't know if this detail matters, since "use default key"

is disabled anywhere in PGP and in PMPGP, at all.)

- The default action configured in Pegagus options for any emails is signing only, means signing is enabled and encryption is diabled by default.

-

The PMPGP options "Auto encryption" and "Auto key selection" are

disabled. (Just to be sure, I also tried enabling "Auto key selection" which (expectedly, since Auto encryption is off) had no

effect on our test case here.)

Now the actions:

1. Write a new email using id2 to a completely unrelated receiver

address and press the send button. (Mind that "Signing" is

automatically enabled, "Encrypting" is disabled, see above: default

actions of Pegasus)

2. Dialog of PMPGP appears with a dropdown list containing both

key1 and key2. The key1 is selected. One would have expected to see the

key2 here.

3. Select key2 which matches the sender address, enter

the passphrase and confirm, so that the email is being signed signed by

PMPGP and sent by Pegasus.

4. Write another new email using id2

(same as in first email) to the same (unrelated) receiver address and

press the send button within the timespan of passphrase caching since

sending the previous email.

5. No dialog of PMPGP appears. Instead the email is being signed with

key1 (auto-selected like in 2.?) using the cached passphrase of key2

(which is in this test case identically to the passphrase of key1) and

the mail is being sent without any further user interaction using the

wrong key.

6. Write another new email using id1 to the same (unrelated) receiver address and press the send button, again within the timespan of passphrase caching since sending the previous email.

7.

Like in 5. no dialog of PMPGP appears. Instead the email is being

signed with key1 (auto-selected like in 2.?) using the cached

passphrase of key2 (which is in this test case identically to the

passphrase of key1) and the mail is being sent without any further

user interaction using the correct key, but this might be by chance in this

case.

 

Thanks in advance for your attention and help :)

Sincerely,

Rainer

 

(edited: adding the operating systems to the migration detail info and fixed two typos)

<p>Hi,</p><p>I have observed two strange behaviors regarding the automatic selection of private keys depending on the current mail identity. Both behaviors seem to be related. </p><p>Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain english versions with no internationalization.</p><p> </p><p>First observation: </p><p>In the former versions the selection of the correct private key worked like a charm, but in the new versions (with same settings) it seems that always the first available key will be proposed.</p><p> </p><p>Second behavior that is worse, especially in combination to the first one: </p><p>When sending an email by one identity with one private key, the passphrase will be correctly cached like it has been set up in the options, but when sending an email by another identity with another private key, the passphrase of the formerly used private key is used together with the newly proposed private key (see also first problem above) without any dialog box appearing and even without any chance to select the key manually.</p><p>Since this short description might sound a little bit confusing, here is a step-by-step test case for you to reproduce the scenario:</p><p>First the environment:</p><p>- There are two Pegasus identies (id1 and id2).</p><p>- Each identity has a different email address (user1@domain1.tld and user2@domain2.tld)</p><p>- Each email adress has a different private key (key1 and key2) in the PGP keyring, but both with the same passphrase.</p><p>- The first identity (id1) is marked as the main identity inside the PGP keyring. (I don't know if this detail matters, since "use default key" is disabled anywhere in PGP and in PMPGP, at all.)</p><p>- The default action configured in Pegagus options for any emails is signing only, means signing is enabled and encryption is diabled by default.</p><p>- The PMPGP options "Auto encryption" and "Auto key selection" are disabled. (Just to be sure, I also tried enabling "Auto key selection" which (expectedly, since Auto encryption is off) had no effect on our test case here.) </p><p>Now the actions: </p><p>1. Write a new email using id2 to a completely unrelated receiver address and press the send button. (Mind that "Signing" is automatically enabled, "Encrypting" is disabled, see above: default actions of Pegasus) </p><p>2. Dialog of PMPGP appears with a dropdown list containing both key1 and key2. The key1 is selected. One would have expected to see the key2 here.</p><p>3. Select key2 which matches the sender address, enter the passphrase and confirm, so that the email is being signed signed by PMPGP and sent by Pegasus.</p><p>4. Write another new email using id2 (same as in first email) to the same (unrelated) receiver address and press the send button within the timespan of passphrase caching since sending the previous email. </p><p>5. No dialog of PMPGP appears. Instead the email is being signed with key1 (auto-selected like in 2.?) using the cached passphrase of key2 (which is in this test case identically to the passphrase of key1) and the mail is being sent without any further user interaction using the wrong key. </p><p>6. Write another new email using id1 to the same (unrelated) receiver address and press the send button, again within the timespan of passphrase caching since sending the previous email.</p><p>7. Like in 5. no dialog of PMPGP appears. Instead the email is being signed with key1 (auto-selected like in 2.?) using the cached passphrase of key2 (which is in this test case identically to the passphrase of key1) and the mail is being sent without any further user interaction using the correct key, but this might be by chance in this case. </p><p> </p><p>Thanks in advance for your attention and help :)</p><p>Sincerely,</p><p>Rainer </p><p> </p><p>(edited: adding the operating systems to the migration detail info and fixed two typos) </p>

[quote user="rgl"]Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to

PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain

english versions with no internationalization.

First observation: 

In the former versions the selection of the correct private key worked like a charm, but in the

new versions (with same settings) it seems that always the first

available key will be proposed.[/quote]

Wow, someone (aside from me) is still using PGP, I'm really surprised ...

As can already be seen by the length of your post this is an extremely complex issue - and even more complex if you don't tell me what version of PGP you're using and whether it was updated in due course as well. Can you please add this information before I start digging into this issue (this is important since PGP changed its own default key handling starting with version 9)?

Edit: And if you updated PGP did you test PMPGP 6.2.7.4 on the old machine with the previous version?

[quote user="rgl"]Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain english versions with no internationalization.<p>First observation:  </p><p>In the former versions the selection of the correct private key worked like a charm, but in the new versions (with same settings) it seems that always the first available key will be proposed.[/quote]</p><p>Wow, someone (aside from me) is still using PGP, I'm really surprised ... </p><p>As can already be seen by the length of your post this is an extremely complex issue - and even more complex if you don't tell me what version of PGP you're using and whether it was updated in due course as well. Can you please add this information before I start digging into this issue (this is important since PGP changed its own default key handling starting with version 9)?</p><p>Edit: And if you updated PGP did you test PMPGP 6.2.7.4 on the old machine with the previous version?</p>
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

Hi Michael,

yes, of course some people out there really use PGP instead of GnuPG or other implementations - apart from myself I do know of at least even two more... ;)

Sorry for my lapse of forgetting to mention the PGP version itself: I still use PGP 6.5.8 ckt (Build 08) since this version was the last one not including an ADK.

If PGP respectively PMPGP supports a newer version of PGP that does not has the ADK issue (means later than 8), I'd consider a major upgrade, but have not done yet because of the rule to never change a running system without a good reason. Last but not least I'm looking forward to the upcoming PMail 5... :)

Finally I have seen the information on your website at http://www.pmpgp.de/pmpgp/historyde.htm#limits stating that the current PMail (since version 4.7) does not support 6.5.x anymore which was another reason for me to stick as close as possible to the known environment for the time being.

<p>Hi Michael,</p><p>yes, of course some people out there really use PGP instead of GnuPG or other implementations - apart from myself I do know of at least even two more... ;)</p><p>Sorry for my lapse of forgetting to mention the PGP version itself: I still use PGP 6.5.8 ckt (Build 08) since this version was the last one not including an ADK.</p><p>If PGP respectively PMPGP supports a newer version of PGP that does not has the ADK issue (means later than 8), I'd consider a major upgrade, but have not done yet because of the rule to never change a running system without a good reason. Last but not least I'm looking forward to the upcoming PMail 5... :) </p><p>Finally I have seen the information on your website at http://www.pmpgp.de/pmpgp/historyde.htm#limits stating that the current PMail (since version 4.7) does not support 6.5.x anymore which was another reason for me to stick as close as possible to the known environment for the time being. </p>

[quote user="rgl"]I have observed two strange behaviors regarding the automatic selection of private keys depending on the current mail identity. Both behaviors seem to be related. 

Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to

PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain

english versions with no internationalization.[/quote]

On a first check (by comparing source code of both versions) I don't see any code dealing with this having changed. Since it's a complex issue as mentioned before I guess I need to create a test case now ... but maybe you should test my latest (unreleased) version first, please contact me via email (PMPGP's About ... dialog provides the address, e.g.) for doing so.

[quote user="rgl"]I have observed two strange behaviors regarding the automatic selection of private keys depending on the current mail identity. Both behaviors seem to be related.  <p>Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain english versions with no internationalization.[/quote]</p><p>On a first check (by comparing source code of both versions) I don't see any code dealing with this having changed. Since it's a complex issue as mentioned before I guess I need to create a test case now ... but maybe you should test my latest (unreleased) version first, please contact me via email (PMPGP's <em>About ...</em> dialog provides the address, e.g.) for doing so.</p>
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

[quote user="rgl"]I have observed two strange behaviors regarding the automatic selection of private keys depending on the current mail identity. Both behaviors seem to be related. 

Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to

PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain

english versions with no internationalization.[/quote]

Ok, tested on Windows 7 with PGP 10.0.3: No such issue, correct key is pre-selected and used. Maybe testing on XP with PGP 8.1 or 6.5.8 will reveal a different result.

[quote user="rgl"]I have observed two strange behaviors regarding the automatic selection of private keys depending on the current mail identity. Both behaviors seem to be related.  <p>Before that I migrated from PMail 4.51 with PMPGP 6.2.7.1 on Windows XP SP3 32bit to PMail 4.62 with PMPGP 6.2.7.4 on Windows 7 SP1 64bit, both Pegasus and PMPGP were the plain english versions with no internationalization.[/quote]</p><p>Ok, tested on Windows 7 with PGP 10.0.3: No such issue, correct key is pre-selected and used. Maybe testing on XP with PGP 8.1 or 6.5.8 will reveal a different result.</p>
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft