Beautiful Code [163]
One of these was the composition of MIME messages with binary attachments. When the code was built using Persistence::Object::Simple, the cmaild protocol had been circumvented for binary MIME message composition. Attachments uploaded by the user were saved in a temporary directory, which both cmaild and the web server process had access to. Thus, it was necessary to run cmaild and the Cryptonite web interface on the same server.
With the move to Persistence::Object::Postgres, it became possible to easily pass binary objects between the frontend and the backend via the database, without relying on direct filesystem operations. This was important because the interface, the database, and the Cryptonite engine were all intended to run on their own independent servers or in load-balancing clusters.
Input validation (to check the validity of user-supplied inputs, such as folder and message identifiers) was straightforward to add. The Params::Validate module, very slightly modified, was used to add input validation to every method of Cryptonite::Mail::Service. The mvmsgs method, for example, validates its inputs with:
sub mvmsgs { # Move a list of messages to some other mailbox.
my ($self, $username, $key, $dest, $copy, @msgnums) =
(shift, lc shift, shift);
my ($user, $session, $err) = $self->validateuser($username, $key);
return $err if $err;
return $self->cluebat(@{$@}) unless eval {
($dest, $copy, @msgnums) = validate_with ( params => \@_,
extra => [$self], spec = [
{ type => SCALAR, callbacks =>
{ 'Legal Folder Name' => $self->legal_foldername } },
{ type => SCALAR, callbacks =>
{ 'Boolean Flag' => $self->opt_boolean }, optional => 1 },
({ type => SCALAR, callbacks =>
{ 'Legal Message Number' => $self->legal_msgnum } })
x (@_ - 2) ]
)
};
The acceptability of user-supplied input for each type of input field is specified via callback subroutine references stored in a hash in the Cryptonite::Mail::Config module:
LGL_FOLDERNAME => sub { $_[0] =~ /$_[1]->{"VFOLDER"}/i
or die (['EBADFOLDER', $_[0]]) },
OPT_BOOLEAN => sub { $_[0] eq '' or $_[0] eq 0 or $_[0] eq 1
or die (['EBADBOOL', $_[0]]) },
LGL_MSGNUM => sub { $_[0] =~ /$_[1]->{"VMSGNUM"}/
or die (['EBADMSGNUM', $_[0]]) },
Similar subroutines are invoked whenever an input parameter is validated. The regular expressions for validity are stored separately in Cryptonite::Mail::Config.
Even though most of the validation subroutines are essentially the same, they are all distinct, to enable each one to be tweaked as necessary without affecting the others or sacrificing clarity in this part of the code. The validation regular expressions and error strings are stored in a table as well, to enable localization in the future.
Persistence::Object::Postgres also performs its own input sanity checks, to protect against SQL injection attacks.
11.8.2. Auditing Crypt::GPG
Crypt::GPG had been written to be a working prototype and needed complete auditing to eliminate any potential security issues before public testing of the system.
Crypt::GPG had been freely available on CPAN since 2001, and I'd received much valuable feedback from its users. While many users said that they really liked the module's clean and simple interface, some had trouble getting it to run on certain platforms, where the Expect module it used to interact with GnuPG didn't work right. (Expect uses Unix pseudoterminals [ptys] as its IPC mechanism, and that doesn't work on Windows, for example.)
The Expect module's interface and syntax were also somewhat convoluted, which made the code a little difficult to read, as can be seen from this section of the sign method: