Skip Menu |

This queue is for tickets about the Authen-Passphrase CPAN distribution.

Report information
The Basics
Id: 129761
Status: new
Priority: 0/
Queue: Authen-Passphrase

Owner: Nobody in particular
Requestors: ether [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Subject: Need explicit documentation about characters vs. octets - or, the unicode problem
Download (untitled) / with headers
text/plain 774b
Bugs like show that it's pretty easy to pass a wide-char-containing string along to Authen::Passphrase without realizing that, somewhere along the way, it needs to be utf8_encoded first. Since crypt (in perlfunc) is documented to require octets, it would seem that e.g. Crypt::Eksblowfish::Bcrypt::bcrypt_hash should also take octets, but it's unclear at what point before that the utf8 encoding should be done. Should $authen_passphrase_obj->match(PASSPHRASE) take octets, or characters? i.e. should Authen::Passphrase::* do the encoding, or should the caller? Either way, it needs to be clearly documented what layer is doing the encoding and whether callers should be passing unencoded characters, or encoded octets.
Download (untitled) / with headers
text/plain 646b
As far as DBIx::Class::PassphraseColumn's usage of this distribution is concerned, I believe I have fixed the problem in, by utf8-encoding all payloads before passing them to Authe::Passphrase. It would be great to have this requirement documented in Authen::Passphrase, as adding encoding after-the-fact to an existing application does break backward compatibility (all existing non-ascii latin1 passphrases are rendered unusable because they encode differently now) -- therefore users should be informed of the requirement to perform utf8 encoding right from the start.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to