Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Invalid vCard v2.1 with base64 encoded public key #21

Closed
GoogleCodeExporter opened this issue Mar 21, 2015 · 7 comments
Closed

Invalid vCard v2.1 with base64 encoded public key #21

GoogleCodeExporter opened this issue Mar 21, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1.Create vCard v2.1 with a BASE64-encoded public key
2.Open vCard in Outlook 2010
3.Outlook does not find the public key (under 'Certificates')

What version of ez-vcard are you using?
0.9.6

What version of Java are you using?
1.7

Please provide any additional information below.
I had to add a newline ('\r\n') after the BASE64-encoded public key. The '\r\n' 
is also the BASE64 chunking delimeter, and the single '\r\n' at the end of the 
key is not being read as the end of the 'KEY' value.

Original issue reported on code.google.com by siegelm...@gmail.com on 5 Nov 2014 at 10:00

Attachments:

@GoogleCodeExporter
Copy link
Author

Note: I only tested it with vCard v2.1 (as this is my requirement)

Original comment by siegelm...@gmail.com on 5 Nov 2014 at 10:12

@GoogleCodeExporter
Copy link
Author

Thanks for the report.  I committed a fix in r1069.

Does Outlook 2010 also have trouble parsing other binary data, such as photos?  
The fix I've committed will only insert an extra "\r\n" for KEY properties.  I 
am wondering if I should add that extra newline for the other properties that 
use base64-encoded data too.  Thanks.

Original comment by mike.angstadt on 5 Nov 2014 at 11:50

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Thanks for the quick fix, happy to help out. Good question, haven't given it a 
shot with anything other than a KEY. I'm going to speculate that any folded 
base64 encoded data would be handled the same way, and they're not delineating 
(right or wrong) between a line fold and end of data.

Original comment by siegelm...@gmail.com on 6 Nov 2014 at 1:56

@GoogleCodeExporter
Copy link
Author

Just test Photo with Outlook 2010, worked fine w/o the extra new line (see 
attachment).

Original comment by siegelm...@gmail.com on 6 Nov 2014 at 3:08

Attachments:

@GoogleCodeExporter
Copy link
Author

When I added both a photo and sound, I had to have the extra blank line after 
the sound in order for the photo to show up in Outlook. Attached both versions. 
There's no way in Outlook to play the sound, so in both cases I don't know 
whether or not it's handling that correctly or not.

Original comment by siegelm...@gmail.com on 6 Nov 2014 at 3:22

Attachments:

@GoogleCodeExporter
Copy link
Author

I guess I will add a blank line after all base64 values then (see r1071).  
Hopefully, it does not break any other mail clients.

Thank you for testing this.  I don't do as much testing against real-world mail 
clients as I should.  Please let me know if you stumble upon any other issues!

Original comment by mike.angstadt on 9 Nov 2014 at 2:26

@mangstadt
Copy link
Owner

Updated in issue 33.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants