|
Due to the underwhelming response to this thread, I'm proposing I push this defect to post 1.0. Anyone disagree with doing that? FWIW, I'd love to get this fixed, but I do need help in deciding how.
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 11/09/07 3:41 PM >>>
I've made my way back to https://bugs.eclipse.org/bugs/show_bug.cgi?id=196224 which seeks to make attributes and metadata holding secrets have their backing data objects be mutable.
Right now all attribute and metadata values are backed by the Java types in the last column of this table http://download.eclipse.org/technology/higgins/downloads/idas.api/lastNightlyBuild/javadoc/org/eclipse/higgins/idas/api/ITypedValue.html#getData() (Further, when one calls getCanonical() or getLexical() a String is returned.)
Of these underlying data types, only ByteBuffer and Date have mutators. Any attribute or matadata value could potentially be seen as holding secret or sensitive data.
Deciding how to address the defect begs two questions:
1) How do we represent all these data types in ways that are mutable?
2) Who is responsible to overwrite the sensitive data? What is the contract?
On #1, there are some data types that are easy to find mutable replacements for, like String could become StringBuffer. Others aren't so easy (like BigInteger). If the solution is to swap out these datatypes, it starts to feel like the solution would be to back everything with a StringBuffer. This means that CP writers and consuming applications would have to do their own conversions when the data exists or is needed as a more native type.
Also, anything we do like this will cause existing implementations which call getLexical, getCanonical, and getData to be re-written
On #2, I suppose we could tell CP writers to put code in their ITypedValue implementations that would clear the data when the destructor is called, and we could also introduce a new method called clear() which a consumer could call to ensure the data has been cleared.
Anyone else have ideas? Mike once suggested a subclass of IAttribute called ISecretAttribute. I thought that sounded good at the time, but I'm not sure what it does. First, the solution needs to apply to metadata as well as attributes, and also the data is held at the ITypedValue level, so I'm not sure if we'd need a whole new hierarchy of ISecret* classes or what.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
|
