A. Pagaltzis (paga...@gmx.de)

* J. Shirley <jshirley@gmail.com> [2008-10-06 01:10]:
> Andy apparently just wanted to start a flamewar.

In the comments:

    Oh, FFS. If you didn't use software because you think one or
    several of the contributors were assholes, you'd have to
    write everything from scratch.

    And I rather like ack.

Ice Burn.

Regards,

* Lee Aylward <lee@laylward.com> [2008-10-03 00:40]:
> Assuming that your shared host has all of the required modules
> installed you can use the .cgi script found in the /scripts
> directory of your catalyst application.

That?s going to be extraordinarily slow.

Regards,

* Bill Moseley <moseley@hank.org> [2008-10-01 20:45]:
> Where on the risk spectrum is CSRF compared to, say, session
> hijacking?

It?s even harder than XSS to pull off, and requires even closer
involvement of the attacker, but if they succeed, they can
overcome barriers that could prevent an XSS attack from doing
too much harm.

In a sense, it?s the next step in the progression from CSRF to
XSS. CSRF is dangerous primarily because of how easy it is to
set up an attack.

Regards,

* John Beppu <john.beppu@gmail.com> [2008-10-02 02:40]:
> Have any of you ::Engine::HTTP::Prefork users written init
> scripts for starting and stopping your Catalyst apps?

I must admit, not yet. The server I?m on is an RHEL5 VM ? not my
choice, but I didn?t have another. Problem is, I couldn?t find
any guide for writing RHEL init scripts as solid as eg. the
Debian sysadmin guide, mostly just largely-cargoculted example
scripts that I would have to cargocult in turn. Maybe I?m just
dumb and/or blind, I dunno.

If anyone has a good reference resource, I would greatly
appreciate a pointer. I?ll publish the result too if there?s any
interest.

Regards,

* Moritz Onken <onken@houseofdesign.de> [2008-10-01 12:55]:
> but this does still rely on the fact that there is no XSS issue
> on your page, doesn't it?

So what? If your site has an XSS hole, it?s already game over.
The attacker can inject Javascript that passes the same-origin
policy blockade, so they can already do whatever the hell they
want.

> I imagine a case where the attacker's site opens a iframe to
> your site which exploits a XSS issue and can send the hole form
> information back to the attacker's site. He has now the HMAC
> and the random string.

Using an XSS hole to initiate a CSRF attack is like breaking in
through the window to steal the house keys so you can unlock the
front door. Attackers don?t build Rube Goldberg contraptions.

Regards,

* Moritz Onken <onken@houseofdesign.de> [2008-10-01 09:25]:
> The best way is to include a random string which has to be
> stored somewhere for comparison on the server side.

Doesn?t have to be stored. Send a random string as well as a HMAC
digest of a server secret plus the same string. To check a token,
check if the random string plus server secret hash to the same
digest as the one provided by the client. Since the server secret
is not known or knowable to third parties, if the digest checks
out, then this token must have been minted by the server. Very
simple; near-zero CPU overhead; no server-side storage required.

Instead of a random string, you can also use useful data: include
a datetimestamp of when you minted that token, and expire tokens
after X period of time.

Better still, include the form action URI in the token.

And the user ID.

Concatenate all these bits, then hash them together with the
server secret using HMAC, then concatenate the resulting hash.
Now you have a token that says ?at $datetime, $user was granted
permission to POST to $uri, verifiable by $digest.?

Regards,

* Ashley <apv@sedition.com> [2008-09-30 19:30]:
> If scripting is involved that makes it a XSS attack instead,
> though. No?

No.

XSS means injecting attacker-controlled HTML into a page. That?s
usually used to inject Javascript, but doesn?t have to; just HTML
could work just as well. The attack takes place when the victim
visits a page on the vulnerable site and can cause anything to
happen, including sending sensitive information from that page to
third parties.

CSRF means getting the victim?s browser to send a request to the
vulnerable site. It makes use of what?s sometimes referred to as
?ambient authentication,? ie. the victim is already logged into
the vulnerable site, eg. with a remember-me-forever cookie, which
the CSRF attack relies on to trigger actions that require
authentication. The attack can take place anywhere on the web at
all (you just have to get the victim to visit a site you control)
but can only trigger functions of the vulnerable site.

There is some overlap in what you can achieve with the two routes
of attack, but the overall risk profiles are different. The main
thing to keep in mind is that CSRF holes are much easier to
exploit, by virtue of the fact that attacks can be initiated from
any page on the web.

Regards,

Nothing scientific. For me the major attraction is that it?s a
boatload easier to administrate and debug, since I?m doing the
entire devel/QA/sysadmin cycle mostly on my own, and my time is
limited. I?d throw a second machine at it much sooner than I?d
switch to a more complicated solution.

All that said, however, I simply haven?t had to investigate its
performance, as it?s proven plenty fast for our modest needs.

I can?t imagine off hand any reason for it to be significantly
slower than a FastCGI deployment ? conceptually it?s the same
setup, with a standard webserver like Apache facing outward and
a separate set of Catalyst processes running in the backstage.
The main difference (and it makes a world of difference) is the
wire protocol used in the connection between those parts.

So this is all just anecdotal so far, but it worked perfectly for
me. If you think it might work for you, just give it a try ? it
takes very little work to do so! I came up with this setup almost
by accident, in fact.

Regards,

* John Lee <jlee+catalyst@pangeamedia.com> [2008-09-29 16:05]:
> What's the general concensus in the catalyst community
> nowadays? Is mod_fastcgi preferred at large over mod_fcgid
> these days?

Personally? ::Engine::HTTP::Prefork + ::Plugin::Static::Simple.
Then I put a reverse proxy in front (it doesn?t really matter,
I?ve used Apache mod_proxy and Varnish, pick whatever you like),
and teach that to cache the static files for a very, very long
time.

That way, the Catalyst server

a) is completely decoupled from its deployment environment
   (the two parts don?t even have to be on the same machine),

b) can therefore also be debugged standalone in production,

c) can be an exact replica of the server that runs on the
   developer?s machine.

(Although the last point is watered down a little by adding
a reverse proxy to the mix in production.)

Regards,

* Zbigniew Lukasiak <zzbbyy@gmail.com> [2008-09-29 09:15]:
> RecursiveUpdate does not require that you have additional
> unique constraints on tables with auto_increment primary keys
> like the original update_or_create does.

If none of the columns you pass is unique, how does it decide
which set of columns to use in the WHERE condition and which are
the ones to use as new values?

Regards,

* Antano Solar John <solar345@gmail.com> [2008-09-09 07:20]:
> By static I mean the generation of the required files instead
> of them coming from the memory. This way it will be possible to
> edit the files manually and make appropriate changes

Bad idea: makes it impossible to upgrade.

Ask for a Moose-ified version instead.

Regards,

* Yuval Kogman <nothingmuch@woobling.org> [2008-09-04 16:20]:
> C<git help> lists common commnads
                              ^^^^
Typo.

> =head3 delete
>
> C<git rm>

Note: this is not mandatory. You can actually delete the file in
any way you like, like plain old `rm`, as long as you update the
index to denote this, eg. with `git add -u`. Using `git rm` just
integrates both parts of the process into a single step.

> C<git pull> fetches changes and merges them using C<git rebase>.

*cough* *sputter* Whuh…? No, it uses `git merge`. Of course you
can tell `git pull` to rebase using the `--rebase` switch, but
this is explicit, as it should be, because rebasing rewrites
history, whereas merging does not.

Regards,

* Nicholas Clark <nick@ccl4.org> [2008-09-02 20:30]:
> But I've tried touting this task before, and everyone seems
> instantly busy.

I can see why.

I can tell you some trivial things that have *not* changed, which
is all of `~~`’s spec outside of that section, such as
precedence, interaction with `when`, exception matching, etc. pp.
This is so easy to figure out that I assume everyone else before
me who may have attempted this task has also figured out this
much, and that my work so far has therefore produced no value.

That leaves the Smart Matching sections themselves. In Feb 2006,
the section was 80 lines long. It has quadrupled since. This’ll
take a rather long chunk of quality time to figure out.

> So it would be useful for someone to compare the Perl 6
> smartmatch table as of February 2006
> L<http://svn.perl.org/viewvc/perl6/doc/trunk/design/syn/S03.pod?view=markup&pathrev=7615>
> and the current table
> L<http://svn.perl.org/viewvc/perl6/doc/trunk/design/syn/S03.pod?revision=14556&view=markup>
> and tabulate the differences in Perl 6.

Actually, the old table was in S04 @7615, with a note saying it
should be in S03.

> The annotated view of changes is
> L<http://svn.perl.org/viewvc/perl6/doc/trunk/design/syn/S03.pod?view=annotate>
> and the diff is
> C<svn diff -r7615:14556 http://svn.perl.org/perl6/doc/trunk/design/syn/S03.pod>
> -- search for C<=head1 Smart matching>. (In theory F<viewvc>
> can generate that, but in practice when I tried it hung
> forever, I assume "thinking")

Even the annotate link hangs until it times out, for me. Not that
in either case it matters, because the table moved from S04 to
S03 in the meantime, so both the diff and annotate views are
actually completely useless. Since the section has grown several
times I’ll assume here that shaving yaks with git-svn to get a)
acceptable performance with b) a local repo browser, will only
lead me to discover that following diffs over time is no more
helpful than reading the two revisions in isolation and entirety.
Therefore I am reading them thusly.

I’ll report back with my findings.

Regards,

But then ~~ against a string in list context would be different
from ~~ against a regex in list context. Is it more important
for ~~ to be consistent with =~ or more important for it to be
consistent with itself? (This is not a rhetorical question. I
suppose the answer is “itself,” but I have not thought of any
solid argument other than that self-consistency for the sake
of self-consistency is an obvious-seeming right choice.)

Regards,