Bug 745841 (EDG-54)

Summary:	etag calculation algorithm allows collision, when two updates are performed too quickly after each other
Product:	[JBoss] JBoss Data Grid 5	Reporter:	Michal Linhard <mlinhard>
Component:	Infinispan	Assignee:	Default User <jbpapp-maint>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	galder.zamarreno, mlinhard, nobody
Target Milestone:	---
Target Release:	EAP 5.1.0 EDG TP
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/EDG-54
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-01-12 13:14:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Michal Linhard 2011-01-04 10:41:52 UTC

project_key: EDG

affects infinispan 4.2.0.FINAL
due to a bug in my testsuite, I discovered this only now, even though I wrote a testcases for ETags sooner:

calculation of etag depends only on content type, last modified time and data length:
def calcETAG(entry: MIMECacheEntry) = new EntityTag(entry.contentType + entry.lastModified + entry.data.length)

which means that when updates are performed in same second and content type and length stays the same, the collision occurs - ETag stays the same although the values are not identical.

Comment 1 Michal Linhard 2011-01-04 10:54:13 UTC

TestCase: testETagChanges() in
https://anonsvn.jboss.org/repos/jbossas/branches/JBPAPP_5_1_datagrid/testsuite/src/main/org/jboss/test/cluster/datagrid/test/RESTClientTestCase.java

Comment 2 Galder Zamarreño 2011-01-04 11:34:46 UTC

Link: Added: This issue depends ISPN-858

Comment 3 Galder Zamarreño 2011-01-04 15:05:38 UTC

The modifications made as part of this JIRA resulted in the loss of precision. I'm going back to that JIRA to try to understand what the original issue was.

Michal, do you have the code for the test case of that original JIRA?

Comment 4 Galder Zamarreño 2011-01-04 15:05:38 UTC

Link: Added: This issue is related to JBPAPP-5262

Comment 5 Galder Zamarreño 2011-01-04 15:44:36 UTC

Right, I think I've found the original test, it's testIfUnmodifiedSince in that same file.

Comment 6 Michal Linhard 2011-01-04 16:07:07 UTC

the change in MIMECacheEntry that was part of the JBPAPP-5262:

    public MIMECacheEntry(String contentType, byte[] data) {
        this.contentType = contentType;
        this.data = data;
+++     lastModified = System.currentTimeMillis() / 1000 * 1000;
---        lastModified = System.currentTimeMillis();
    }

only made this more probable (the updates have to be more than a second apart to not collide)
without JBPAPP-5262 it would be one millisecond, but wouldn't that be still a problem ?

Comment 7 Galder Zamarreño 2011-01-04 16:52:53 UTC

Indeed it'd be a problem cos it'd be considered a weak validator as per http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3 which indicates how ETags are compared. It appears that a version ala Memcached/HotRod is needed in order to identify individual changes, regardless of the time difference.