1 files changed, 4 insertions, 95 deletions

diff --git a/devel/p5-Penguin/pkg-descr b/devel/p5-Penguin/pkg-descr
index 2c463078687a..9d0f53f0bcf5 100644
--- a/devel/p5-Penguin/pkg-descr
+++ b/devel/p5-Penguin/pkg-descr
@@ -1,95 +1,4 @@
-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.
+The Penguin module provides a framework within which a user on one host
+electronically signs a piece of Perl code, sends it to another host where the
+signature is checked and the code is executed with privileges that are
+particular to that user.