We're still pretty far away from "good to go" :-(
For starters, I think that this is a good idea and I feel that it
will add value. Before we can approve this, we need to do a proper
legal review. That may be time consuming. Further, if we're going to
put this into the packages, then we need to get the Webmaster team
to take over responsibility for the server to ensure robustness.
Here's what we need to do.
1) Get buy-in from the Architecture and Planning Councils. I need a
"yes, we'll use this" consensus. Conversely, if we get a "no, we
won't use this" sort of response, then we're done. We have an AC
call on Thursday; let's add this to the agenda. You'll have to
contact the PC via the Technology project's representative (Chris A)
2) If we get AC/PC buy-in, Mike and I will discuss this with Janet
to ensure that we're in good shape legally-speaking. I'll need a
very specific workflow and description of exactly what we're going
to capture for this conversation.
3) If we determine that this is legally sound, we'll roll this into
the packages using the existing virtual server configuration with a
commitment up to M5.
4) If after M5 is released we can demonstrate that that the
functionality has actually been useful, we'll get Webmaster to take
over responsibility for the server.
To be frank, if we can show that the Platform, JDT, and Web Tools
teams have taken real value out of this, then we're in really good
shape.
Does this make sense?
Wayne
On 12/08/14 02:48 PM, Marcel Bruch
wrote:
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
_______________________________________________
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
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
 |
