The asymmetric encryption used to protect the message is always just to encrypt a symmetric encryption key that is used to encrypt the actual contents of the message, as you said (and like SSL as you also said). Even so, that little bit of asymmetric encryption gets expensive when multiplied by a heavy load of messages. The symmetric encryption computation time, on the other hand, is cake by comparison.

Let me know if your understanding is different.

“whereas WS-Security needs to perform asymmetric key encryption on each message (one computation for handling encryption and one computation for handling the signature)”

While you can’t get away from the need for a server certificate, you can use WS-Security without a client certificate, and you often will use symmetric encryption as part of the message. You’re right that you’ll definitely use asymmetric in the message, but it might be used just for key exchange like SSL. Actually I think this is the more common usage. Of course it’s still per message.

And let us not even get started with how ports 80 and 443 are abused through firewalls!

What extension can do is provide user conveniences. Security in Windows 2003 at a protocol level is basically the same as 2000. Unfortunately both still by default enable support for the Windows 98 protocols. Windows 2008 changes this, but anyone can disable the Windows 98 protocols as is. So there we see subtraction adding to security.

At the same time, Windows 2003 and Windows 2008 make an administrator’s job much easier without reducing security. In an effective sense they raise it by making it more likely they’ll know how to or have time to make the appropriate choices. Though pure security may not change much, effective does. Of course, management may instead take the efficiency improvements and roll them into staff cuts or more work, or more process, but that is an age old cause of many problems.

As far as 445 goes, I’m not sure why it’s more highly scrutinized than 22. It may be a mistake that 22 isn’t more scrutinized. I’ve heard of plenty of attacks that originated here. In fact, most UNIX attacks I recall any details of did. Perhaps it’s just a community bias that would leave such blind spots.

I’d say in both cases, that these are need to know ports. Applications services should use ports that are easier to separately monitor and control if you’re approaching it from a security perspective. If you approach it from any other perspective they should use ports 80/443 exclusively to subvert all security restrictions. ;p

Quite why are you evaluating random code for configuration - doesn’t ruby have decent support for configuration files?

I replied before about this - the example you give is so unhelpful that I don’t see any case at all for what you’re going on about.

In my experience the occasions where you want some kind of ‘quick and dirty on the fly evaluated user input’ that you call a DSL, are exactly the times when you have a domain specific problem that a domain specific API should handle well with a proper parser.

For example in my work I handle human and computer created data feeds from Air Traffic services, The Met Office, US DoD, ICAO, etc, all of this data is parsed properly through a lexer with validation, edge case handling, and then fed into the system through the same clear and documented OO API that it will be retrieved through.

I’m trying but failing to see a good scenario for what you’re proposing - a good DSL is very hard to create, not technically but through the difficulty of the design decisions - the implementation in any language is the most trivial part - perhaps the reason we don’t use Quick/Dirty Pseudo-DSL like Ruby programmers is because many of us know that a better solution to the problem is usually available and done properly on CPAN or requires up front design time in doing it right (which rules out a DSL in 99.9% of cases).

package DoStuff;

use Moose;
use IO::All;

has ‘func’ => (is => ‘rw’);

sub BUILD {
my $self = shift;
local *do_stuff = sub (&) { $self->func($_[0]); };
eval io(’config’)->slurp;
}

sub run_func { shift->func->(); }

Wonderful thing, modern perl.

That being said, it really sounds like you and I don’t have a significant difference of opinion here once we recognize that we’re using different definitions for similar terms, hence the disconnect.

I agree. Thanks!

While I like to promote the use of DSLs via string eval, I would not use it for any of the above examples that you present where a lexer and parser would be superior (further affirming your point that we agree on a lot). Your point about taking data in different formats is not one I considered, but I would not trust externally submitted data enough to pass to eval anyway.

I have never considered a situation where a parser might be taking input from any one of several lexers. Mine have always been married in a way because I was focused on one type of input. Nifty idea for me to churn on!

Do not use language-powered DSLs when writing a parser is clearly superior, such as when the input cannot be trusted.

This is perhaps one of the most significant issues I have with a “language-powered DSL” (a.k.a., fluent interfaces). If there’s even the slightest danger of untrusted input, then I strongly object to them. However, people will disagree as to what constitutes “untrusted input”. To my mind, this means any code coming from outside of the program, even it’s just a simple file that someone down in accounting can edit. I may be overly paranoid on this point, however.

More importantly, the who concept of fluid interface is just good programming. It’s a difficult skill to develop. That some people refer to these as DSLs where others do not makes a lot of the point moot. In Perl’s case, we do have a string eval which does this, but if implemented incorrectly, can lose some context (I’d love to easily be able to run an eval against a higher stack frame).

For myself, I distinguish between fluent interfaces and DSLs because the former, as mentioned, is just good programming and is not restricted to a problem domain while the latter is harder to implement, tends to be more restricted, but offers a greater expressiveness if suitably done. Plus, by separating the lexing and parsing, you can gain a lot of flexibility if someone needs to submit their data in an XML format but your DSL is natural language. Just write a separate lexer and use the same grammar! The decoupling of these steps is trivial and since Perl is so powerful when it comes to text manipulation, it’s well-suited for this.

That being said, it really sounds like you and I don’t have a significant difference of opinion here once we recognize that we’re using different definitions for similar terms, hence the disconnect.

(And I really wish you had a preview button here

http://ryan-technorabble.blogspot.com/2007/08/flux.html

I think it would be good if you read up on the Wikipedia entry on DSLs (http://en.wikipedia.org/wiki/Domain-specific_programming_language). Since I’m not sure what formatting is allowed here, I wrote up a journal entry on use.perl (http://use.perl.org/~Ovid/journal/34010).

Cheers,
Ovid

Please to be reading TFM

Hint : perldoc -f do.

Aristotle ( http://use.perl.org/~Aristotle/journal/34004)couldn’t be bothered to jump through the hoops of registration and logging in just to correct such a silly mistake, but it’s monday morning and the Tax man and a slow paying client have annoyed me already so I’m cranky.

Also - more importantly than remembering to RTFM, is to not be dynamically eval’ing in the first place - ick! I have to agree with Aristotle on both counts here.

From the filename, I’d suggest you want to be reading a nice configuration file using one of the nice modules on CPAN. Lately I’ve been using Config::Context, which gives me Apache style per host and directory configuration - incredibly handy for my Perl MVC application so I can deploy a web application once, but with configuration per host and path. Sweet as!