Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Perl and CGI for the World Wide Web

by Ovid (Cardinal)
on Jul 08, 2000 at 00:51 UTC ( [id://21576]=bookreview: print w/replies, xml ) Need Help??

Item Description: Perl CGI

Review Synopsis: Less than worthless: dangerous

Note: I have since realized that the rude comments that I made in this post distracted from the content. I am embarrassed by how I handled this post and I hopefully have learned a valuable lesson: always be as kind as possible, even when one is being critical. I would love to see this node go away, but that would be unfair to the people who have rightly criticized the attitude used in this review. My sincerest apologies to Elizabeth Castro and all others who may be offended by this.

Introduction

I needed to learn Perl and CGI and I needed to learn it fast. Having purchased, and enjoyed, another Visual QuickStart Guide, I went ahead and bought "Perl and CGI for the World Wide Web" by Elizabeth Castro, first edition, Peachpit Press. I did learn some Perl and I thought the book was handy. Now, if I go to amazon.com and read all of those glowing reader reviews, I can understand why people like this book. In fact, the only significant problem that I have with this book is that it was published.

I'll pause now to let that sink in.

In Ms. Castro's introduction, she writes, "This book starts at the very beginning. Even if you've never, ever programmed before, you'll be able to understand this book." I was definitely a beginner when I bought the book and that's my only excuse for saying I liked it.

Let's face it, in a perfect world, we don't give knives to little children, we don't ask the police officer if we can finish our beer before we step out of the car and we don't let novice programmers cut their teeth on CGI!!!

The real world is different. CGI is sexy. Your boss was impressed when you pointed out that his mouse had buttons so he asks you to do the company Web site. You want a career change and make more money. Whatever the reason, absolute amateurs will want/need to learn Web programming. That being said, I can see a need for a "Perl/CGI for Newbies" book. Castro's book should not be that book.

The Premise

The idea behind the "Visual QuickStart" series should appeal to many programmers. From the cover: The "Visual QuickStart Guide uses pictures rather than lengthy explanations."

Rather than have a dense, technical tome that would scare off prospective buyers, Visual QuickStart guides have each page split in half. The outer half is an incredibly simple-minded explanation of how to type and the inner half has pictures of the result. For Castro's HTML book, this was a good combination. With "Perl and CGI," we have pictures of words. The outer-half also goes into explanations of what is going on and this is probably Castro's greatest strength: she can explain things in a clear, concise manner. If you pay attention, you can really come up to speed fairly quickly with Visual QuickStart guides.

The Problem

This book is not only aimed at novice programmers, it also assumes that the reader may know nothing about HTML. In fact, all of Chapter 3 is spent hand-holding the reader through creating a simple Web form. Given this, I would feel that the novice programmer needs a serious heart-to-heart talk about security. In fact, Peachpit Press also feels that there are some concerns there. In their "Notice of Liability", they state that "every precaution has been taken in the preparation of this book." No, it hasn't. Ms. Castro obviously feels that security is so important that she prominently displays a section on it buried in the back of the book in Appendix C (for Rush Limbaugh fans: the preceeding sentence is what we humans call "sarcasm").

Poor treatment of security is the number one problem with this book and is the main reason why I cannot recommend it. There are numerous other problems why this book and your fireplace should be intimately familiar with one another, but this is the worst. I'll detail this and mention the other problems in passing.

First, except for a couple of brief mentions in the text, security is not covered until Appendix C, page 235, near the end of the book. Many people never bother with appendices. Why should they bother now? Further, if they do read it, Castro hints that her scripts may not be secure (they aren't, but she doesn't come right out and say that), but tells the wide-eyed newbie that they "must be sure that [the scripts] pose no security risk to your system." While she does list several URLs that the reader can peruse to learn about these issues, she then proceeds to give terrible security advice. For example, she mentions that you can use the "HTTP_REFERER environment variable to make sure the page that accesses the script is on your server and, indeed, located in a particular directory." To her credit, she points out later that this can be spoofed, but she then demonstrates a small Perl script to check for this value anyway, but it has no -T, no -w, no strict, and prints out an the untainted REFERER to a Web page, if the script doesn't like it.1

Two pages later, she finally gets around to explaining the -T switch for untainting data. She still doesn't bother with -w or strict, but who am I to be picky? Here are Ms. Castro's rigorous instructions for untainting data:

To untaint data:

  1. Type $outside_data = ~ /regex/; where some part of the regex is enclosed in parentheses to capture the desired portion of the outside data.
  2. Type $clean_data = $1; The scalar variable $1 is automatically set to contain the matched expression from step 1 (see page 150).
Needless to say, that's going to get some programmer handed a pink sheet. The closest that Castro comes to actually explaining what is going on is when she says "it's your responsibility to ensure that your regular expression does a good job of ensuring that the data is what it should be." Unfortunately, she never clarifies what goes into ensuring that "data is what it should be" or what the programmer should be looking out for.

Here's two other fun comments that she makes:

  • You can print tainted data - even to an external file - without cleaning it. (Pop quiz: what's a potential problem here? Anyone, anyone? Bueller?)
  • You can also open a file to read using tainted data without getting an error. (Well, yes, this is possible. It's also stupid, but she doesn't point that out.)

Other Problems

There are too many other problems to go into detail, so I'll just give highlights.

No -w switch or use strict;. Nope, she doesn't use 'em once. She once coyly mentioned that she was going to be "strict" and declare a variable, but that's about it.

Bad code: On page 87, Castro explains how to modify all members of an array. The example she gives prints a list of numbers, calculates their square roots, and then displays the list of square roots.

print "The numbers you entered were: "; foreach $number (@numbers) { print "<LI>$number"; } foreach $number (@numbers) { $number = sqrt($number); } print "<P>The square roots of those numbers are: "; foreach $number (@numbers) { print "<LI>$number"; }
Yup, that's right. She has iterated over the same array three times in succession. She mentioned that she could reduce this to two loops (with clearer HTML, she could do this in one). I have to disagree with an author showing sloppy code and mentioning in a footnote what can be done to clean it up.

I also got a good laugh noticing that this "HTML expert" couldn't be bothered to close her <LI> tags in the above code, but I'm just a lowly Perl programmer, so what do I know?

No CGI.pm: I have no problem with an author showing how to decode form variables by hand. After all, it's good to know what's under the hood. However, if I pick up a Perl book that purports to teach CGI and doesn't mention Lincoln Stein's CGI.pm module, I just put it back on the shelf. With the exception of books written before Perl 5 was available, I haven't seen a CGI book that fails to mention CGI.pm and was worth anything.

Summary

I could go on at length about the problems in this book, but I think I've hit the high points. The security issue is, unfortunately, an all too common one for CGI books. Lazy authors will publish insecure code and then mention in passing that this is a bad idea. I cannot stress enough how dangerous such an attitude is. When we have a book that is specifically aimed at new programmers, what better time to teach them good habits?

Summary of the Summary

Don't waste your money on this piece of trash.

1. This is a problem because the script could easily be modified to save the Web page rather than printing it out. Someone can then include <!--#exec cmd="arbitrary command"--> in the REFERER and your system may very well attempt to execute that command when the page is accessed. This is a common problem with Web security. A script with no obvious security holes is created and someone does a cut-and-paste of the features they need, but then uses those features in a completely insecure manner.

Further, we have the common problem of people adding links to porn images or dangerous javascript or all sorts of other goodies that can pose problems for people if user data is blindly printed to a page.

Replies are listed 'Best First'.
Re: Perl and CGI for the World Wide Web
by Dominus (Parson) on Jun 09, 2001 at 21:34 UTC
    I had a chance to review the first edition of this book about six months ago, and I can't agree with your excessively snide review. I don't think this is the best book in the world, but I do think it's a lot better than most of the books with which is competes.

    The main point of your review seems to be that the book is bad because it doesn't discuss security issues in enough detail. But as we all know, beginners usually can't get security right even when it is explained clearly. When I was reading your criticism, I tried to imagine what would have satisfied you, and I don't believe that anything would have, unless maybe it was a much fatter book. Since I think one of the book's greatest strengths is that it's so small, I think that including a large and comprehensive section on security would have been a bad decision, decreasing the worth of the book. A small, incomplete section on security evidently would not have solved the problem here. So what's Castro to do? Are you saying that any small book about CGI must necessarily be Evil and Wrong? So it would seem. But I can't agree. I think a small book with a brief security warning and references to further information is just what is appropriate for a first book about security, and that is what we have here. I suppose in your perfect world, everyone is willing to study security for a month before they write a 'Hello World' CGI program, but I don't think that is a very realistic belief.

    I also don't think that your criticism about strict and -w is on the mark. The Perl community's dogmatism about these features gets increasingly silly every year. The programs in Perl and CGI for the World-Wide Web are never more than about twenty lines long. They don't need strict. I'll say it again: They do not need strict. Use of strict will confer no benefit in this case. There is no use of references, so there is nothing for strict 'refs' to do. There is no use of baseword strings, so there is nothing for strict 'subs' to do, and even if there were barewards, they are unlikely to cause a maintenance failure in a program this small. And in a twenty-line program there is practically no difference between a global and a lexical variable, so use of strict 'vars' and my would be a waste of effort and space.

    The style and maintenance rules for large programs simply do not apply here, because these are not large programs. I've heard plenty of arguments that you have to learn these style rules right from the beginning, apparently from people who think that if you once turn down the Path of Darkness your Soul is Lost Forevermore, and I think it's bullshit. A programmer has plenty of time as their programs get bigger to learn how to write bigger programs effectively. But it is not Castro's job , or the job of this book, to teach them; they should have another book for that. Anyone relying on Perl and CGI for the World Wide Web as their sole source of Perl information is going to write some very bad Perl programs, certainly, but an introduction to use strict is not going to help that. If you are worried about readers of this book perpetrating bad code, I think a better criticism would be that the book has so little material about subroutines and encapsulation issues. But as I said, I don't consider this a problem. There is plenty of time for the reader of this book to go and get a copy of Learning Perl. You say you started with this book, and it doesn't seem to have done you any lasting harm.

    Now, that all said, what did I like about the book?

    I liked the way it was broken down into small, easily digested units, one per page. I think that that, and the book's shortness, may be its best features.

    One of my major criticisms of most introductory programming books is that they have very few realistic examples. Perl and CGI for the World Wide Web succeeds tremendously here. Every page has a clear, brief, and realistic example.

    I liked the extensive discussion of permissions and the chmod() operator. I think too many books try to skip past this or keep their fingers crossed and try to ignore the issue, which Castro tackled head-on. (In your frothing about security you somehow missed this.)

    I liked the discussion on page 27 of the distinction between the value of an expression and its side effects, although the terminology was a little strange: Castro missed the opportunity to introduce the term 'side effect'.

    I found very few actual errors. Compared with, say, Perl For Dummies, this book is a marvel of correctness. In fact, it compares favorably in this regard with Object-Oriented Perl. Unlike most computer books, it's clear that it was carefuly edited and composed.

    My most serious criticism of this book would be that it doesn't seem to include very much discussion of programming issues, such as how the programmer decides what variables and functions to use, and how the programmer breaks the task down into steps. But perhaps people don't have as much trouble with this as I think they do, or perhaps the many small examples Castro shows will provide a natural jumping-off place for new programmers to gradually extend and enhance the examples. The other worry I have is that the book seems to encourage the reader to paste in code without understanding what it's doing. Many times, the book says "Type a close parenthesis". It's hard for me to pin down just what I thought was bizarre about that, but I'll try. It seems to me to suggest that programming is about typing the right sequence of characters in the right order, and I don't think that's true. To program you have to have a deeper understanding of what's going on. (It reminds me of a comedy sketch I once saw in which a Shakespearean actor explained that Hamlet was the hardest role to play, because not only does he have more words to say than any other character, but one must speak all 12,483 words in the right order.)

    One occasionally sees people asking questions like 'what do I type to change all the a's to b's in a string?' and then a couple days later from the same person 'what do I type to change all the f's to r's?' This person is missing something fundamental. I worried that the style of Castro's book would encourage this kind of misunderstanding. On the other hand, I was never sure that this was a real problem---maybe it isn't. I tried to imagine what I would have liked in place of "To do this, type this:...", and what came to mind was that I probably would have written "To do this, use this:..." But that is not different in any meaningful way.

    Perl and CGI for the World-Wide Web is not the best possible book, and it has some serious problems. But it is valuable, and I think it will do a lot more good than harm. I have recommended it to people in the past, and I am looking forward to the second edition.

    --
    Mark Dominus
    Perl Paraphernalia

      Thanks for the feedback. You raise some good issues and I realize that I should have tried to pay attention to some of the good in the book, rather than focus on the bad. This was a blunder on my part and clearly a blind spot that I tend to have.

      That being said, unlike footpad, I disagree with you strongly regarding the security and 'strict' issues. I'm on the beginners-cgi mailing list and I try to answer questions for them (sometimes I even get an answer right). However, I've noticed a disturbing trend: many of these people seem to be maintaining or developing sites for businesses. I try as well as I can to steer them to better coding practices, but I am seeing so many people doing work that should be handled better.

      Now admittedly, I may be biased here. I worked for a company where the lead programmer (of a small shop) learned Perl from Castro's book. While a sample of one is not the most useful for statistical analysis :), I saw poor coding habits that simply didn't need to be there. He never used strict. As a former Javascript programmer, he tended to end his Perl subs with return true;, not realizing that this was useless. Of course, his subs didn't need to return anything because all variables were global. He didn't check the status of his opens. He didn't validate any incoming data. He didn't...

      Well, you get the picture. The surprising thing is, this guy was brilliant. He just had never been exposed to proper coding practices. Others that I have worked with (confession time: I'm one of them) have had tendencies to push back when new things are introduced. Many, many people get into a routine where they are comfortable and when another programmer comes along and says "you really should use strict", they resist. You don't need strict when you've found all of the bugs in your code, right?

      Ask anyone who works with moderately complex systems (project management, software design, medicine, economics, etc.) and they'll all tell you the same thing: it's cheaper and quicker to prevent a problem than to clean it up after the fact. Pushing the glass away from the edge is a better solution than sweeping up the pieces. The same goes for good programming style: teach everyone from the start and they'll just do it. They won't know better. How many times have you heard someone say "I tried using strict but it breaks everything?" When that happens, more often then not, they just give up.

      Dominus wrote:

      When I was reading your criticism, I tried to imagine what would have satisfied you, and I don't believe that anything would have, unless maybe it was a much fatter book.

      Well, this is something I can agree with. I don't think the book would have to be huge, but essentially, Castro gave a 'Cliff Notes' version of Perl/CGI programming. Can you imagine a thin calculus book? I'm not saying that Perl/CGI is as difficult as the Calculus, but what I am saying is that, to know Perl/CGI programming, there is much more territory to cover than what Castro has presented. The readers of the book were short-changed.

      Dominus, I have a lot of respect for you, but I simply can't agree with you here. Too many people are exposed to poor code and are happy. They don't want to be told they're 'doing it wrong'. They often see it as a personal affront when someone points out code issues. If their stuff works, they're happy. Frankly, if their stuff works, I'm happy too. But not if I have to maintain it. Not if someone stores the price in hidden fields on a Web site. Not when someone defaces yet another Web site due to poor code. I, too, am looking forward to her next book, but only because davorg mentioned that it will be much better. Why deliberately start people out on a path that you know they must veer from?

      Cheers,
      Ovid

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        Brief personal response


        My first Perl program was written to chop up Netscape bookmark files, as it was so long that I got tired removing all the extraneous bits (Last-Visited etc) by hand.

        I read some bits of the Programming Perl book carefully, wrote it, and three days later (part time) it worked.

        I then read about use strict; and decided to stick it in. It took another two full days to make this working program compile. But I learnt a lot about Perl.

        The moral - always use strict; or know why ;-)

        -- Anthony Staines

      It is not the best possible book, and it has some serious problems. But it is valuable, and I think it will do a lot more good than harm. I have recommended Perl and CGI for the World-Wide Web to people in the past, and I am looking forward to the second edition.

      I disagree slightly. You may be right about the benefits regarding use strict, my and -w in Castro's examples, however, you must admit that those are good habits to get into. Indeed, I've found that by starting with good habits, I've avoided some of the problems we see posted so often. Also, other titles have shown that it is possible to start with good basics: security, CPAN, good program design, and so forth. While that title is perhaps not appropriate for a first introduction to programming, it can help experienced programmers learn better habits from the start. As I'm sure you're aware, once we get an idea into our heads, it's difficult to shake it.

      I agree that Perl and CGI for the World Wide Web can be a good place to start from some people; I fear, though, that some will presume that they have enough knowledge when finishing it to create and deploy production scripts. Given the relative lack of security information in the first edition, that would be very dangerous. The book does have some value, however, I would hope that people move from there to one providing more suitable education for production CGI scripts.

      As an aside, the second edition appears to be available (check the above link). Since davorg mentions that some of the more egregious problems have been dealt with, the new edition may be more successful than the first.

      --f

Re: Perl and CGI for the World Wide Web
by davorg (Chancellor) on Mar 26, 2001 at 19:19 UTC

    Thought that you might all be interested in this news.

    There's a second edition of this book due out in a couple of months. I've exchanged a few emails with the author and she's made some changes to the book. In particular:

    • Discussion of CGI.pm
    • -w and use strict in all code examples
    • Much more importance placed on security aspects

    I've seen proofs of many of the chapters in the new edition and I have to say that it looks a lot better.

    --
    <http://www.dave.org.uk>

    "Perl makes the fun jobs fun
    and the boring jobs bearable" - me

      I have the second edition of this book and these issues are addressed. I like the book - it's a start. Anyone involved in a corporate website should be aware of the need to consider security issues and if they aren't they shouldn't be allowed near it.

      Perhaps this node should be changed so that it clearly refers to the first edition of the book?

RE: Book Review - Perl and CGI for the World Wide Web
by athomason (Curate) on Jul 08, 2000 at 09:12 UTC
    I couldn't agree more. Sadly, I did the same thing as Ovid, since I was handed a website and told to fix it up in 3 days. I picked up Castro's book since it was the thinnest one on the shelf containing both "CGI" and "Perl" in the title. The first drafts of all my scripts used her hacked-together CGI routines... badly. Some months later (after having read the ORA books on Perl and CGI), I went back to those scripts and laughed myself silly. I rewrote the site using DBI and CGI.pm in a fraction of the time and space it had originally taken me. I don't think that introducing Perl and CGI concurrently is necessarily a bad idea, but doing it in a book that's only 272 pages cover to cover is insane. Newbies beware: this book is full of bad habits and lacks critical information. Experienced PHs won't have any use for it at all. I'll echo Ovid's summary: don't bother.
      Okay, I'm going to sit here and kick myself repeatedly. In reading your response, I remember what I forgot to include in the review: Elizabeth Castro doesn't know Perl.

      After reading through her little pamphlet (I can't dignify it with the term "book") I came to the conclusion that she needed to get a book out the door quickly and either took a class on Perl or bought a book on it and started writing. That would explain the generally poor quality of her code and why she spends so much time explaining how to FTP and how to create a Web form. Large portions of this book are spent on non-perl things. She also gets her Perl stuff wrong:

        Perl has three operators that let you look inside incoming data and act accordingly: match, substitute, and split.
      Is that so? I guess I'll have to throw away tr///;. What a shame. It's really useful.

      Another beef I have is the regex she listed to capture any phone number in the form (xxx) xxx-xxx, with the x's being replaced by digits.

      /^((\(\d{3}\))? *\d{3}(-| )\d{4},? *)+$/
      This regex really isn't bad, but it has some stumbling blocks for the novice programmer (aside form the fact that a novice won't understand it). The problems:
      • It matches numbers where the dash is replaces with a space. That's not a problem, but it's not what she said she was matching.
      • The (xxx) is optional. See my first gripe.
      • The phone number is captured into $1. Fine and dandy. But did you notice the ,? * at the end? We have an optional comma and potentially many spaces being captured. That's probably not what we want in $1.
      • And what the heck is that '+' doing before the '$'? Are we trying to capture one or more phone numbers? Again, this wasn't explained and could confuse the heck out of newbies.
      • Due to the variable-width font in the book, the spaces in the regex are difficult to see.
      These gripes may seem petty, but this is programming. We need to be very specific and not just "fudge" things. Castro should not be giving examples that are "almost" correct.
Re: Perl and CGI for the World Wide Web
by clintp (Curate) on Aug 10, 2001 at 07:12 UTC
    First, some disclosure before I get going: I've got a competing (?) book on the market, Teach Yourself Perl in 24 Hours (2nd edition coming in October). It's selling well, it's been well received by the Perl Community, and the readers have really liked the book judging by the mail I get. >2/3 of the book is an introduction to Perl, the last 1/3 is the application of Perl to (horrors!) CGI programming. I have seen Ms. Castro's book and I think I even own a copy (research).

    I agree with your statement about the need for a novice CGI book (that's why I wrote one). And Ms. Castro's book isn't the worst example of a book that teaches the topic. The presentation technique is unique and appropriate for the medium. I find it nearly impossible to teach CGI without drawing lots of pictures and waving my arms. 4/5 illustrations in my book appear in the CGI chapters. Writing a book in a novel format like this must have been excruciating and she did a fair job. The explanations are clear and for the most part accurate. CGI can be a hard topic to wrap your head around.

    Using strict, -T and -w are good things to use when appropriate. They're not always needed. I present -T, and use it sometimes, but for the most part in these 15-20 line scripts I don't need it. And just putting -T at the top of every CGI script just because "well, that's what you do!" is just as Cargo Cultish (Randal's term) as cutting-and-pasting from Matt Wright scripts.

    It so happens I used -w everywhere. Cargo Cultish? Naw. -w catches silly user typos ("used only once..."). It also seems I used strict everywhere after chapter 8. Why? For 'strict vars' mostly because I'm consistantly encouraging "self-contained" functions and argument passing and this helps you to remember to create block-scoped lexicals. Nothing more.

    I don't like the explanation of how to untaint without full examples though. I deferred to perlsec here. I would have hoped there was at least a passing reference to it in her book, but I don't see one. One demerit.

    Moving on... Even if the HTML were incorrect, this isn't an HTML book and isn't the place to teach it. I wouldn't expect proper and compliant HTML in a Perl/CGI book. And teaching it would obscure the topic at hand. You have to allow for some handwaving.

    Speaking of handwaving. The three foreach loops? That may be appropriate for a beginners book too. Sometimes you want to take small bites, and this example DOES have three functions: display a before list, alter the list, display the after. It'd be cute (and FASTER!) to roll it all up into 2 or 1 loop. But when you're teaching new programmers (not just new Perl programmers) you have to take small steps.

    Not using CGI.pm? Well, that I don't like. I'm not a big fan of CGI.pm, but at the very least it saves space in the listings for showing CGI techniques and less space for encoding/decoding things. Bad editorial decision. I think this is the only point I agree completely on.

    And on a more personal note. This tone was very poor, Ovid. It is possible to give a bad review of a work and still be gracious and civil. In a public forum we should strive to be cultured and thoughtful. Bitch sessions are best done over a beer. Catch me at a conference sometime, and I'll buy you one.

Re: Perl and CGI for the World Wide Web
by Chrisf (Friar) on Aug 10, 2001 at 06:15 UTC
    Excellent review, you made some very good points. I bought Castro's html vqg a while back and thought it was an excellent book (and I still recommend it) so when I wanted to learn perl (and cgi in particular) it seemed like a good idea to buy this book. I read the whole thing through and thought it was a pretty good book, that is until I actually learned a thing or two about perl, and in particular, security. On the bright side though, the book did do a decent job fueling my fireplace :-)
Re: Perl and CGI for the World Wide Web
by Anonymous Monk on Feb 05, 2001 at 19:29 UTC
    I also got a good laugh noticing that this "HTML expert" couldn't be bothered to close her <LI> tags

    Hey, the book's crap, and sarcasm is great, but you look silly pointing out mistakes that aren't. <li> tags don't have to be closed in HTML so why bother? Would you critise a Perl book for using $_ ?

      <li> tags don't have to be closed in HTML so why bother?
      That's a booboo on my part. I'm thinking XHTML and everything needs to be closed properly. It's a good habit to get into (which I don't always bother with). Allowing optional end tags is stupidity, but quite valid in regular HTML.
      Would you critise a Perl book for using $_ ?
      What? You're comparing cheese and Wednesday here. The only way I can see what you're meaning is to assume that you're pointing out that both are valid. Other than that, I have no clue as to your point. Thanks for pointing out my initial error, though.

      Cheers,
      Ovid

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: bookreview [id://21576]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (3)
As of 2024-03-19 07:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found