Are changes coming?

On last week something weird had happened – a couple of researches disclosed information about vulnerabilities in Documentum xPression and Documentum WDK applications:

and these disclosures are qualitatively different from what EMC was publishing previosely – these disclosures had been coordinated. Let’s explain this point. When Documentum was under EMC wing EMC was never published correct/true information about security flaws: they were always underestimating security impact and were never noticing that exploit/PoC were available in the wild, and such behaviour, obviously, had negative impact on customers: customers see that vulnerability impact is medium and prefer do not install security fixes – that is a kind of expected behaviour, because in most cases Documentum updates tend to break a lot of things which previosely work smoothly. But last disclosures are different – they are full and everybody can independently estimate a security impact, so I do see positive changes for Documentum customers after acquisition. On the other hand it is not clear whether acquisition took effect on talented team, because my communication with both EMC and OpenText was not so good – please check my story below.

Long time ago (I believe it was 2012 or 2013) I filed a plenty (more than 20) of security reports related to Webtop and Content Server via EMC customer support channel, they confirmed the existence of vulnerabilities and after a while I was notified that my vulnerabilities were remediated, but there were a couple of things which shocked me:

  • EMC refused to disclose those vulnerabilities, that time I considered such decision as scorn of customers
  • some of vulnerabilities weren’t actually remediated – EMC didn’t even try to find a root cause of vulnerability
  • some of fixes were breaking a lot of thing – check out D2 story for example

So, I realised that EMC customer support channel didn’t work and opened my cool blog. During next three years I was contacted by EMC reps twicely:

  • First time that was Jeron Van Rotterdam (CTO) – he asked to share all my finding for free, though on that time EMC knew about 15 unfixed vulnerabilities in Documentum and I was unable to understand why they requested more, by the way I let him know that if he wanted to collaborate on this topic ECD had to provide contact(s) of qualified SW engineer(s) on EMC side
  • Second time that was John O’Melia (SVP) – he had attempted to hire me, and I that time I failed to understand what I was supposed to do there – it was clear they failed to find competent contact and I had no intention of teaching their talented team.

Dialog with OpenText had more promising beginning: 7 months ago I have contacted Muhi S. Majzoub (CTO) regarding security issues in Documentum (like I discovered more than 30 security flaws and I would like to help) and on the same day (technically that was next morning in Australia) I received following from David Goldberg (VP):

Hi Andrey,

Thanks for accepting my LinkedIn request. Mark Barrenechea forwarded the note you sent him to the head of Engineering at OpenText who asked me to reach out to you. We are interested in better understanding the issues you mentioned in your message. Is there more you can tell me?

We got a shot conversation (actually, I didn’t provide information about all security vulnerabilities – it would take a lot my time, I just picked up two most important (CVE-2017-5585 and CVE-2017-5586), in my opinion that was enough to evaluate whether talented team is capable to fix security flaws or not), and the result of that conversation was (un)expected:

Thank you, Andrey

I will pass this on to our Engineering team and we will consider what follow-up is required.

And as you can see, CEO, two VPs and 2000 talented persons are not enough to replace two vulnerable jar files.

As regards to last vulnerability disclosures: the second part of CVE-2017-14524 looks very similar to I perceive the world: response.sendRedirect(String location) and it is XSRF, but the first part is not a XSRF but XSS – if I understood properly the following piece of code in webtop/help/en/default.js is vulnerable:

if (document.location.search != null && document.location.search != "")
{
if (document.location.search.substring(0,9) == "?startat=")
{
startPage = document.location.search.substring(9,document.location.search.length);
if(startPage.indexOf("://") != -1 || startPage.indexOf("\\") != -1 || startPage.toLowerCase().indexOf("javascript:") != -1)
{
startPage = null;
}
}
}

so I have no idea why two different security vulnerabilities were combined into single CVE, moreover I doubt that XSS was actually remediated – both disclosed test case and description (“open redirect”) are confusing:

So, I think it is clear that OpenText management seems to be much better than EMC was, but, unfortunately, talented team remains the same.

Advertisements

Documentum innovations

A week ago OpenText have announced another one Documentum roadmap (here I recalled following quote:

“I’ve been watching this process with OpenText for more than a decade, and I think, in 2009, I called them ‘The Roadmap Company,'” said Tony Byrne, founder of Real Story Group, a research and advisory firm in Olney, Md. “Every time [OpenText] acquires a company, they always have this story around innovation and synergy and a roadmap. It’s a very nice story for the customer and perhaps OpenText believes it, but it very rarely executes on it.”

), this roadmap contains more “technical details” than the previous one, so we may discuss it more thoroughly.

Brava! & Blazon


Actually, here I didn’t understand what innovations they were talking about, because both innovations are already available:

More probably they were talking about new challenges for Documentum customers: in D7 EMC have switched CTS primary rendering engine from Adlib to Aspose, now it seems that they are going to switch from Aspose to Blazeon.

S3, Hybrid services and Independent JMS


And again, I did find nothing innovative there – all these three innovations were part of “EMC’s vision” in 2016:

Moreover, all these three points seem to be doubful:

Application access control in D2

If my memory serves me right similar feature was implemented in Documentum xCP 1.x ๐Ÿ™‚

Improved content contribution in D2

Very innovative, if forget that the similar behaviour was present in, at least, webtop 5.3 ๐Ÿ™‚

Expand with homophones

From business perspective this slide looks funny, the problem is that Atenolol and Timolol are two different drugs, so this slide literally means following: in version 16.4 our search engine will return irrelevant results ๐Ÿ™‚ From technical perspective, again, I do see nothing innovative here: the similar behaviour could be implemented via com.documentum.fc.client.search.filter.IDfQueryFilter.

Why you should stay clear of REST. Part II

Actually, as a continuation of previous blogpost I wanted to write about DDD and my own experience with DFS, CMIS and REST, but today I have found another gem on LinkedIn: Performance Anti-Pattern For RESTful API – batch updating (saved copy), actually that blogpost hides package names:

but all we do know what is hidden there:

As far as I know, batch updates were introduced in 7.2 and they are dead slow ๐Ÿ™‚

Another LinkedIn gem: Potential Permanent Generation Leakage In Your JVM

Why you should stay clear of REST

Once again I get inspired by to write this blogpost by Alvaro de Andres Documentum 16.3 delayed until Feb 2018 blogpost – there is some “interesting discussion” about REST where you can find following opinion from another member of talented team:

Is DFS a personal target for your projects? Baseline REST is a mature offering and it has active Engineering working on it. The planet seems to be focused on a RESTful interface and the DCTM platform is meeting that focus with a set of platform APIs. As Iโ€™m sure you are aware Captiva, xCP and D2 can be access through REST interfaces.

Actually, it is not clear what Tomas meant under the word “REST” because my observations about REST are following:

  • when most people talk about REST they typically mean JSON, which is obviously wrong: it is true that in the most cases (especially when REST client is a web-browser) REST is used together with JSON, but if we want to get faster data processing or put validation rules on data nothing prevents us from using XML or protocol buffers. Moreover the idea to use JSON in most cases sounds ridiculous: we spend a lot of time on designing data structures, but once we chose to use JSON as serialisation technique we throw all our efforts out of window.
  • Documentum’s REST API is actually not REST-compliant, so when talking about Documentum under the REST we should mean “something that looks like REST”, so, yes, REST seems to be a standard of providing interoperability between computer systems on the Internet,
    but how it relates to Documentum?

Let’s discuss the second point: why is Documentum REST not REST-compliant? The base idea is following: when we work with our data through REST API we consider two types of resources: elements and collections of elements, which could be queried/modified using GET, PUT, POST, PATCH and DELETE methods, the behaviour of these methods is following:

Method Resource type Contract
Collection Element
GET List the URIs and perhaps other details of the collection’s members Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type readonly
PUT Replace the entire collection with another collection Replace the addressed member of the collection, or if it does not exist, create it idempotent
PATCH Not generally used Update the addressed member of the collection
POST Create a new entry in the collection. The new entry’s URI is assigned automatically and is usually returned by the operation Not generally used. Treat the addressed member as a collection in its own right and create a new entry within it
DELETE Delete the entire collection Delete the addressed member of the collection idempotent

Below are some explanations of the table provided above:

  • Documentum REST API should not allow to do something like:
    GET /dctm-rest/repositories/DOCBASE?dql=delete%20dm_user%20objects
    

    because GET method is readonly

  • PUT method against element must completely replace element’s data, i.e. if you are doing something like:
    PUT /dctm-rest/repositories/REPO/DOCBASE/dm_user/11bc614180000522
    Content-Type: application/vnd.emc.documentum+json;charset=UTF-8  
    
    properties: {
      "user_address": "user@domain.tld"
    }
    

    the request above should set user_address to user@domain.tld and clean other properties, if your objective is to update user’s email you should do something like:

    PATCH /dctm-rest/repositories/REPO/DOCBASE/dm_user/11bc614180000522
    Content-Type: application/vnd.emc.documentum+json;charset=UTF-8  
    
    properties: {
      "user_address": "user@domain.tld"
    }
    
  • example of POST method usage against element should look like:
    POST /dctm-rest/repositories/REPO/DOCBASE/dm_workflow/4dbc6141801aa1e1/attachments
    Content-Type: application/vnd.emc.documentum+json;charset=UTF-8  
    
    properties: {
      "object_name": "new attachment"
    }
    
    

Now, how it does look from Documentum perspective:

  • updating object:
    POST http://localhost:8080/acme-rest/repositories/REPO/alias-sets/6600000580000515 HTTP/1.1  
    Authorization: Basic ZG1hZG1pbjpwYXNzd29yZA==  
    Accept: application/vnd.emc.documentum+json  
    Content-Type: application/vnd.emc.documentum+json  
      
    {  
      "properties":{  
        "alias_name":["RestASX ", "Everyone_Write"],  
        "alias_value":["/Resources/Registry/Presets", "dce_world_write"],  
        "alias_category":[5, 6],  
        "alias_usr_category":[1, 1],  
        "alias_description":["A test alias set", "A second alias set"]  
      }  
    } 
    
    HTTP/1.1 200 OK  
    Content-Type: application/vnd.emc.documentum+json;charset=UTF-8  
    Content-Length: 725     
      
    {  
      "type":"dm_alias_set",  
      "definition":"http://localhost:8080/acme-rest/repositories/REPO/types/dm_alias_set",    
      "properties":{  
        "owner_name":"dmadmin",  
        "object_name":"TestASX",  
        "object_description":"A test alias set",  
        "alias_name":["RestASX ", "Everyone_Write"],  
        "alias_value":["/Resources/Registry/Presets", "dce_world_write"],  
        "alias_category":[5, 6],  
        "alias_usr_category":[1, 1],  
        "alias_description":["A test alias set", "A second alias set"]  
        "i_is_replica":false,  
        "i_vstamp":0,  
        "r_object_id":"6600000580000515"  
      },  
      "links":[  
        {"rel":"self","href":"http://localhost:8080/acme-rest/repositories/REPO/alias-sets/6600000580000515"},    
        {"rel":"author","href":"http://localhost:8080/acme-rest/repositories/REPO/users/dmadmin"}    
      ]  
    }  
    

    and inconsistencies are:

    • improper usage of POST method
    • PATCH method is not implemented at all
    • if under POST they actually mean PUT they should clean values of owner_name, object_name and object_description attributes – I believe talented team actually uses POST as a replacement of PATCH, though PATCH method was introduced in 2010 (7 years ago)
  • dealing with workflow tasks:
    PUT /rest-app-name/processes/process-system-name/process-id/task-name/task-id/status
    Content-Type: application/vnd.emc.documentum+json  
    
    {
      "acquire":{}
    }
    

    that is a total mess, the correct implementation should be:

    PATCH /rest-app-name/processes/process-system-name/process-id/task-name/task-id
    Content-Type: application/vnd.emc.documentum+json  
    
    properties: {
      "r_runtime_state": 1
    }
    

As you can see REST implementation in Documentum is actually not REST-compliant, so, I have no idea what talented team was doing last 8 years. On the other hand it is not a big issue in comparison with the next one. At current moment ECD/OT provides following options to work with Content Server:

and the problem is that all those options do not provide you an out of the box robust integration with Documentum: while the planet seems to be focused on ORM, DDD and scaffolding, Documentum developers write tons of boilerplate code.

Hardware company mantra. Part III

When I was writing the previous blogpost I had a feeling that I was missing to write something important (i.e. due to experience I suppose that some things are obvious, but readers may not even know such things), so let’s start from the “beginning”.

Below is a history of names of EMC Documentum division:

What was the reason to rename CMA division in 2010? Well, until 2009 EMC was offering only two ECM solutions:

  • Documentum Webtop and it’s derivatives
  • Documentum Desktop

Moreover, somewhere until 2007 EMC was considered as leader of ECM market, take a look at Gartner MQ for ECM in 2006:

Unfortunately (unfortunately for EMC, but competition is always a good for end-users) the release of MS SharePoint 2007 has changed a lot on ECM market – below is Gartner MQ for ECM in 2007:

and in 2009:

So, EMC was forced to compete with new ECM players and their strategy in 2009 was the following:

  • Improve content management discipline, i.e.:
    • add Web 2.0 and Social Networking capabilities (CenterStage – Webtop replacement and MS SharePoint competitor)
    • improve Desktop integration (MDD, MDO, FSS, DCO)
  • Introduce new discipline – Transactional Content Management (a.k.a Case Management with TaskSpace as a flagman product)

You can find some Momentum 2009 “materials” here: Momentum 2009 โ€“ EMCโ€™s vision. Also it is worth to note that “configuration over coding” and “lower TCO” slogans have first appeared in 2009 too (it seems that somebody is little behind a schedule):

So, the renaming in 2010 was required to demonstrate both customers and competitors that EMC was doing much more than just content management. However, somewhen in 2011 EMC realised (for me it was always clear) that CenterStage didn’t take off, but they already wasted a lot of time on it (for example first rumours about D7 have appeared in 2009, but D7 was released in 2012, though from my perspective there is no difference between D6.5 and D7, moreover, I have no idea why they decided to create new product instead of evolving WDK – adding Web 2.0 capabilities into WDK is not a big deal), and in 2012 EMC has started reselling C6 D2 and in 2013 EMC announced a new UI for D2 client (the original UI was based on ActiveX). Interesting thing here is a fact that CenterStage, D2 and xCP2 UIs were designed by the same person:

Well, I think it is clear that during last 8 years talented team was trying to do their best to kill webtop, but it is still alive. Why?

Hardware company mantra. Part II

I thought a lot how to write continuation for previous blogpost, because I have my own OpenText experience and I’m looking forward to share it, on the other hand OpenText has recently shared their Documentum “roadmap“, so I want to share my thought on it as well. Today Alvaro de Andres has inspired me to write a blogpost about second topic, i.e. roadmap. Actually, I would completely ignore this blogpost if it was written by a sales person, who was hired a couple of months ago and has a KPI to sale as much D2 licences as possible, but statements like “migrate to D2 because you can configure it” sound ridiculous if you are an architect with 20 years of experience. Well, let’s discuss this topic more thoroughly, and let’s begin not with Documentum ๐Ÿ™‚

Simple question: what is the worst bugtracking software ever?

I do know it is not correct to use universal quantifiers, because my experience is limited only by four bugtracking systems:

but without doubts I can say that in my opinion Atlassian JIRA is the worst bugtracking software ever – it is so uncomfortable that every opening of JIRA dashboard causes a vomiting attack. Simple case: imagine that I need to create an issue in my bugtracking system, what steps I had to perform in order to do this? There is nothing special: I need to login into bugtracking system, open special page, provide short/full description, steps to reproduce, information about environment and versions, attach log files and submit an issue. Now how it looks in JIRA:

What is the hell? First of all, Atlassian guys, who think that modal window is extremely convenient, must to commit a suicide as soon as possible, at second, JIRA offers to fill a lot of irrelevant information but misses the important thing – adding attachments. Now how the same functionality looks in another bugtracking system:

It is awesome! Another case: every evening I want to review all recently submitted issues in order to check that those issues has been properly classified and assigned, JIRA search functionality:

the same in YouTrack – after JIRA it is like a big gulp of clean air:

Well, why is there abysmal gap in “user” experience between YouTrack and JIRA? The answer is pretty simple: YouTrack is a specialized software, which was designed to support development activities, JIRA is a software which allows you to setup/configure processes which look like trouble ticketing, i.e. you can use JIRA both as bugtracking and ITSM system, but in both cases it’s functionality lacks some crucial points, for example, in case of ITMS trouble ticketingincident management is not the only discipline, there are also problem management and configuration management – take a look at this marvel: JIRA as CMDB (actually, there is a third-party CMDB module for JIRA, but it’s existence just proves that JIRA lack some functionality). And the real question is: if I want to support some processes in enterprise, what is the best option: buy specialized software or use a single system, which is definitely not ideal for particular processes but, it general, covers about 80% of required functionality?

Now let’s return to Documentum. Why did I provide a user experience comparison between JIRA and YouTrack? Because it perfectly fits to the following statement from the original blogpost:

These days, the goal is more likely to be user acceptance, or better put โ€“ user adoption โ€“ making users happy and productive. The business side now typically drives decisions about which products and solutions will be implemented, and this makes total sense: Users must derive a business benefit from any implementation, otherwise, why implement? So the focus now is more on User Experience in terms of ease of adoption (including level of training needed), ease of use, speed of use โ€“ essentially, does the solution drive productivity or hinder it?

Hey, talented team, why are you still on JIRA if YouTrack provides better user experience? YouTrack also reduces TCO because it is cheaper – compare: YouTrack Standalone License and JIRA, hosted on your server. And, moreover, it is obvious that your users fail to adopt JIRA:

How was it possible that webtop CR became a part of D2 release? There are only two options:

But in both cases I do think OpenText must immediately migrate to YouTrack, otherwise the statement about TCO and user experience seems to be inconsistent – you suggest customers to migrate to another software due to certain reasons, but fail to do the same for your organization. And more vital question: if I think that webtop does not fit my needs well, why do I need to migrate to D2 and stay with OpenText? Why do not prefer another ECM vendor? If you think that your ECM processes are so simple that you are able to “transparently” switch between Webtop and D2, I swear: for you it won’t be a challenge to change ECM vendor. Moreover, if we start comparing ECM vendors using TCO and user experience metrics Documentum will demonstrate the worst results. My personal suggestion: never ever try to calculate money in someone else’s wallet – TCO is just a last resort when you are trying to compare competing products – if these products do not compete you statements looks poor, during long period of time Microsoft was trying to do the same and as the result we have a MSSQL running on Linux servers.

Now we are ready to talk about Documentum roadmap.

Frankly speaking, I didn’t expect much from that webinar due to following consideration: the “roadmap” term assumes that you clearly understand what is your current location and where is your final destination, and roadmap just defines a set of steps (milestones) you need to perform to reach your final destination, and, if you think that 30 minutes is enough to present “Documentum roadmap” you are bloody idiot – even a couple of days is not enough to do that, moreover, 90 days are not enough to think the current situation through and define a final destination and milestones, so, I was expecting that OpenText reps would use some populist slogans like: we are going to improve support, documentation, security, stability, integration capabilities, etc… – sounds poor from technical perspective, but it is exactly what Documentum customers were expecting, but even these low expectations didn’t come to true – all what we got was: we have acquired a 25-years old building and what we are going to do is change it’s signboard (change version numbers) and paint a facade (change D2 UI – actually, this analogy seems not to be perfect because D2 is just an outbuilding which has been constructed using dirt and cane, but on the other hand OpenText reps do think that D2 is our future, so, this analogy is correct). And when you are suggesting customers to migrate from Webtop to D2 you are actually suggesting to move from 25-years old building into an outbuilding – it is ridiculous.