Bug #70797 for Mail-GnuPG: Proposed patch for Mail::GnuPG

Wed Sep 07 16:10:13 2011 nathan [...] packetmail.net - Ticket created

Subject:	Proposed patch for Mail::GnuPG
Date:	Wed, 7 Sep 2011 15:10:02 -0500
To:	"bug-Mail-GnuPG [...] rt.cpan.org" <bug-Mail-GnuPG [...] rt.cpan.org>
From:	Nathan <nathan [...] packetmail.net>

Hello, I respectfully submit the below patch for review and comments. It seems that the handling of multipart is not compatible with all PGP clients. The below patch resolves this issue and allows these clients to work as expected. I also believe this format to be closer to what traditional OpenPGP and PGP clients produce. --- /usr/share/perl5/Mail/GnuPG.pm 2008-05-20 06:37:01.000000000 -0500 +++ /usr/share/perl5/Mail/GnuPG.pm 2011-09-07 14:29:28.000000000 -0500 @@ -901,13 +901,14 @@ $entity->attach(Type => "application/pgp-encrypted", Disposition => "inline", - Filename => "msg.asc", + Filename => "Version.txt", Data => ["Version: 1",""], Encoding => "7bit"); $entity->attach(Type => "application/octet-stream", Disposition => "inline", Data => [@ciphertext], - Encoding => "7bit"); + Encoding => "7bit", + Filename => "message.asc"); $entity->head->mime_attr("Content-Type","multipart/encrypted"); $entity->head->mime_attr("Content-Type.protocol","application/pgp-encrypted"); I look forward to your comments if any. Thanks, Nathan

Sun Sep 11 11:45:18 2011 jesse [...] fsck.com - Correspondence added

Subject:	Re: [rt.cpan.org #70797] Proposed patch for Mail::GnuPG
Date:	Sun, 11 Sep 2011 11:45:16 -0400
To:	bug-Mail-GnuPG [...] rt.cpan.org
From:	Jesse Vincent <jesse [...] fsck.com>

Hi Nathan, Can you give me a bit more to go on about what we're doing that's not RFC-compliant or making other clients choke? Which clients are failing? Thanks. On Sep 7, 2011, at 4:10 PM, Nathan via RT wrote: Show quoted text

> Wed Sep 07 16:10:13 2011: Request 70797 was acted upon. > Transaction: Ticket created by nathan@packetmail.net > Queue: Mail-GnuPG > Subject: Proposed patch for Mail::GnuPG > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: nathan@packetmail.net > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=70797 > > > > Hello, I respectfully submit the below patch for review and comments. It seems > that the handling of multipart is not compatible with all PGP clients. The > below patch resolves this issue and allows these clients to work as expected. I > also believe this format to be closer to what traditional OpenPGP and PGP > clients produce. > > --- /usr/share/perl5/Mail/GnuPG.pm 2008-05-20 06:37:01.000000000 -0500 > +++ /usr/share/perl5/Mail/GnuPG.pm 2011-09-07 14:29:28.000000000 -0500 > @@ -901,13 +901,14 @@ > > $entity->attach(Type => "application/pgp-encrypted", > Disposition => "inline", > - Filename => "msg.asc", > + Filename => "Version.txt", > Data => ["Version: 1",""], > Encoding => "7bit"); > $entity->attach(Type => "application/octet-stream", > Disposition => "inline", > Data => [@ciphertext], > - Encoding => "7bit"); > + Encoding => "7bit", > + Filename => "message.asc"); > > $entity->head->mime_attr("Content-Type","multipart/encrypted"); > $entity->head->mime_attr("Content-Type.protocol","application/pgp-encrypted"); > > I look forward to your comments if any. > > Thanks, > Nathan > >

Sun Sep 11 11:45:20 2011 The RT System itself - Status changed from 'new' to 'open'

Sun Sep 11 14:36:28 2011 nathan [...] packetmail.net - Correspondence added

Subject:	Re: [rt.cpan.org #70797] Proposed patch for Mail::GnuPG
Date:	Sun, 11 Sep 2011 13:36:14 -0500
To:	"bug-Mail-GnuPG [...] rt.cpan.org" <bug-Mail-GnuPG [...] rt.cpan.org>
From:	Nathan <nathan [...] packetmail.net>

On 09/11/11 10:45, Jesse via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=70797 > > > Hi Nathan,

Hello Jesse, thank you for your reply. Show quoted text

> Can you give me a bit more to go on about what we're doing that's not RFC-compliant or making other clients choke?

It appears the crux of the issue is that many clients expect the version as version.txt (insensitive) yet this is being attached as "msg.asc". The GPG encoded body presented inline, with no filename, as application/octet-stream causes some clients to bork which are not fully PGP/MIME capable. The proposed patch seems to be more closely aligned with current PGP/GPG mailers. I believe this may be a "current convention" versus "RFC", I have not done sufficient exhaustive research to assert it's an RFC-compliance issue. Show quoted text

> Which clients are failing?

In my limited testing it appears to be any PGP-capable client which hooks the Apple iOS mail application which does not fully support PGP/MIME. This is a non-issue when the MIME content type is text/plain and the message is encoded inline. This is a persistent issue when any multi-part message is encoded PGP/MIME. Show quoted text

> Thanks.

Thank you for your time and reply, please let me know if more information is needed, Nathan