| For source code: I think it’s possible to identify source code by looking for many „import" statements in the message.
In general, anonymization on the client side is what I intend to do with stackframes (types and methods names other than org.eclipse)
While looking through the data, I submitted I noticed that almost half of the reported errors do not have an error code. pluginId +pluginVersion + error code + stacktrace, however, are a great vehicle to spot issues without ever looking into the messages - as long as we have a stack trace.
If not this gets much more complicated. However, this is something I can figure out over time.
Wayne, would we be good to go if I check the messages for words like „import“ to prevent source code being sent?
Marcel
This is where we ran into trouble with the UDC.
In our implementation, we decided to not obfuscate at the client.
Instead, we transferred the data securely (SSL) and stored it in its
raw accessible only to select EF staff. We used obfuscation to
publish our results.
With the UDC we went to great lengths to avoid leaking the names of
commands, views, editors, etc. that might divulge information about
an organization. Disclosing actual source code is a non-starter.
Wayne
On 12/08/14 08:18 AM, Marcel Bruch
wrote:
But I wonder whether making the error logs accessible
as they are today is okay for EMO. See [1] for a
collection of stacktraces I sent in the past 2 days.
AFAICT, there is at least two log statements in JDT that
log the source code of a whole file in the case of an
error. Other statements contain names of files and ids
(which cannot be filtered easily).
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev |
