Category: Technical

MyEclipse 3.8.1

MyEclipse 3.8.0 GA, released early last week, had a lot of bugs because the MyEclipse team decided to throw in IBM's contribution to Eclipse's Web Tools project which weren't production quality yet.  It's the price one has to pay for being too eager.

Thankfully, they made up for their mistake in short order by releasing version 3.8.1 last Sunday which fixes the most apparent bugs.  I am sure there are bugs yet to be unearthed, but I used it last night and found no serious problems that prevents me from using it.  They even added Sysdeo-style webapp project layout I mentioned before.

For $30 per year, MyEclipse offers a truck load of essential tools for server-side Java developers and unreasonably responsive technical support.  Think of MyEclipse as buying timeshare on a talented blacksmith.  If you want something done, it's just a matter of screaming the loudest.  Highly recommended.

Spring Framework

While I was playing around with MyEclipse 3.8.1 (quickly delivered butt saving release to make up for the silly 3.8.0 version), I got sidetracked into JavaServer Faces (definitely useful but seems to have the same disagreeable feel to it as Struts) and then fell into Spring Framework.  Hmm.  I liked what I read in this introductory article about the framework.

While I am not too hot on IoC (Inversion of Control), I like the way Spring guys implemented IoC.  Most of all, I like the way Spring makes components easier to test by reducing dependency and enhancing configurability.  Apparently, there is an effort to ease integration between Spring and JSF which I'll have to take a look at real soon.

Update:

There is a seemingly very nice Eclipse plugin for Spring Framework you should take a look at if you use Eclipse and are interested in giving Spring a try.

Colliding Hash Destroys Western Civilization

I don't want to alarm you all, but a handful of papers presented at Crypto 2004 conference last week could force most, if not all, security software, services, and certificates to be upgraded in the near future.  Why?  Because strength of two popular hashing algorithms, MD5 and SHA-1, are being questioned by those papers.  These algorithms are used literally everywhere so, if these papers are right, the impact crater will be huge.

MD5 was known to be weak before but, according to one of the papers, it's much weaker than previously known.  How weak?  Supposedly, just a few hours on your desktop PC will break it, meaning you can find a bogus set of bits that produce the same hash as the bits you are trying to spoof.  Oy!

Viral Multimedia

News.com is reporting that six critical vulnerabilities were found in libpng, a widely used library for displaying images in PNG format.  Note that libpng is open source yet no one noticed those vulnerabilities until now.  In my opinion, libpng being free and open source actually contributed to the scalability of attacks that could be launched through those vulnerabilities.

Even more disturbing is that, while patches for vulnerabilities found in end products like IE and Mozilla are quickly and widely distributed, patches for vulnerabilities in libraries often never make it to the end products that use the faulty versions of the libraries for various reasons.

How would you know if any of the infrequently used programs and utilities you have in your computer use vulnerable versions of popular libraries like libpng?  You don't.  Your only protection is that there are easier targets.  Unfortunately, vulnerabilities in multimedia software is starting to look more attractive for hackers.

Most likely avenue of viral multimedia attack is using porn to drive wide distribution of video codecs (compression/decompression) software.  They don't have to carry trojans either.  All they need are a handful of intentional defects for them to use as a wedge later.  They can even release the software as open source since the chance of being discovered before harvest time is rather low.

Consider this a sort of social engineering attack against the little head.

SOAP Interop by Passage

I spent the last couple of days designing a web service API.  Last time I did that was more than six months ago, so I forgot a lot of little tricks and gotchas which I had to relearn.  To save you some trouble, here are some notes:

Getting Started

Currently, Visual Studio .NET is the best environment to start in for web service design.  So I started a Web Service project in VS.NET 2003, wrote my API classes in C#, and launched the service to get WSDL.  I also wrote a .NET client to polish the API.  BTW, VS.NET generates doc/lit style web service which is usually what you want.

I used only simple datatypes to avoid interop issues later.  Complex datatypes should be used only if the benefits are clear because most binding generators will map them to classes which have to be instantiated on both side.

You might want to go easy on the Enums too because VS.NET uses enum symbol names as string literals.  I dislike verbose XML, so I used simple character flags (similar to fopen mode flags) instead as a compromise between fully descriptive strings and bit flags although I used strings to represent the flags for extensibility.

Interop by Passage

Now that I had a WSDL, I fed it to Apache Axis's WSDL2Java tool to generate Java bindings.  I ran into several interop issues with Axis 1.1 so I ended up using Axis 1.2beta2 after a few hours of agony.  Since the service I was designing will be implemented in Java, I generated server-side bindings first and hosted them in Tomcat.

Once the Axis-based service was running, I added a Web Reference to it in my C# client and made sure results from the Axis-based service matched the .NET-based service.  Note that at this point, you have two WSDL, one from each side.  You'll eventually have to let one of them go depending on where the service will be hosted in a Java web server or ASP.NET, but it's nice to have both for developing clients in other languages.

At this point, it's smooth sailing as far as interop is concerned.

Sysdeo Tomcat Plugin 3.0 Released

Version 3.0 of Sysdeo Eclipse Tomcat Launcher plugin was released today.  According to the readme file (txt), source code debugging should now work again although existing Tomcat projects will have to be tweaked by hand:

When using Tomcat 5, Eclipse does not stop on breakpoints set in generated java files for JSP. This is fixed only for new Tomcat projects, for existing ones follow those steps:

…

My version of the instruction:

  1. Open your Tomcat project's 'Properties' dialog.
  2. Goto 'Java Build Path' >> 'Source' panel.
  3. Make sure 'Allow output folders for source folders' checkbox is checked.
  4. Select and expand Tomcat 'work' directory in the list of source folders above the checkbox.  If you don't have it, add it.
  5. Select the last child item (should be 'Output folder: blah') and click-on the 'Edit…' button on the right.
  6. Set or browse to the 'work' directory.
  7. OK, all the way back.

The problem was that, while the 'work' directory was known as a source folder, there was only one output folder (usually 'bin' or 'WEB-INF/classes').  Since Java files generated from JSP files are compiled in-place by Tomcat, object files (.class) ended up in the 'work' directory instead of the default output directory where Eclipse debugger was expecting them.  So the fix was to tell Eclipse that .class files for the Java files in the 'work' directory are within the same directory.  Duh.

Thanks to Bruno Leroux for writing Sysdeo Tomcat plugin.  Hey, Bruno.  Where is your tip jar?

Helping Users Protect Themselves

Some soundbites rom The weakest security link?  It's you, a recent News.com article:

People are the weakest link.

Education is the first line of defense.

People are still not thinking before opening an (e-mail) attachment.

The big problem with educating employees on security issues is being able to track whether you're getting through to people.

Everyone knows about viruses, for example, but half the people don't have antivirus software.

While I agree that people are the weakest security link and even the world's strongest lock is useless if not used, I don't think that training employees about security and tracking security policy compliance is enough to fix the problem.

What's the missing ingredient?

Helping users protect themselves.

Just as training drivers all about driving hazards is useless if the driver is a blind, users can't protect themselves if they are not fully aware of what is going on around them.  Was there any suspicoius activities involving my account since last time I signed-in?  Is there someone accessing my online bank account at the same time I am?

If a hacker broke into your computer remotely and used it to send phishing e-mails or spams, how would you know?  Unexpected blinking network connection lights?  Something is wrong when it's easier to keep track of friends logging into their computers than strangers logging into our computers.

Unfortunately, most designers of today's security products see the user only as an input device: I'll give you access to these if you give me this and that.  This mindset encourages people to be more concerned about lossing access than gaining protection.  This is why people reuse passwords and write them down in easy to find places.

Security companies need to start thinking more about helping users protect themselves by providing more information about what is going on and letting them play an active role in security.  If something suspicious is going on, don't let the information sit until probability crosses some security policy thresholds.  Inform the user rightaway.  Remember that, to the user, no news is good news so they'll think what they are doing is all right unless they are warned away from dangerous edges.

<

p dir=”ltr” style=”margin-right:0;”>There are ways to inform the user without getting in their way too much or making them paranoid.  For example, if an e-mail message has executable or unknown file attachements, mark it visibly as potentionally dangerous.  Hyperlinks should always clearly present the destination URL to the user instead of hiding it behind a possibly bogus text.

.NET Applets

Did you know you can write 'applets' in .NET?  If you have .NET Framework installed, look at your Internet Explorer's Internet zone security settings, specifically the .NET Framework-reliant components section.  Unless you changed your security settings, your IE is configured to silently download and run both code written in .NET.  It doesn't matter whether the code is signed with Authenticode or not.

A good example of .NET applets/controls — note that Microsoft probably calls them something else (web controls?) — is this VG.net demo.  VG.net is a pure .NET vector drawing library.  BTW, you'll need Windows, IE, and .NET Framework to see the demo.  Once you have seen the demo, View Source of the web page.  It has nothing but reference to a style sheet and an object tag.

The style sheet is just used to stretch the object tag to fill the page.  The object tag references a DLL, WebControls.dll, located at myxml.com website.  IE loads the 'applet', notes that it's a .NET library, checks IE security settings, and runs the DLLs inside a sandbox of sort for security sake.

A brief visit to the .NET Runtime Security Policy reveals that, for the Internet zone, .NET 'applets' can use File Open dialog, paint into the 'safe' top-level windows (probably means the window they instantiated in), print 'safely' (huh?), and are given 10K of domain-specific isolated storage as well as a private clipboard, size of which may or may not be counted toward that 10K.  I am not sure whether the isolated storage is persistent or not.

I am not too worried about the Internet zone security policy, but the security policy for LocalIntranet zone does raises some concerns.  For example, there is no UI restrictions at all and isolated storage size limit is set to some huge number.  Note that I haven't figured out the specific implications of these settings yet and I doubt Microsoft engineers haven't vetted the sanity of the default security settings.  So I think it's early to sound any alarm.  But I am intrigued and disturbed.

Firefox Blues

For some reason, Firefox address bar stopped working today.  It simply stopped updating and also won't accept new URLs entered into it.  Only changes I made to the system today were latest set of Microsoft security patches and Sage, a Firefox extension which Tim Bray recently mentioned.

I uninstalled Sage but the problem persisted.  So I proceeded to uninstall all the extensions and restarted.  Still dead.  So I uninstalled Firefox 0.9.1 completely and went to the Mozilla website.  Woo.  Firefox 0.9.2 was out.  So I installed it only to find the problem still there.  Hmm.  Could it be that those five Microsoft security patches I installed today somehow disabled Firefox address bar?  I doubt it because Mozilla 1.6's address bar still works.  Has Sage got too clever and messed up some Firefox settings and failed to restore it during uninstall?

I don't have the answers yet because I don't have time to dick around just so I can point a finger at Microsoft.  I am sure there will be an uproar in no time if it is true so I am going to wait and listen.  Meanwhile, I am back on IE.

Update:

After posting, I realized that Mozilla application data was still in the Documents and Settings directory.  Wiping that out fixed the address bar.  So it looks like the problem was Sage.  That's the trouble with being extension happy.

MyEclipse

Since Sysdeo doesn't let me debug JSP, I subscribed to MyEclipse which, at $31 a year, seems like a good deal considering the range of features it offers.  What I didn't like was that MyEclipse tries to be too smart, too helpful, and makes too many assumptions about how MyEclipse would be used.  MyEclipse assumes it's users are J2EE developers and it's features are arranged to support that.  In my case, I just want to debug JSPs in existing projects.  But when I tried to add WebProject capability to my webapps, it wouldn't let me because the root of my project is the web root directory instead of using a subdirectory as WebRoot.

MyEclipse also disables features until certain conditions are met.  Since the conditions are not visible, figuring out how to enable the feature ends up being a game of hide and seek.  For example, Struts capability is grayed out until WebProject capability is enabled.  While this makes sense logically, it's being unnecessarily helpful since addition of Struts capability doesn't actually depend on anything to be added.

Anyway, I am going to create a blank WebProject and figure out what the WebProject wizard does so I can manually convert my projects.

Update:

I am giving up on MyEclipse for now.  They said they will looking into supporting projectroot==webroot in the future so I'll try MyEclipse again when that happens.  Meanwhile I wasted $31.  Oh, well.  Its a nice bundle of functionalities though.  I particularly like the Struts flow modeler although I suspect it is a good way to mess things up pretty badly with a few errant drag and drop.

I did try changing the layout to the way MyEclipse likes it but still found lots of little annoying overly helpful 'features' and hastily/half implemented features.  It's a nice looking half-finished cruise boat in motion IMHO.  Now I am hoping Sysdeo 3.0 final will have JSP debugging fixed.