Ant signjar error: keystore load: Too many certificates in chain

I just ran into an error building our system using ant while documenting building a project under Windows. (Normally, we build under Unix).

The error was coming from the Ant signjar task:

jarsigner error: java.lang.RuntimeException: keystore load: Too many certificates in chain

A google search turned up multiple references to the string “Too many certificates in chain” but only one hit to this error with regards to the signjar task. Even then, that reference did not contain a solution. I investigated further and realized that when the keystore was checked into CVS, keyword expansion was not set to binary on the file. When the file is checked out on our Unix build machine, the keyword expansion was not causing an error. When the file is checked out on a Windows box, the keyword expansion breaks the build. Changing the keyword expansion to binary fixed the error.

 

Seattle Area Software Testing Related Organizations

I was recently asked by a coworker about local testing related organizations and I put together the following in my response. I thought it would be useful to capture the information in one spot so I can refer people to it in the future:

Seattle Area Software Quality Assurance Group
http://www.sasqag.org/

WSA Quality Assurance special interest group
http://www.wsa.org/events/sig/detail.asp?sigID=47

Seattle Eastside Area Software Process Improvement Network (SeaSpin)
http://www.seaspin.org/

American Society for Quality (ASQ) Seattle Section
http://www.asq-seattle.org/

IEEE Seattle Section
http://www.ieee-seattle.org/

 

Trustworthy Software Systems

I attended a great lecture by Professor Larry Bernstein of the Stevens Institute of Technology. More on Professor Bernstein can be found at his site.

The topic of the presentation was “Trustworthy Software Systems”. Professor Bernstein is a great speaker and shows genuine enthusiasm for his work. He defines trustworthy software as being safe, reliable and secure. On one slide, he defines these terms as:

  • safe – does no harm
  • reliable – no crashes or unexpected behavior
  • secure – no hacking possible
  • He points out that the requirements which make a system trustworthy are non-functional.

    He referred the audience several time to “Trustworthy Systems Through Quantitative Software Engineering ” by Larry Bernstein and C. M. Yuhas. I am planning on becoming more familiar with his work in this area.

     

    Test Values: String (Format String)

    In a prior post, I described various values I use to test strings. However, there are some special characters which may result in unexpected behavior or security vulnerabilities when they are encountered within a string that is later displayed in the application. The specifics of how these works depends on the capabilities of the programming language – so research how strings may be formatted for output in the language used to develop your application. A recent article that describes this well is Programming Language Format String Vulnerabilities” by Hal Burch and Robert C. Seacord. printf style formatting strings are ripe for these types of errors.

    Special character values:

    “\\” Backslash related strings
    “Backslash\\Backslash”
    “\a” Alert (bell) related strings
    “Bell\aBell
    “\b” Backspace related strings
    “Backspace\bBackspace”
    “\f” Form feed related strings
    “Form Feed\fForm Feed”
    “\n” Newline related strings
    “Newline\nNewline”
    “\r” Carriage return related strings
    “Carriage Return\rCarriage Return”
    “\t” Tab related strings
    “Tab\tTab”
    “\v” Vertical tab related strings
    “Vertical Tab\vVertical Tab”

    Format value strings:

    “Decimal: %d” Signed decimal
    “Decimal: %i” Signed decimal
    “Octal: %o” Unsigned octal
    “Decimal: %u” Unsigned decimal
    “Hex: %x” Unsigned hex
    “Hex: %X” Unsigned hex
    “Floating: %.5f” Floating point
    “Exponential: %.5e” Exponential
    “Exponential: %.5E” Exponential
    “Unsigned Char: %c” Character (converted from integer value)
    “String: %s” String

     

    Web Login and Authentication – OpenID

    One of the challenges I have is keeping up with all of the developments and new technologies that are not the ones I use on a daily basis. I had seen references to OpenID but had not spent anytime researching it. Luckily, Scott Hanselman covered OpenID in a recent Hanselminutes. Scott describes OpenID and how it is used to allow someone to login into a web site and provide that website with selected information.

    I decided to play around with OpenID myself. First, I created an account on MyOpenID, a free OpenID server. When you create an account, you are assigned a URL that you can then use to login to sites that support OpenID. In my case, the URL is “http://mensming.myopenid.com”. I also created 2 personas – sets of information I can choose to reveal to a site. I created a minimal persona as the default and a fully populated persona which I named “full”.

    Once I had my account set up, I wanted to try it out. MyOpenID includes a directory of sites that support OpenID. I chose Stikis which is a web based sticky note site. I put my OpenID URL into the appropriate login box, mensming.myopenid.com, and clicked on the login button. I was redirected to the MyOpenID site where I was prompted for my password. After successfully logging in, I was presented with a screen informing me that stikis.com was requesting my nickname (required) and my email address (optional). I had the option to select a different persona and decide what to reveal. I also had the choice “Allow Forever”, “Allow Once” or “Deny”. Once I made my choice (“Allow Once”), I was redirected back to the site and was logged in.

    However, I really don’t want my ID to be this URL assigned to me by MyOpenID. I would really like to be able to use my own URL. There are 2 ways to do this. One is to install an OpenID server at your URL. (I really don’t want to do that…) The other is to add some items to the HTML header on the home page of the URL. I added the following to the HEAD section of the home page at meesqa.com.


    <link rel="openid.server" href="http://www.myopenid.com/server" />
    <link rel="openid.delegate" href="http://mensming.myopenid.com/" />
    <meta http-equiv="X-XRDS-Location"
       content="http://mensming.myopenid.com/xrds" />

    With this in place, I can now use meesqa.com as my OpenID. (Note: In the HEAD section of http://mensming.myopenid.com/, you only see the openid.server setting.)

    Why is this in a blog dedicated to software testing? I think it is important to understand how emerging technologies (which may or may not be accepted) work and become familiar with them before we need to test a product with them. If I were testing a site that used OpenID, I would make sure I verified:

  • OpenID URL that points to an OpenID provider
  • OpenID URL that uses the openid.delegate header
  •  
    As well as the various persona options and error conditions that may arise when communicating to a system outside of the one being tested.

     

    Call to Action: Hardware DEP Compatibility Testing

    I was listening to Security Now! Episode 78: DEP in Depth by Steve Gibson with Leo Laporte. In this particular episode, Steve describes hardware data execution prevention (DEP), how it works and why it is important. At one point he describes how some applications will not work when DEP is set to its most stringent mode, AlwaysOn.

    For anyone testing Windows applications, I suggest that you add compatibility with Hardware DEP in AlwaysOn mode to your test suite. Here is the gotcha: in Windows XP – you can’t configure AlwaysOn from the user interface. Fortunately, Microsoft provides a detailed explanation of DEP and how to configure it by modifying your boot.ini file in the knowledge base article 875352. (In Service Pack 2, you can configure DEP in the less stringent OptIn or OptOut modes.)

    Not all hardware is DEP capable. An easy way to find out is to download and run the small utility SecurAble from Steve’s site.

    TheServerSide.com: Countdown to DST 2007

    As I have posted before, the upcoming DST changes in the U.S. are approaching rapidly. I posted a set of useful links. Today, I came across the following article which repeats much of the same information:
    TheServerSide.com: Countdown to DST 2007

    What is nice about this article is it includes the source to a simple Java program you can use to test whether the DST calculations are working correctly on a particular machine. There is also source to a JUnit test to verify the date manipulation as well.

     

    Extraneous Document Text

    I have been looking at standardizing some document templates for various software artifacts. As I review these things, there are several items that annoy me. As I think about it, I think the difference comes to how the documents are viewed (and in particular whether they are handled in hard copy vs. looking at them online).

    Typical documents I see look like this:

  • Title Page
  • Revision History
  • Table of Contents
  • Bunch of standardized boilerplate text mixed with the content I am interested in
  • Many times, I need to page through 3-5 pages before I get to the information I am interested in.

    Title Page: In a printed document, this may or may not be a nice touch. However, generally, it does not add significant value over just a title, author and update date at the top of the first page of text. Whether to include a title page or not in the printed document is a question of your audience. In an electronic document, this is text and whitespace that must be skipped over to get to the “meat” of the document.

    Table of Contents: If I see another 3 page document with a table of contents, I think I will scream… My general rule for printed documents is that a table of contents is useful once the “meat” of the document is over 10 pages. In an electronic document (where I have full text search), I want the table of contents to be hyper linked enabled so I can use it as a navigation tool.

    Boilerplate Text or Background Info: In a printed document, it is a matter of preference. In general, I prefer background information on a project to be kept in a separate document that is referred to in the main document. However, this may make using the printed document unwieldy if the reader needs to shuffle between multiple documents. In an electronic document, I want the background information to be a link to the definitive source. It is easy for me to skip over and if it changes, there is only one location that needs to be updated.

    Boilerplate text is often seen in document templates. These are usually instructions for how to use the template or perhaps generic text that describes corporate policies or procedures. This text may be useful to a new employee or someone who is using the document for the first time. However, after that initial experience, this is text that most people will skip over and generally ends up wasting space. If instructions are needed or a reference to a procedure needs to be included, make it a reference (or link) to another document.

    Revision History: Some documents include a detailed table of every change made by every person ever in the history of the document. While this is valuable information, I consider this document meta-data rather than content of the document itself. I would prefer to see this data stored in the version control or content management system rather in the body of the document. That being said, it is nice to have some version identifier in the document (perhaps in the header or footer) to distinguish between versions.

    Test Values: String

    In a prior post, I described the test values that the JUnitDoclet utility uses for testing various data types. Now, I would like to describe the values I use for test string input. Note that some of these items do not make sense based on the type of testing that is being done (unit testing vs. gui testing).

    I am also excluding those values that I use to specifically test for cross-site scripting (xss) or sql injection vulnerabilities. That will be a subject for another post.

    Basic Tests:

    null  
    “” (empty string)
    ” “ (single space character)
    “a” (single alpha character)
    “abc123” (nominal alphanumeric)

    For more extensive text manipulation, I might use the following values:

    “lowercase” If case is going to be manipulated
    “UPPERCASE” If case is going to be manipulated
    “MiXedCase” If case is going to be manipulated
    ” Leading Spaces” See if leading whitespace impacts functionality
    “\tLeading Tab” See if leading whitespace impacts functionality
    “Trailing Spaces “ See if trailing whitespace impacts functionality
    “Trailing Tab\t” See if trailing whitespace impacts functionality
    “Embedded Spaces” See if “extra” whitespace impacts functionality
    “Embedded\t Tab” See if tab in middle of string impacts functionality

    Obviously, there is the possibility that length or format may matter:

    Shortest possible string
    If shortest possible string > 1, string with length 1 less than shortest possible string
    Longest possible string
    String with lenght 1 more than longest possible string
    Match format mask
    Not match format mask, first character
    Not match format mask, last character
    Not match format mask, middle character
    Not match format mask, strip out “separator” characters (-, /, etc.)

    HTML Character Entities

    < which may be encoded as "& lt;"
    > which may be encoded as “& gt;”
    & which may be encoded as “& amp;”
    ” which may be encoded as “& quot;”

    For a full listing of these encoding, see Character entity references in HTML 4.

    Low order, High order ascii characters

    Non-printable, low order. ASCII codes 0 – 32 (decimal)
    Printable. ASCII codes 32-126
    “Delete” ASCII code 127
    Extended ASCII (printable and non-printable). ASCII codes 128-255