| Summary | Use of raw_data in Horde_Crypt_Blowfish_Openssl |
| Queue | Horde Framework Packages |
| Type | Bug |
| State | Assigned |
| Priority | 1. Low |
| Owners | Horde Developers (at) |
| Requester | almarin (at) um (dot) es |
| Created | 06/24/2015 (3661 days ago) |
| Due | |
| Updated | 03/08/2016 (3403 days ago) |
| Assigned | 03/08/2016 (3403 days ago) |
| Resolved | |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Assigned
State ⇒ Feedback
format? Of course in both encrypt/decrypt operations
output to be binary and portable.
We can probably change the logic in Horde_Session#get() to first check
if the data is encrypted, and only check for the NOT_SERIALIZED flag
if it is not. Do you by chance have some example data that produces
leading NULs during encryption, so we can create a unit test?
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Use of raw_data in Horde_Crypt_Blowfish_Openssl
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
operations, so the result can be any binary string, even a string
starting with \0 at the beginning.
That causes issues like in Horde_Session, where values starting with
\0 are considered NOT_SERIALIZED and are returned unencrypted
(https://github.com/horde/horde/blob/master/framework/Core/lib/Horde/Session.php#L355)
Can be replaced with $raw_data = false to force the use of base64
format? Of course in both encrypt/decrypt operations