|
Source: ONLamp.com Parrot’s first ever Bug Day is this Saturday, 16 December 2006. The core Parrot developers will be in #parrot on irc.perl.org all day to:
Review tickets in the Parrot RT queue
Answer questions from newcomers
Fix bugs
Add features
Improve the documentation or tests or…
Recruit and encourage new developers
If you’re curious about Parrot, please join us. You don’t have to be an expert programmer. If you can follow the build instructions (or report where they fail for you), manage a source code checkout, and work an IRC client, you’re plenty qualified. There are plenty of ways to get involved in almost any capacity you can conceive.
Source: ONLamp.com I recently needed to filter and process some Atom feeds. I know enough
XML that I could process them with my own SAX filter, but this seemed like
a better opportunity to use the XML::Atom module.
Fortunately, it was very easy.
Installation
Installation went well from the CPAN shell. It required a few other
modules I didn’t have installed, but this was on a new machine and they all
seemed pretty standard. I also didn’t have libxml2 installed, but that’s
also a common dependency.
Usage
XML::Atom provides several objects. The important ones for
my purposes represent feeds and entries. When I publish an Atom feed, it’s
a list of entries. When you subscribe to my feed, you get a chronological
list of entries.
My project needed to work through a list of feeds to find new entries to
process. XML::Atom’s documentation pointed me in the right
direction, though I had to make a few guesses.
Working with Feeds
Suppose I have a feed. Suppose it’s just an XML file on my local hard
drive. I need an XML::Atom::Feed object:
use XML::Atom::Feed;
my $feed = XML::Atom::Feed-new( 'sample.xml' );
That worked. A feed has several attributes, including a title. The
Feed object provides accessors:
So far, so good. What can I do with it? Let me check the title:
warn $feed-title();
Working with Entries
More importantly, a feed contains entries. My goal was to process those
somehow. The code is again simple:
for my $entry ($feed-entries())
{
}
What’s in $entry? XML::Atom::Entry objects.
This is where the documentation started to get a little sketchy, but the
code is straightforward and sensible. A little guessing worked out
fine.
My application must process each entry once. A feed may get refreshed
once a day, but newer versions might include already-processed entries.
Fortunately, the Atom specification includes a unique identifier for each
entry. It’s the responsibility of the feed creator to provide these. It’s
easy to fetch them from the Entry objects, though I suspect
that I’ll hash them just for a little extra paranoia:
my $id = $entry-id();
My application also needs the entry titles:
my $title = $entry-title();
The really important part of my application uses the content of the
entry. That’s the main text. This is where the documentation was unhelpful
and I had to read the source. It turns out that there’s a
content() method:
my $content = $entry-content();
That didn’t give me text; it gave me an object. I wanted the text:
my $body = $content-body();
That’s all of the pieces I needed to build my application. It’s only a
handful of method calls; I’m pleased;
Enhancements
It’s a little bit unrealistic to expect that I’ll only ever parse local
feeds. It’s useful to do so when developing so as not to punish someone’s
web site with any of my programming errors, but it would be nice to be able
to parse live URLs. How does that work? Here’s what I wanted to write:
my $feed = XML::Atom::Feed-new('http://example.com/some_feed.xml' );
That actually worked. The documentation made me think that it required a
URI object, but the version I tested (0.25) handled this case
nicely.
I put off doing this project for a while because I’d never consumed Atom
data before. It’s surprising how easy it was.
Source: ONLamp.com Recently I was pointed to a blog entry announcing the retirement of Stefan Esser from the PHP Security Response Team. Stefan, amongst other things, developed Suhosin, a PHP security tool. His retirement announcement was extremely disturbing and is worth reading.
The crux of it is this paragraph:
The reasons for [my retirement] are many, but the most important one is that I have realised that any attempt to improve the security of PHP from the inside is futile. The PHP Group will jump into your boat as soon you try to blame PHP’s security problems on the user but the moment you criticize the security of PHP itself you become persona non grata. I stopped counting the times I was called immoral traitor for disclosing security holes in PHP or for developing Suhosin.
Now I’ve done relatively little hacking of PHP and don’t expect to do this for a living, so why should I care about this? I hacked on one PHP app that horrified me because of how poor it’s security was, but this is not a reflection on PHP. However, as I was once griping about the fact that I don’t miss strong typing, one programmer pointed out that if we could get optional strong typing in Perl, we could gain tremendous performance wins for all Perl programs.
That’s why I was annoyed at the security holes I had to fix in the PHP app (SQL injection attacks), but not overly worried. If Stefan’s comments are accurate, then there are plenty of reasons for the PHP community to be concerned. You might not care about an individual program — you can usually just choose a different program which does the same thing — but if you’re talking about the entire programming language, that’s serious. The more people who are affected by what you do, the more disciplined and less-ego driven you need to be.
Of course, it’s possible that Stefan is just a crank — I wouldn’t know — but if any of the people involved are reading this, my apologies if I’ve offended anyone. I’m an outsider looking in and perspective is a difficult thing to acquire.
Source: ONLamp.com Disclaimer: I have programmed in both Ruby and Python, but not enough to be familiar with their conventions, so the following could be a serious misunderstanding on my part.
Any Python or Ruby programmers out there able to explain why these languages default to integer math?
$ python -c 'print 7/2'
3
$ ruby -e 'puts 7/2'
3
Those languages default to integer math unless you explicitly use a float. For example:
$ python -c 'print 7.0/2'
3.5
Why should the default be to silently discard information? Now I can understand that in C. For example, run gcc -Wall on the following:
#include
int main(int argc, char *argv[]) {
printf("%f\n", 7/2);
return 0;
}
You’ll get the following warning (is this something I could enable in Python or Ruby?):
divide.c: In function 'main':
divide.c:4: warning: format '%f' expects type 'double', but argument 2 has type 'int'
C pretends to be a statically typed language and if you get confused about types, your language will misbehave. So you either want to be explicit and cast the result, (float)7/2, or better still, use floats in the first place (some argue that the ability to cast data types means a type system is broken). If you use integers in division, it will give you an integer result. If you use more than one data type, the result of the expression is the one which loses the least information:
#include
int main(int argc, char *argv[]) {
double numerator = 7.0;
int denomenator = 2;
// no warnings with -Wall because the result is a double
printf("%f\n", numerator/denomenator);
return 0;
}
In Perl, because it’s dynamically typed, the result of an mathematical expression is simply whatever result has the most information (that’s an oversimplification):
$ perl -le 'print 7/2'
3.5
If you need the occasional performance benefit you can gain from integer math you can tell Perl to discard the extra information:
$ perl -Minteger -le 'print 7/2'
3
In other words, you request “incorrect” answers, rather than assuming them. That strikes me as far more intuitive for a ‘dynamically typed’ language, so I’m clearly misunderstanding something here. What’s the benefit of defaulting to integer math?
As an aside, the counter-argument I could see is the following:
perl -le 'print 4 + "3 apples"'
7
Issues like that are why we encourage programmers to enable warnings:
$ perl -wle 'print 4 + "3 apples"'
Argument "3 apples" isn't numeric in addition (+) at -e line 1.
7
Source: ONLamp.com This week on the Perl 6 mailing lists
“Your faithful Dynamic Environmentalist”
– closing signature of Bob Rogers in ‘RFC: Proposal for dynamic binding’
Language
[svn:perl6-synopsis] r13487 - doc/trunk/design/syn
Last week,
a commit from Larry Wall related to expanding tabs led TSa to ask
if array equivalence should be defined in terms of Bags. Larry replied
that he felt most people would prefer to look at Sets and Bags as Hashes,
so he will not include Sets and Bags in the smartmatching table. Darren
Duncan also felt that the current summary in Synopsis 6 was adequate.
This week, TSa responded to Darren’s request that any change requests
be explained in detail. According to TSa, the intent was not to change
the synopsis but to have a few points clarified on list, such as the
subtype relationship between Set and Bag. TSa also asked if KeyHash,
KeySet and KeyBag are forced in to sigiled variables. Darren replied
that he would expect that they would work like hashes.
[svn:perl6-synopsis] r13488 - doc/trunk/design/syn
In this commit, Larry Wall clarified the relationship between Set/Bag and
KeyHash.
[svn:perl6-synopsis] r13489 - doc/trunk/design/syn
Larry Wall elaborated on gather, which has been modified to be more
like do in that it allows any statement.
Gather/Take and threads
Given a gather block which spawns multiple threads,
Joe Gottman wanted to know if it is guaranteed that no object returned
is lost, given that the relative order of items returned is
indeterminate.
Parrot Porters
RFC: Proposal for dynamic binding
This thread was started by Bob Roger’s proposal for dynamic binding.
He compared two options, and later gave an analysis of a third (STM)
at Leopold Toetsch’s request.
Last week, Allison Randal responded to the proposal with the question of
why dynamic binding should only apply to globals. She stated that
the proposed implementation was not being approved, but noted that one
of Bob’s ideas concerning threads was of particular interest and likely
to be included at some point. Bob replied in depth to the points she
raised and asked if he could improve the proposal or if he should give
it up.
This week there was further discussion between Allison and Bob.
[perl #40958] [BUG] - can't iterate subclass of ResizablePMCArray
chromatic responded to ticket [perl #40958] by including a patch which
demonstrates the problem in the iteration code within the PMC. He noted
that this is not the correct fix.
[perl #40966] [BUG] Parrot core dumps in perl6 (possible GC/pointer bug?)
Earlier, Patrick R. Michaud reported a bug in ticket [perl #40966].
This week, Matt Diephouse responded. He had seen the error in a different
test, and identified the failing assertion. The problem seems to be that
constant strings are being garbage collected too soon. He supplied a patch
to not collect any constant PObj headers, but was not certain that was
what should happen.
Leopold Toetsch replied that if they were being collected, they were
being initially created in different object pools and then stored as
constants. He requested information about the origin and
contents of the constant, in order to track down where it was being created.
Initial feedback on PAST-pm, or Partridge
Earlier,
Allison Randal initiated a discussion on Partridge (PAST-pm) with a post
of her comments on user experience and implementation.
One subthread which developed dealt with a number of unrelated points.
Leopold Toetsch joined Allison and Patrick R. Michaud in this thread.
One of the topics involved Parrot limitations related to :init methods.
This week, Allison responded to a proposal from Patrick and asked if he
had thought further about the syntax for initialization. She also agreed
with treating moving code generation out of POST node objects as low priority.
Patrick replied to some of the points.
[perl #41020] [PATCH] pmc2c.pl functionality extracted into separate package
Earlier,
in ticket [perl #41020], James Keenan supplied a patch to make
pmc2c.pl easier to test. This involved putting most of the subroutines
in a new package. He fixed a problem with GetOptions but thought there
were additional corrections to be made.
This week, James wrote that he had underestimated the challenges in testing
Parrot build tools. He explained the problem, which involved the files
which exist and the state of the system at the time that the tests are
run, and concluded by asking what was the goal of testing the build
tools.
[PATCH] tru64: compile (src/nci.c) and runtime (src/memory.c)
Jarkko Hietaniemi submitted two patches. One was to allow the Parrot
trunk to compile in Tru64, and the second one was to eliminate some
core dumps.
[perl #41044] use warnings not clean
In ticket [perl #41044], Will Coleda reported a problem with
loading the platform and local hints file.
[perl #41047] [BUG] :multi doesn't work with :outer
Patrick R. Michaud created ticket [perl #41047] to report an error
with the :multi pragma when :outer is present. Matt Diephouse reported
it fixed in r15971.
[perl #41051] [PATCH]: Configure.pl: Spell out what 'ICU' means
James Keenan created ticket [perl #41051] to request that the POD
in Configure.pl use ‘International Components for Unicode’ instead of
‘ICU’ for clarity. Will Coleda applied the patch as r16021.
[perl #41052] [PATCH]: docs/configuration.pod: Small grammatical corrections
In ticket [perl #41052], James Keenan included a patch to correct
grammar in docs/configuration.pod.
Bug Day!
chromatic suggested a virtual gathering on the 16th in #parrot. The
purpose of the meeting is to examine the bug database to verify,
fix, or resolve issues. Additionally, this meeting would serve
to help curious newcomers get started. Lee Duhem felt that some
examples could be cleaned up to make it easier for people to get
started.
[perl #41053] [TODO] More useful dumping of Env PMC
Bernhard Schmalhofer thought that generic Hash dumping functionality
would make it easier to see things such as the Env PMC. This request
was ticket [perl #41053].
[svn:parrot-pdd] r16036 - trunk/docs/pdds/clip
Allison Randal added additional notes to the overview PDD on the target
platforms for Parrot. The requirement for the 1.0 release of Parrot is
that it be supported on major versions of Linux, BSD, Mac OS X and
Windows.
[perl #41055] [BUG]: 'Argument is not numeric' warning in Darwin configuration
In ticket [perl #41055], James Keenan registered a bug with running
perl Configure.pl, which seemed to be related to having a 3-level
version number.
Acknowlegements
This summary was prepared using
Mail::Summary::Tools,
available on CPAN.
If you appreciate Perl, consider contributing to the Perl
Foundation to help support the
development of Perl.
Thank you to everyone who has pointed out mistakes and offered
suggestions for improving this series. Comments on this summary can be
sent to Ann Barcomb, kudra@domaintje.com.
Distribution
This summary can be found in the following places:
use.perl.org
The Pugs blog
The perl6-announce mailing
list
ONLamp
See Also
Perl Foundation activities
Perl 6 Development
Planet Perl Six
Source: ONLamp.com Quite a few months have passed since my last post, as cryptography-related endeavors, and family matters, most importantly, have occupied about all of my time that’s available for occupying. As far as cryptovirology research is concerned, results are coming together, and what began as a single paper a couple of years ago, has branched off into separate avenues of design philosophy. One particular branch deals with the development of a cryptovirus that is efficiency-oriented, with an emphasis on speed and reasonable security trade-offs. The original cryptoviral information extortion attack, by Dr. Adam L. Young and Dr. Moti M. Yung, was built on public-key cryptography and an on-board random number generator, with the latter proving to be the bottleneck, responsible for consuming over half of the time the attack takes (i.e., roughly 11 seconds). A couple of years ago, I looked into stripping these two components and playing around with different security trade-offs. Roughly speaking, what I ended up with is a structure that uses a symmetric block cipher and block cipher-based MAC, to satisfy confidentiality and integrity requirements, while sending the keys in - yes, you’re reading correctly - plaintext.
The reasoning behind this is practical. The cryptovirus needs a carrier. All that is necessary is for the carrier to drop the cryptovirus onto the host, and for the cryptovirus to perform its operations. If the carrier is fast and discreet enough in getting the cryptovirus to the host, this should compensate for the plaintext keys that are riding shotgun with the cryptovirus. We’ve ditched asymmetric cryptography, and already regain over half of the attack’s operational time, by generating key material beforehand, so we’re already looking at an attack that takes less than half the time of the original. By using fast implementations of AES, we can achieve a completely standardized approach, complete with tight security bounds. As of now, I’ve chosen AES in CTR mode, which is IND-CPA secure, as well as CMAC-AES, which is a SUF-CMA MAC; if used in the Encrypt-then-Authenticate composition, this renders IND-CCA2 security and achieves INT-CTXT, for some constructions of this attack. The key to understanding all of these acronyms will grace the end of this post. The important thing to know here is that I’ve just described the basic setup for a cryptovirus that is just as stout as any good, defensive system that uses the same cryptography.
For those who aren’t familiar with the idea of a cryptoviral information extortion attack, here’s how it goes. We have an adversary and victim. The adversary desires some resource that the victim has; we’ll call this “H.” (I’m following the naming convention of the original attack by Dr. Adam L. Young and Dr. Moti M. Yung.) To get this resource, he’ll need some leverage, so he designs the cryptovirus to look for some critical data on the host victim; we’ll call this, “D.” When the cryptovirus finds D, it encrypts it, using AES in CTR mode, overwriting the original. When it finds H, it computes a MAC on it, using CMAC-AES. (This implies that the cryptovirus houses two symmetric keys: one for encryption and one for authentication.) At this point, both keys have been overwritten in RAM, and the cryptovirus instructs the victim to send H, along with the corresponding MAC, to the adversary. Upon receiving this from the victim, the adversary will compute a MAC on H using the authentication key (remember, the keys are precomputed, so he has a copy) and CMAC-AES. If the MAC he computes matches the MAC that accompanied H, then H is valid. Otherwise, the victim tried to send some bogus substitute, H’. Because the victim hasn’t any knowledge of the authentication key, he can’t compute a valid MAC on a bogus file to send in place of H.
Theoretically, if the victim cooperates, the adversary sends the encryption key used to encrypt D, such that the victim can decrypt it, thus restoring the critical data. The problem here is that the trust model is based on a relationship between a victim and adversary. Traditionally, we look at channels between Alice and Bob, where trust is implied. However, there is no balance of trust between a victim and adversary. I’ve addressed this issue, theoretically, with an arbitrated, game-theoretic protocol (i.e., a trusted third party, who treats the exchange, between the victim and adversary, in terms of a non-zero-sum or zero-sum game.) I’ll leave this for another rainy day, though. Now that you have the contextual gist of the attack, I’ll pose my questions.
For those of you in charge of policies for handling adversarial attacks, how would you go about handling a cryptoviral information extortion attack? The obvious defense is a good back-up, of course. However, it seems plausible that with enough a priori information of the system (i.e., insider attack), a cryptovirus could be tailored to attack prior to a scheduled back-up. For information that is archived in relatively short time intervals, perhaps the cryptovirus’ fast execution time can increase the viability of this tailored approach. After all, we’re looking at seconds.
Some might be quick to respond, “You should just ignore the adversary and never give him what he wants.” Failed attempts at cryptoviral information extortion attacks have been reported, where the “H” that the adversary demands is in the form of a monetary payment. If this demand will cost more than the data, being held for ransom, is worth, then sure, that’s a good argument for ignoring it. However, what about when this isn’t the case, and it’d be worth it to pay the ransom? Others might retort, “But what if the adversary doesn’t follow through with his end of the bargain?” Theoretically, it’s in the best interest of the adversary to play fairly. Keep in mind that attacks are often reported and publicized. If the media reports reflect the adversary as someone who never pays up, future victims are less likely to take the risk. However, if the reports reflect an adversary who always holds up his end of the bargain, future victims may give in, if statistics show them that there’s a promise of hope in recovering their data. Again, this is just one theory.
Oh, and here’s some alleviation from the acronym jungle you had to venture through, to get to this point:
AES = Advanced Encryption Standard (I know, I know; y’all probably know this one.)
MAC = Message Authentication Code
CTR = Counter Mode
CMAC = Cipher-based Message Authentication Code
IND-CPA = Indistinguishability under Chosen-Plaintext Attack
IND-CCA2 = Indistinguishability under Adaptive Chosen-Ciphertext Attack
INT-CTXT = Integrity of Ciphertexts
SUF-CMA = Strong Unforgeability under Chosen-Message Attack
If you want a friendlier treatment of introductory cryptoviral extortion, that even a kid might enjoy reading, I’ve written some things about it here. Pardon all the thinking-out-loud, but now that I’ve laid out the fundamental context, it’ll be much easier to get to the point with future research. Until then, have a good one and stay warm, if it’s winter where you are. It’s downright cold, here in the South, tonight. Almost 10 degrees. Here’s hoping that this research is as fruitful as my fireplace is toasty.
Source: ONLamp.com Perl fans rejoice. This year we have two advent calendars. The Perl Advent Calendar reviews one fantastic CPAN module every day until Christmas. (We’ll also send you a book of your choice if you contribute a review.) Similarly, the Catalyst Advent Calendar gives one tip or trick every day for using the Catalyst web framework.
Source: ONLamp.com It’s been three months since PHP Versions in the Wild. What does Nexen report about PHP version adoption statistics for November?
I find this information all too fascinating; most of the software I write
isn’t web-available, so I never get to see who uses new versions or old
versions nor any statistical information about who prefers what.
Nexen’s PHP Adoption Stats for November 2006 show that PHP 4.4 has surpassed PHP 4.3. PHP 5 is in the double-digits, but it’s still a fraction of PHP 4’s popularity, despite its climb.
Fortunately, PHP before version 4 barely registers on the graph.
Still, I can only imagine how frustrating it must be to work on PHP 6 while
realizing that, if PHP 5 is any indication, it’ll be two years before a
significant percentage of users upgrade.
Source: ONLamp.com I was impressed with the size of the XML2006 conference (a name that must have been chosen by a designer, not by anyone who has to write Web pages), which took place in Boston this week. Rooms were overflowing for many topics, indicating that several large industries and government bodies have settled on XML for document storage and automated text manipulation. Microsoft Office still seems the editor of choice for most people writing and editing documents. The poor XML output of Office is a major irritant.
Self-processing data
No one is more interested in XML processing than the XML specifications committees. Over the years they’ve entered ever narrower corridors in the specification maze, forging specifications that determine not only what XML stores, but how the stored data is processed. The most salient example is XSL, but I found two new ones at the conference.
I’ve never quite seen the need for XML-driven processing. Programmers have been quick to use their favorite procedural languages to parse and manipulate XML. What happens when the processing moves to XSL is that procedures are replaced by declarations. It’s a major shift in thinking for programmers to express their needs in declarations. The XSL goal of self-processing data (data that tells you how it’s meant to be processed) is a complex task.
The new efforts I heard of along these lines at XML2006 were Remote Events for XML (REX) and the XML Processing Model (XProc). Like XSL, they take on tasks that have been done by languages outside XML for years, and put them between angle brackets.
REX deals with the activities that current Web pages perform through onclick and onsubmit functions, along with other activities that (from the point of view of the programmer) look like events. If this effort at standardization works, the JavaScript functions that respond to such events will be replaced by REX XML documents.
XProc is meant to replace build procedures, which are currently done through techniques ranging in sophistication from manual activities and Unix shell scripts to Ant or commercial business processing tools. XProc looks more procedural than declarative. One defines the types of processing (such as the use of XSLT) and then strings them together in an XML document.
Norm Walsh, leader of the working group, was questioned heavily at his XProc presentation on why they want to duplicate so many other tools. As with other such specifications, the hope is to achieve more portability and predictability.
Skeptics about these new bricks in the XML edifice could do well to quote Douglas Crockford, the JavaScript expert who standardized JSON. In one of the deepest statements I heard at the conference, Doug said, “Being well-formed and valid is not the same as being correct and relevant.” In context, this meant that the automated processing done on XML documents was not the type of information programmers really need to worry about. Doug followed up by saying that ultimately, every application is responsible for validating its own data.
JSON
We are now no longer talking about XML in this blog; we have switched to the entirely different subject of JSON. JSON is a structured plain-text format that has no pretensions to being anything but a structured plain-text format; one couldn’t imagine a three-day conference about JSON.
Since it’s in widespread use, stable (Doug hasn’t even assigned a version number to the standard, because he doesn’t expect it to change), and thriving, the most urgent issue is getting his JSONRequest protocol implemented by browsers. He pointed out that mash-ups, because by definition they bypass the normal “Same Origin Policy” for web pages, are currently using nonsecure data transfer methods that leave browsers open to activities by untrusted sites. A JSONRequest would limit the data sent and received, notably by omitting client cookies.
It was gratifying to see that the JSON talk was one of those bringing an overflow crowd, who definitely had challenging questions but seemed highly interested.
Source: ONLamp.com X.org includes several useful utilities and features that almost no one knows about. You can accelerate your display, nest one X server in another, distribute your session across multiple monitors on different machines, and watch a session on another machine. Dru Lavigne explains.
Source: ONLamp.com Blessed are the toolmakers, writes Piers Cawley. I agree.
Maybe it seems counterintuitive that some of the best toolsmiths I know are stalwart Perl programmers. I know the stereotype: we’re all hackers and script kiddies who glue together applications, couldn’t commit to a static type declaration if we could recognize one, and write unmaintainable piles of goo once we get past ten lines of code (as if you need more than ten lines of code to do anything in Perl).
Yet that doesn’t explain why there are so many useful libraries for programmers for and by Perl programmers. Maybe it’s the spirit of tinkering, or maybe it’s that the language design deliberately avoided making polemic statements about one particular way to do thing, or maybe some of the criticism is correct in that there are some definite warts on the language. (I think I can say that, as I’ve written and used Perl 6 code that does not suffer from those mistakes.)
There’s a definite sense of play required to solve a problem by inventing a new tool rather than giving up or doing it by hand or writing a one-off that you never refine or, worse, throw away immediately.
I tried to document that sense of play and my amazement at the wonderful things people can and do with this language in Perl Hacks. We found 101. There are probably 1001 more within reach.
I’m sure the same is true of other languages as well. Watch the toolmakers; they’re the ones pushing languages and libraries and ideas in completely new directions.
Source: ONLamp.com In Can’t Someone Else Write/Deploy It?, I pointed to Tony Stubblebine’s first exploration of Salesforce.com’s new API. He’s updated his series with a second article, Using the Salesforce.com API.
Don’t fret; there’s more Perl this time. In particular, it takes only a little bit of glue to connect the comment engine of your weblog software to your database of prospective contacts. I can think of several interesting projects from there, starting with graphing your range of influence….
Source: ONLamp.com A newly unveiled company named Kryptiva is trying to meet all the important requirements for securing email. Many companies have offered encryption, digital signatures, and proofs of delivery for electronic mail. But up to now, according to Kryptiva founder and CEO Karim Yaghmour, each design has embodied an important flaw that reduces either usability or security. (Karim is the author of Building Embedded Linux Systems, which I edited. Kryptiva is proprietary software.)
I won’t say much about Kryptiva’s architecture, which is laid out on one of Kryptiva’s web pages. What interests me most, among their discussion of requirements, is their way of trying to provide features that are usually mutually exclusive.
Kryptiva’s designers reject web-based mail for several reasons. Given the widespread success of phishing attacks, too many users could be tricked into giving a masquerading site their valuable information. If the web site being visited is maintained by the vendor, an enterprise might not want to entrust its sensitive email to the site. Finally, Kryptiva email can use the user’s familiar email client (the initial version works with Outlook, and a Thunderbird plug-in is coming) so that users can continue to manipulate their mail folders the way they’re used to.
The downside of integrating with popular email clients is that Kryptiva can’t do its job unless people on both side download and install a plug-in. Without the plug-in, a recipient can read signed mail, but not mail that’s encrypted or requests a proof of delivery.
Kryptiva can be installed on the enterprise’s own servers, so that it doesn’t have to interact with a third party. It is built to be integrated with other parts of email infrastructure. For instance, it can authenticate users in an LDAP directory to reduce the number of passwords required per user, and it can consult anti-spam, anti-virus, and anti-phishing products. No key ever has to be transmitted over the network. Kryptiva is also infrastructure-independent, meaning that an enterprise can add it to whatever network of servers they have without modifying the existing network. They can also deploy it selectively and incrementally.
Finally, Kryptiva is stateless, which makes it more scalable.
Source: ONLamp.com The winners of the Sysadmin of the Year contest were announced this morning. Do you ever hug your system administrator, or do you go to him or her just when you have something to complain about? Well, if your sysadmin is an extraordinary figure, you may have a chance to show your appreciation in a future contest, because it seems this contest has satisfied the expectations of the key sponsor, Splunk.
I profiled Splunk earlier this year, praising their contemporary approach to solving system admiinistration problems by linking and providing data mining tools for large quantities of data, and for incorporating end-user feedback into the solution sets. Although this contest gained them some new potential marketing contacts, it was a contribution to the field, endorsed by a wide range of companies you can find on the contest’s home page.
Winners included an administrator who stayed in a burning building long enough to rescue his company’s data (thus saving not only the business but the key information of their customers), someone so popular at his web hosting service that 700 individuals submitted separate endorsements, and other worthy professionals.
Source: ONLamp.com Fritz Mehner’s amazingly useful perl-support Vim plugin supports Perl::Critic. (Okay, it’s done so for a year, but he just mailed me to make sure that I knew.) Fantastic!
See the perl-support Vim plugin screenshots or the perl-support Vim plugin help file for more information.
Thanks, Fritz!
|
