diff options
author | James FitzGibbon <jfitz@FreeBSD.org> | 1997-05-30 20:02:24 +0000 |
---|---|---|
committer | James FitzGibbon <jfitz@FreeBSD.org> | 1997-05-30 20:02:24 +0000 |
commit | b579a4e406e1f5e3ebbf4ffbb4d49e470a0554e5 (patch) | |
tree | ab9d19862f3b9f5b07ba1a5c3d2d85b177264cfd /devel/p5-Penguin/pkg-descr | |
parent | 669f12c3222b280736cbc116ef62d7b3f8f5574c (diff) | |
download | ports-b579a4e406e1f5e3ebbf4ffbb4d49e470a0554e5.tar.gz ports-b579a4e406e1f5e3ebbf4ffbb4d49e470a0554e5.zip |
Import of the Penguin module for perl5
Notes
Notes:
svn path=/head/; revision=6643
Diffstat (limited to 'devel/p5-Penguin/pkg-descr')
-rw-r--r-- | devel/p5-Penguin/pkg-descr | 95 |
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. |