view release on metacpan or  search on metacpan

FAQ  view on Meta::CPAN

0.  'What's the interface to the penguin mailing list?'

    Unfortunately, there is no list at the moment.

1.  'What's the list for?'

    If it existed, which it, again unfortunately, no
    longer does, it would be for discussing how to mess
    around with Penguin.

2.  'Who does development and why?'

    I do, with huge indirect and theoretical help from Tim Bunce.
    I work alone whenever I can steal a moment from my horrifically
    involved job as bizarre internet appliance hacker for Data General.
    Nobody pays me for Penguin, and I'm not sure yet what my 
    motivation is. :)

3.  'Where is Penguin at in completionspace?'

    Penguin needs a few more things before I'm actively happy with
    letting it go out into the world and kill java.  However, since
    some of these things are way beyond my control, it'll probably
    have to go out early.  We need:

    a.  A firmed-up digital signature method that doesn't require
        as much external stuff.  Depends on: PGP-3.0, or finding a
        different, smaller algorithm.  Note that PGP3 is several
        years late.

    b.  A set of well-known basic classes and a framework for implementing
        further classes that permit programs executing on a remote machine
        to use the power of normally-unsafe operations in a safe way.
        Depends on: time, manpower.

    c.  A graphical user interface class.  Depends on: huge time,
        huge manpower, or Perl/Tk getting much much smaller.

    d.  A rewrite in XS.

    e.  A safety guarantee (perl experts ensuring that it really does
        what it should).

    All in all, I think we're about 91% done with the base part of
    Penguin (although Tim's efforts rewriting Safe will substantially
    alter that in one direction or another), and 44% done with 
    Penguin-as-Internet-domination-engine.  Both of which statements
    should be construed as a call for assistance and bug reports. :)

4.  'How can I help?'

    a.  Try to use the code.  

    b.  Look at the code.  See if it makes any sense, or if you can
        offer improvements, even if they're just verbal and not
        context diffs.  

    c.  Think about the concept and share your thoughts.  The
        design of Penguin is open, and apart from a strange willingness
        to do all of the busywork, I have no vested interest in
        one way of doing it over another.

    d.  Send code.  If you send me cool code, I will buy you beer.

5.  'Saaaay, what _is_ the design of Penguin?'

    Glad you asked.

    Consider two machines, foo and bar.  A user on foo (or perhaps
    a program on foo) wishes to execute a program on machine bar.
    However, imagine that the people running bar don't want just
    anyone running code on their machine for security reasons.
    This is the normal case on the Internet, and one which the
    World Wide Web attempts to emulate with HTTP and CGI.

    Normally, there is no well-known channel for foo to transmit
    code to bar.  Further, there is no provision for the code to
    undergo verification after transmission.  Too, there is no
    well-defined way for bar to ensure that foo's code does not
    attempt to perform insecure or damaging operations.

    Penguin attempts to solve these issues while making sure the
    code language maintains some acceptable degree of sufficiency
    and power.
    
    Using Penguin, the user/program on foo 'digitally signs' the
    code that's earmarked for delivery to bar.  The signature
    encodes the code in such a way that it is impossible to alter
    the code or deny that the signer signed it.

    The code is then wrapped up into a packet and transmitted
    through a 'channel' to a Penguin process running on machine
    bar.  The channel's protocol layer is abstracted away
    enough that it becomes unimportant; Penguin code can just 
    as easily be delivered through SMTP or AOL Mail as through
    TCP/IP, DECNet, AppleTalk, whatever.

    The Penguin process on bar unwraps the packet, which contains
    further verification and checksum information, and then
    'digitally unsigns' the code, a process which provides the
    code in 'clear' form while telling the receiver who digitally
    signed it.

    The receiver then cross-references the signer's identity with
    a list of rights that the receiver associates with the signer,
    reverting to a set of default rights if the signer is unknown
    or unlisted.

    A safe compartment is then created, populated with the
    functions allowed to the signer, and told to limit the
    operations it can perform to only those permitted to the
    signer.

    The code is then compiled within that safe compartment.  If
    it attempts to do something which the signer is not allowed
    to do, or if it attempts to call a function not permitted
    to the signer, the compartment immediately traps the operation
    and throws the code away before it can execute.  If the code
    uses no unsafe or illegal operations, then it executes and
    produces a result.