[
https://issues.apache.org/jira/browse/AXIS2C-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Lazarski resolved AXIS2C-976.
------------------------------------
Resolution: Won't Fix
Changing this would be a breaking API change that could introduce
security vulnerabilities (buffer overflows) in existing code. The
current behavior is actually safer for the common use case of
allocating a buffer before encoding.
I added implementation comments in the code:
- axutil_base64_encode_len() - Explains the +1 is for null terminator
and references AXIS2C-976
- axutil_base64_encode_binary() return statement - Notes it "returns
total bytes written including null terminator (allocation size, not
strlen)"
- EBCDIC version return statement - Same clarification
> base64 encode length returns size of encoded string + 1.
> --------------------------------------------------------
>
> Key: AXIS2C-976
> URL: https://issues.apache.org/jira/browse/AXIS2C-976
> Project: Axis2-C
> Issue Type: Bug
> Components: util
> Affects Versions: 1.3.0
> Reporter: Senaka Fernando
> Priority: Major
>
> base64 encode length returns size of encoded string + 1, which is incorrect.
> This is because we assume that someone expects the length + 1 to accommodate
> '\0' that we add. But, if we gave the same string to a strlen() it returns
> size of encoded string. This would confuse a potential user.
> axutil_base64_encode (encoded, "senaka", 6) = 9, and strlen(encoded) = 8.
> Also, axutil_base64_encode_len(6) = 9.
> Therefore, I think it is better to stick to the strlen() way, especially
> because popular libraries and resources adopt that strategy. Refer [1] for
> more information.
> [1] http://www.obviex.com/Articles/CiphertextSize.aspx
> Regards,
> Senaka
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
