1 files changed, 95 insertions, 0 deletions
diff --git a/devel/p5-Penguin/pkg-descr b/devel/p5-Penguin/pkg-descr
new file mode 100644
index 000000000000..2c463078687a
--- /dev/null
+++ b/devel/p5-Penguin/pkg-descr
@@ -0,0 +1,95 @@
+From the FAQ:
+
+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.
+
+    The code executing side then becomes the master in the
+    transaction, and can send code to the original sender,
+    send the return value back in a data packet, and so forth.
+    The process repeats as necessary until both parties are
+    done; the channel then closes, and the Penguin transaction is complete.
+
+    The basic sentiment behind the idea of 'identity' being
+    correlated to 'rights' in the receiver is that in signing
+    the code, the signer commits her identity and her reputation
+    on the correct operation of the code.
+
+    'highly trustable' signers (as one might imagine Larry Wall,
+    Randal Schwartz, and Tom Christiansen to be) might be assigned
+    very high levels of trust and equivalent degrees of 'rights',
+    so that programs they sign can perform very complex and
+    interesting operations on your computer.  By the same token,
+    paranoid sites or those wishing isolation could assign zero
+    rights to everyone except for a select (perhaps internal) few.
+
+    Part of the 'rights' given to signers include possibly specialized
+    functions that encapsulate the functionality of extremely dangerous
+    operations.  For instance, a store opening up on the Internet might
+    put up a Penguin server which put functions called 'list_items'
+    and 'buy_item()' into the limited compartments all users get.
+    'list_items' might open up a file on the store's machine, read
+    the contents, and spit them out -- an operation which, if allowed
+    in the general case, would clearly breach security.  However,
+    by creating a specialized function, the security concern is
+    removed, and by letting potential customers know of the function,
+    the power and ease of use are kept high.
+
+    Niggling but important technical issues currently being wrestled
+    with include the way that foreign functions are registered into
+    the namespace, the construction of a foreign function framework
+    so that the names and function of the functions are well-known,
+    and a superior-than-current 'digital signature' method.