Since ORF 3.0, we sign every ORF binaries with Vamsoft’s Authenticode code signing certificate. This is great, because you can be sure that you have the original files from Vamsoft and no tampering was made with them. This practice is also encouraged by Microsoft and signed components probably will be a requirement for the Windows ‘Longhorn’ Server Certification Logo program.

When we released the Vamsoft Image Spam Agent extension for ORF, we signed the agent imgspamagent.exe binary as usually and let it go. Then we started receiving reports about timeouts running the agent and we did not have any idea why only specific servers were failing to run the agent and why the agent worked when they tried running it from command-line. And we were struggling to find an explanation until one of our clients (thanks!) found that the agent tries to connect to crl.verisign.com:80 every time it starts. Cool.

I mean, uh? Pardon me?

Obviously, the timeout was caused by the security settings of the affected servers—these servers blocked HTTP access to crl.verisign.com, thus the timeout error. But what makes the agent trying to visit VeriSign if we did not add such code to it?

Here is the trick: Windows was checking the Certificate Revocation List (CRL) of VeriSign to make sure that our certificate was not revoked, e.g. because our certificate was compromised and now bad people are trying to impersonate Vamsoft. The funny thing is that Windows does not check the CRL for regular ORF binaries, because they were written in Delphi, but the agent was written in .NET/C# and .NET programs behave differently.

According to this blog entry, if your .NET assembly is signed using Authenticode, every time the assembly is loaded, Windows performs the Certificate Revocation List check (depending on the user settings). This potentially means a couple of seconds wait to get your .NET program started or even more if the firewall prevents the program from accessing the CRL.

Now we know. If you sign it, it won’t run.

Has anyone else seen this? Every once in a while, Outlook 2003 starts hanging on every email that has attachments or embedded images, about for a minute or so. It is utterly annoying and I did not find any resolution for this on the Internet—I guess it is either the anti-virus software, or Outlook tries to do something with the network that eventually fails, but uh, come on, should not it just work?

In the last few months, I talked with quite a few ORF users who wrote External Agents to implement tests based more complex rules than otherwise allowed by ORF. I have also seen a few good agent proposals that never seen the light and I started wondering why and how could we help these agents born.

The first idea was to write an article about creating agents, with code samples in various languages from C# to PHP, etc., but the more I was thinking of this the more pointless the article seemed. After all, if you already know how to program in Perl, parsing command line parameters would not be big trouble, right? So why not start writing the agent?

My guess is that starting is hard. Banality or not, writing an agent takes a couple of things, like a command-line parser, a MIME parser, maybe a config reader/writer, a testing environment, etc. commonly called “PITA” and when you suddenly realize that, your great agent idea just does not seem that great.

Well, I may be easily wrong here, but if that is a real problem, would not a common source code platform for creating agents help?

What I have been thinking of is an open source C# external agent backbone, hosted on a collaborative development site such as SourceForge.net. The platform would already have most common things in place, like the command-line parser or the MIME parser. It would make adding new tests very easy (just implement a C# interface) and would have a built-in test environment. Due to the “plugin” architecture, you would need to run just one agent (thus save resources) and the end user could select which tests to run.

What do you think, would you participate?