Community
Participate
Working Groups
Build Identifier: If more than one thread calls Base64.decode at the same time, the wrong value can be returned to the user. It's possible that this is problem might be the cause for some defects related to our product: https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/171495 https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/167948 Reproducible: Sometimes Steps to Reproduce: The problem can be reproduced by looking at the code. Imagine two threads calling Base64.decode() at the same time. Both threads execute until the call to init(), but because init() is synchronized only one will enter. Now, one thread is executing in init() and the other is waiting to enter the synchronized method. After the first thread finishes with init() it proceeds through the rest of the method calling decode() at various places. If the second thread starts executing init() while decode() is executing in the first thread, then two threads will be accessing a shared field without synchronization. That can lead to corruption in the decoding of the string because the field used in the decode method might not be initialized while it's used.
Seems decodeTable should be final and initialized in a static initializer.
Oleg, do you know the history of this version of the org.eclipse.equinox.internal.security.storage.Base64 class. We have many copies of a class called Base64 in Eclipse, but this version looks to be a completely different implementation. The other implementations are: org.eclipse.osgi.internal.signedcontent.Base64 org.eclipse.core.internal.preferences.Base64 org.eclipse.ui.internal.preferences.Base64 These versions do not have this issue. I am wondering if we should just copy one of these versions of Base64 or try to fix this version.
(In reply to comment #2) > The other implementations are: > > org.eclipse.osgi.internal.signedcontent.Base64 > org.eclipse.core.internal.preferences.Base64 > org.eclipse.ui.internal.preferences.Base64 > None of those are APIs. At the time we discussed making Base64 processing an API, but that was buried in usual questions on where it is going to reside, how we make other classes to switch to it, etc. Due to this I only briefly looked into other classes. I am not sure if the processing they provide is identical. Unless the changes to secure storage's Base64 are done in a way the preserves it "input -> output" behavior, it will break the ability to decrypt currently stored data.
Created attachment 201337 [details] proposed fix (In reply to comment #3) > None of those are APIs. At the time we discussed making Base64 processing an > API, but that was buried in usual questions on where it is going to reside, how > we make other classes to switch to it, etc. > > Due to this I only briefly looked into other classes. I am not sure if the > processing they provide is identical. Unless the changes to secure storage's > Base64 are done in a way the preserves it "input -> output" behavior, it will > break the ability to decrypt currently stored data. Do to your concerns the safest fix is to fix this version. Here is my proposed fix.
(In reply to comment #4) > Created attachment 201337 [details] > proposed fix +1, looks good.
Released to master with: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=0e82ed0a2b8b648b26d2ab5a40e2acccda1d2142
I forgot to update the version. That is done with commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=9dfa830ee7dcc2978dc6a34bcd801a1577cc4eab
