ESA for Documentum Content Server and JRE

EMC published ESA-2015-016: EMC Documentum Content Server Security Update for Oracle Java Runtime Environment (JRE).  The vulnerabilities described here are the same as described in ESA-2015-017: EMC Documentum Foundation Services (DFS) Security Update for Oracle Java Runtime Environment (JRE) published last week.  Why they couldn’t cover all vulnerabilities — especial those all dealing with the JRE and having the same remedy — in one ESA, I don’t know.

DFS ESA for Java Vulnerabilities

EMC published ESA-2015-017: EMC Documentum Foundation Services (DFS) Security Update for Oracle Java Runtime Environment (JRE) recommending an upgrade to Java JRE 7u72 on the DFS server and client machines.  The vulnerabilities addressed by this update are described at Oracle CPU for October 2014.

I find this ESA puzzling.  First, the ESA suggests upgrading DFS to v7.2.  I can’t find DFS v7.2, can you?  (DFS v7.1 patch 13 was issued in Jan 2015.)  It is unclear whether DFS must be upgraded to the (mythical) v7.2 to work with Java JRE 7u72 or is simply upgrading the JRE sufficient to address the vulnerabilities.  Second, Java 7u75 is the latest Java version, why doesn’t the ESA recommend updating to Java 7u75?

Can anyone shed some light on this?

Note, the end of public updates for Java 7 is scheduled for April 2015.  At that point, I suspect EMC will provide ESAs or ETAs recommending upgrading to Java 8 and issuing the requisite patches for their products.

UPDATE: ESA-2015-016: EMC Documentum Content Server Security Update for Oracle Java Runtime Environment (JRE) covers essentially the same vulnerabilities for the Content Server platform.

Another Tech Advisory for Java and UCF

EMC just released ETA 177121: Documentum: UCF content transfer and file operations may experience operational issues for JRE versions 1.7.u45 / 1.7.u25.  There has been another change in the Java security baseline that affects the UCF. All WDK-based clients are affected.  The current JRE, 1.7u51, is not supported by Documentum WDK-based clients, and EMC recommends not to upgrade. EMC is working on certification of UCF applets for JRE 1.7u51.  In the meantime, the ETA provides a simple work around until certification is obtained. Follow the link to the ETA for more details.

If you are curious, here is the post from the last ETA concerning Java and the security baseline.

UCF – Java 1.7.u45 Conflict

EMC just released ETA: UCF content transfer and file operations may experience operational issues for JRE version 1.7.u45.  There has been a change in the Java security model that can cause problems with the UCF if client and server are not using the same version of the JRE you are using a JRE earlier than 1.7u25.  The bottom line is that client and server should be upgraded to JRE 1.7.u45, or all should remain at JRE 1.7.u25 or earlier.  All WDK-based clients are affected.  Follow the link (and discussion in the comments section) for more details.

DFC Code to Automatically Build Folder Paths

If there is one piece of code I have rewritten more times than the login routine, it is that which will create nested folders in the repository given a fully qualified path.  I have implemented this code in WDK, TBOs, SBOs, Captiva, jobs, and migration code.  For example, suppose you have a process that ingests news feeds and stores them according to wire service, year, month, and day.  Your storage structure in the Docbase might look like this:

  • /News/wire service/AP/2012/Jan/01
  • /News/wire service/AP/2012/Jan/02 …
  • /News/wire service/Reuters/2012/Feb/14 …

Get the idea?  Each service’s stories are stored in a unique folder according to the day they were recieved.

If an automated process is recieving, classifying, and storing these stories it would need to be able to create new folders based upon the date or wire service.  Usually this information is readily available from the process ingesting the content.  So, it would be nice to simply construct the desired storage path as a String, create the necessary elements of the path, and link the newly ingested content to the proper folder.  The code for the method dmCreateStoragePath(IDfSession session, String path) below does just that.

    public IDfFolder dmCreateStoragePath(IDfSession session, String path) throws Exception {
        IDfFolder folder = null;

        // first see if the folder already exists
        folder = (IDfFolder) session.getObjectByQualification("dm_folder where any r_folder_path='" + path + "'");

        // if not build it
        if (null == folder) {
            // split path into separate folders
            String[] dirs = path.split("/");

            // loop through path folders and build
            String dm_path = "";
            for (int i=0; i<dirs.length; i++) {

                if (dirs[i].length() > 0) {

                    // build up path
                    dm_path = dm_path + "/" + dirs[i];

                    // see if this path exists
                    IDfFolder testFolder = (IDfFolder) session.getObjectByQualification("dm_folder where any r_folder_path='" + dm_path + "'");
                    if (null == testFolder) {

                        // check if a cabinet need to be made
                        if (dm_path.equalsIgnoreCase("/" + dirs[i])) {
                            IDfFolder cab = (IDfFolder) session.newObject("dm_cabinet");
                            cab.setObjectName(dirs[i]);
                            cab.save();
                         // else make a folder
                         } else {
                             folder = (IDfFolder) session.newObject("dm_folder");
                             folder.setObjectName(dirs[i]);

                             // link it to parent
                             String parent_path = "";
                             for (int j=0; j < i; j++) {
                                if (dirs[j].length() > 0) {
                                    parent_path = parent_path + "/" + dirs[j];
                                }
                             }
                         folder.link(parent_path);
                         folder.save();
                        }
                    }
                 }
            }
        }
        return folder;
    }

To use this code in your ingestion program, you can simply do this:

  IDfSysObject newStory = (IDfSysObject) session.newObject("dm_document");
  // do some stuff with newStory
  IDfFolder newFolder = dmCreateStoragePath(session, "/News/wire service/Fox News/2012/May/07");
  newStory.link(newFolder.getObjectId());
  newStory.save();

Where the path, “/News/wire service/Fox News/2012/May/07” is build dynamically from metadata. Any or none of the components of this path may exist. The dmCreateStoragePath() method builds what is necessary. Note that this code does not make any accomodation for ACLs placed on the created cabinet or folders, but could easily be modified to do so.

Updating Java on the Documentum Platform

I have always been reluctant to upgrade the version of Java that was shipped with the Content Server and the Java Method Server for fear of breaking something in the platform stack. In April of last year, my fears were justified when EMC Documentum advised NOT to upgrade to Java 1.6.0_24 until they had had a chance to certify the platform on the update (see my previous post about this announcement and EDN notice) .

This past month, my Content Servers showed up as vulnerable on a routine security scan by my IT department because of the antiquated version of Java they were running. After doing some research, I discovered the EMC Documentum procedure for upgrading Content Server 6.5, 6.6, and 6.7 to Java 1.6.0_24, as promised in their original advisory. Though this update isn’t the latest version of Java (Who can keep up?), it does squash some of the bugs my security folks were concerned about.

The information you need to do the Java upgrade can be found in the Content Server 6.6/6.7/6.7 SP1 download site. The files are named jdk6upgrade_windows.zip, and JdkUpgradeReadme.txt.

Here is an EMC Solution Note with a cumulative list of known issues and workarounds for Java 1.6.0_x.

Updating the Java running your WDK server and/or client workstations seems to be a different matter. As feared, Java 1.6.0_24 did in fact, break the WDK . If you are updating Java on your WDK server, or users’ desktops, make sure you update to 1.6.0_27 (or later).

As of this writing, the current version of Java is 1.6.0_31. I have not seen any EMC Documentum notices indicating that there are problems with any version of Java after 1.6.0_27. Does this mean we can update to the latest version? If so, why is there no scripted update?

Java JRE 1.6 update 24 – Beware!

If you haven’t heard already: EMC has recommended not installing the Java 1.6 update 24 patch recently distributed by Oracle on any computer running Documentum products due to incompatibilities. Update 24 addresses legacy security issues in the JRE, but has introduced some incompatibilities with the WDK, and other products in the Documentum stack.  EMC is working to update their code and expects to release patches in June.

If you have already installed Update 24 on your workstation and can’t — or don’t want to — back it out, you can try this work-around to minimize the problems with Webtop.

  1. Open the Java Control Panel
  2. Click the Advanced Tab
  3. Open the Java Plug-in tree item
  4. Uncheck the “Enable the next-generation Java Plug-in”
  5. Click OK
  6. Close the browser
  7. Restart the browser

Here is the EMC announcement: https://community.emc.com/docs/DOC-10357

%d bloggers like this: