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

People
Owner: Nobody in particular
Requestors: ether [...] cpan.org
Cc:
AdminCc:

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
Bugs like https://rt.cpan.org/Ticket/Display.html?id=92497 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.
As far as DBIx::Class::PassphraseColumn's usage of this distribution is concerned, I believe I have fixed the problem in https://metacpan.org/release/ETHER/DBIx-Class-PassphraseColumn-0.04-TRIAL, 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.