[Bug] vBinary class causes image bytes to become corrupt

[FilipAtanasovski-dev]

Describe the bug

The vBinary class corrupts image files if loaded in.

To reproduce

from icalendar import vBinary
import base64

# 1. Create a small "image" payload (pretend PNG header + fake data)
original_bytes = (
    b"\x89PNG\r\n\x1a\n"  # PNG signature
    b"\x00\x00\x00\rIHDR"  # fake chunk
    b"\x00\x00\x00\x01\x00\x00\x00\x01"
)

# 2. Wrap it into vBinary
vb = vBinary(original_bytes)

# 3. Serialize to iCal base64 form
ical_encoded = vb.to_ical()

# 4. Decode back using the library method
decoded_bytes = vBinary.from_ical(ical_encoded)

# 5. Save both to files for comparison
print("Original bytes:", original_bytes)
print("Decoded bytes:", decoded_bytes)

print("Match:", original_bytes == decoded_bytes)
### ...

Output:

Original bytes: b'\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x00\x01\x00\x00\x00\x01'
Decoded bytes: b'\xef\xbf\xbdPNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x00\x01\x00\x00\x00\x01'
Match: False

Expected behavior

Original bytes: b'\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x00\x01\x00\x00\x00\x01'
Decoded bytes: b'\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x00\x01\x00\x00\x00\x01'
Match: True

Environment

• Operating system: Windows 11
• Python version: 3.13.1
• icalendar version: 7.0.4.dev127

Additional context

• I tested it with the latest version. For example, I used the command pip3 install --upgrade https://github.com/collective/icalendar.git.
• I attached the .ics sample file, or there is no .ics sample file.

[niccokunzmann]

I see this:

    def to_ical(self) -> bytes:
        return binascii.b2a_base64(self.obj.encode("utf-8"))[:-1]

Since it is supposed to be a binary representation, it should actually operate with bytes.
UTF-8 encoding and decoding should not happen, really.

The fix I would suggest:

• Revert changes to IMAGE in the factory file - this flags up the errors
• report those errors and have a discussion on how to approach them in this issue

Possible further path to fix this:

• introduce vBinary.bytes with type bytes (possibly a property)
• use bytes as the base wherever possible
• create a property for vBinary.obj which then returns the string data, getter + setter
• create a deprecation warning when using the .obj property? That is to discuss...
• make sure we test the desired behaviour thoroughly
• document in the vBinary class which way to use it is the best way

The .obj property works in many cases - e.g. when the content is expected to be utf8 e.g. an attachment of an html file.

What are your thoughts on this?

Related:

• 876/vBinary #1274
• bug: X-properties with VALUE param now parsed as correct type (fixes … #1288

[baodq06]

Hi! I’m a University of Michigan student in EECS 481, and I’m planning to contribute to this project over the next few weeks for a course assignment. I’m currently interested in working on this issue and wanted to ask whether it seems like a good fit for an outside contributor right now. If there are any preferences about approach, testing, or scope, I’d really appreciate the guidance.

[stevepiercy]

@baodq06 thanks for your interest! In @niccokunzmann's comments, one of the todos is a discussion of how to approach it. It appears that the discussion hasn't taken place, so any approach is on the table.

Meanwhile see our guide for how to Contribute.

[niccokunzmann]

@baodq06 Thanks for taking this up! Yes, I would say: please work on it. It is also good for an outside collaborator. In contrast to 'just solving an issue', this issue specifically asks of @FilipAtanasovski-dev to give an input on the possible path of implementation that I proposed if that will solve the issue. So, as a FOSS starting point, you get more: a contribution to a project on the basis of code as well as mentoring and interacting in the FOSS ecosystem and learning about how to solve an issue through communication. So, because communication might take a while, thanks for getting in touch early and registering the interest! I suggest, getting to know the code and the specific change/bug/regressions for this particular issue and starting with the communication/ideas on how you see this can be approached to provide stability and usability to developers. I suggest: try to recreate the issue on your computer, ask for more details and evaluate how the changes we made in 7.x impact using this feature of icalendar. The code problem is clearly described. The approach to solving it requires some creativity and communication. We maintainers will follow the communication, feel free to ask questions and work in your own pace. Thanks!