PhotoCatalog OAuth support and Bytecode
Loren M. Lang
I've been working on compiling the OAuth client as Perl bytecode so we
can distribute it along with the rest of PhotoCatalog, but had some
issues. The FAQ entry for compiling Perl into Bytecode or C starts out
with this:
"In general, you can’t do this. There are some things that may work for
your situation though."
It then mentions PAR (Perls version of JAR), and B::Bytecode. It also
mentions some commercial for fee compilers. Since B::Bytecode was
included with Perl on Ubuntu 8.04 I decided to try it out. After
compiling the module and loading it, updatelocation.pl ran correctly but
segment faulted on exit. I created a small module that does nothing at
all, compiled it, and included it with updatelocation.pl and it still
segment faulted on exit, but otherwise ran OK.
Thinking Ubuntu 8.04 might just have a buggy version of the Bytecode
interpreter, I tried it on 8.10 only to find the ByteLoader library
missing. I searched the package database and couldn't find it. on
8.04, ByteLoader was a part of the perl package. Next I looked at 10.04
and still no ByteLoader. I'm not sure what happened to it, but it
appears to no longer be bundled with Perl. I looked at the FAQ entry on
newer versions of Perl and they removed B::Bytecode from the entry; it
only mentions PAR and the commercial compilers. PAR appears to simply
be a way to bundle files together and not a bytecode compiler.
Perl does support compiling C code as Perl modules which is well
supported. That how modules like XML::LibXML work which link Perl code
with the LibXML C library, but then we would be distributing
platform-dependent binary blobs with PhotoCatalog instead of
platform-independent Perl bytecode.
The module I am trying to distribute is simply a small Perl module that
makes requests for OAuth signatures against my OAuth signing server.
Even with a binary module, anyone could use the module (with Perl)
outside of PhotoCatalog, the main purpose of obfuscating it would be to
avoid someone (easily) figuring out the protocol and writing their own
client in any language they see fit. It's still not difficult to
disesct the module even as Bytecode since they could just replace LibWWW
Perl that I use for calling back to the OAuth server. Should we just
distribute the client as source? We could still require them to
register a client token with us in order to use our server which then
allows them to sign against any number of services we use OAuth for.
--
Loren M. Lang
lor...@north-winds.org
http://www.north-winds.org/
Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc
Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B