It's all about the answers!

Ask a question

RTC - How to decrypt enumeration literals that are encrypted in the database?


Ben Newell (3224) | asked Mar 25 '13, 11:45 a.m.
We're building external reports based on data stored in our RTC database. We are querying the database directly. For some reason, RTC encrypts these enumeration literals in the database. There doesn't appear to be an option in RTC/CCM to specify whether certain fields are encrypted or not (these are not sensitive fields, why can't we specify whether to have them encrypted or not?). It appears my only option is to decrypt these manually. What is the encryption used? Is there a default key? If not, where can I find the key and was it set during the initial configuration of the server? Any help would be appreciated.

Database:
SQL Server 2008
RTC Version: 4.0.1

Encrypted vs. Plain Text RTC Fields

Query to get specified encrypted field:

USE RTC

SELECT
    I.ITEM_VALUE
FROM
    REPOSITORY.ITEM_STATES AS I



Thanks,

Accepted answer


permanent link
Sandy Grewal (1.6k1223) | answered Mar 25 '13, 11:56 a.m.
JAZZ DEVELOPER
@ben the Item_value field is a gzipped blob, if you unzip it you can get the xml.
Ben Newell selected this answer as the correct answer

Comments
Ben Newell commented Mar 25 '13, 2:16 p.m. | edited Mar 25 '13, 2:31 p.m.

Thanks for the response. So these enum literals ARE stored in this field/column (  REPOSITORY.ITEM_STATES.ITEM_VALUE)? And the value of the field is a gzipped blob that contains XML that specifies what enum has been chosen?

 I was able to get part of the XML extracted by putting the binary data into a hex editor, saving it as a .gz file and extracting the data from there. Unfortunately, it only appears to be part of the XML, though. I guess from here it would be a different question but I'll ask anyways. Should ITEM_VALUE contain the entirety of the XML or is it merely one part of something larger?


Sandy Grewal commented Mar 25 '13, 3:55 p.m.
JAZZ DEVELOPER

@ben from my knowledge it is XML.

Ralph is quite correct in suggesting not to touch the DB directly especially any updates.
But if you want to really read from the column you could try something like below.
ResultSet rs = null;
 PreparedStatement ps = null;
InputStream inputStream = null, rawStream = null;
ByteArrayOutputStream out = null;
try {
ps = conn.prepareStatement(query);
rs = ps.executeQuery();
int start =0;
boolean hasNext = rs.next();
while (hasNext ) {
rawStream = rs.getBinaryStream(column);
inputStream = new GZIPInputStream(rawStream, 8192);
out = new ByteArrayOutputStream(2048);
byte[] bytes = new byte[1024];
int size = -1;
while ((size = inputStream.read(bytes)) > 0) {
out.write(bytes, 0, size);
}
fw.flush();
start++;
hasNext = rs.next();
out.close();
inputStream.close();
rawStream.close();
}

One other answer



permanent link
Ralph Schoon (63.1k33646) | answered Mar 25 '13, 11:59 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You should not work on DB level, especially not write to it. You should use the API's to access the data. If you work on the DB level, you will be potentially hit by schema changes. And you will probably run into many places where plain SQL does not give you the data you want, or the data is stored in blobs and zipped.

Comments
Ben Newell commented Mar 25 '13, 12:40 p.m.

Thanks for the warning, but we have quite a few reports that pull directly from the database and they work perfectly for our use. We've even updated from v3 to v4 and the queries/reports still worked fine. I guess we got lucky. We may try the API route if we do, indeed, start running into issues though. So far it's been fine.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.