Re: [cross-project-issues-dev] Error reporter and third-party code
Stack frames should not be considered sensitive just because they are from a non-OSS code base. Users post stack traces with commercial code references in forums all the time. Just because they can doesn't imply the are allowed to. There are all sorts of liability questions in here which I can understand as a reason to hide those. I think there is no other option. For most commercial code, the user can not simply allow disclosing such information but a vendor would have to approve. As long as we make it an explicit user choice whether convey this information to eclipse.org, I don't see how it's any different from user making an explicit choice to convey this information to say stackoverflow. The burden is on the user to comply with whatever policy or license obligations might bind them. How about this system: 1. The top-level package names are extracted from the stack trace. 2. The list is checked against an authorized list, which starts out populated with OSS namespaces. 3. If entries are found that aren't on the authorized list, the user gets a prompt like the following: An error was detected that includes stack frames with the following namespaces that you have not yet authorized for reporting to Eclipse Foundation. [list of namespaces] [Authorize] [Authorize Once] [Do Not Report] Looking at the stack trace, I read it as some Sapphire code is initializing a data service which is implemented/provided by an adopter. That adopter calls some WTP code which fails. From a Sapphire perspective it shouldn't matter if it's a WTP issue, i.e. it's the adopter's code which is failing. This should be handled in a way that an adopter realizes it. For example, Sapphire should catch the root exception and wrap it into a Sapphire specific error message which is then either presented to the user or logged to a log file. From an Eclipse.org error handler perspective, this error message should probably then be marked as log message. It really isn't Sapphires fault here. My goal is not to remove blame from Sapphire, but to improve the quality across the Eclipse ecosystem. As such, the proposed strategy doesn't help. My bottom line... Censored stack traces are useless. At the minimum, anything that would be censored should not be reported. Ideally, we should have a better system in place that avoids the need to censor so that we can help adopters improve their code and let them help us by exposing errors that are only evident in adopter scenarios. Thanks, - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Gunnar Wagenknecht Sent: Thursday, July 23, 2015 9:29 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Konstantin, Am 22.07.2015 um 13:01 schrieb Konstantin Komissarchik konstantin.komissarc...@oracle.com: Stack frames should not be considered sensitive just because they are from a non-OSS code base. Users post stack traces with commercial code references in forums all the time. Just because they can doesn't imply the are allowed to. There are all sorts of liability questions in here which I can understand as a reason to hide those. I think there is no other option. For most commercial code, the user can not simply allow disclosing such information but a vendor would have to approve. Anyway, I have a different view on your particular topic, which might be a possible approach for other adopters. Looking at the stack trace, I read it as some Sapphire code is initializing a data service which is implemented/provided by an adopter. That adopter calls some WTP code which fails. From a Sapphire perspective it shouldn't matter if it's a WTP issue, i.e. it's the adopter's code which is failing. This should be handled in a way that an adopter realizes it. For example, Sapphire should catch the root exception and wrap it into a Sapphire specific error message which is then either presented to the user or logged to a log file. From an Eclipse.org error handler perspective, this error message should probably then be marked as log message. It really isn't Sapphires fault here. BTW, the NPE in WTP is bad, though. But we simply can't now if it's a bug in WTP or if the adopter failed to initialize/setup some expected variables. But it should be the adopter investigating it. -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org, http://guw.io/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this
Re: [cross-project-issues-dev] Error reporter and third-party code
A big +1 -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Max Rydahl Andersen Sent: Thursday, July 23, 2015 5:12 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code On 22 Jul 2015, at 20:37, Marcel Bruch wrote: Konstantin, I assume you understand that user may find stacktraces to contain potentially sensitive data (if not - let’s assume it hypothetically), which options would you propose? I'll repeat what I've suggested in the past: add more to the list of OSS packages, i.e. add org.jboss.*, *.redhat.* and org.spring.* and possible more from the top 10 OSS plugins on marketplace. So at least the OSS collaborators can be contacted and we can help improve ;) /max http://about.me/maxandersen ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Error reporter and third-party code
'instance of Eclipse' is ambiguous. I mean the Eclipse installation. The reason I think this scope is the correct one is as that's where the plugins reside that the user is asked to make a choice regarding. For instance, I might have one installation with pre-release code that's private and another installation with all released code that's ok to report. If the choice is persisted in the workspace that seems too dangerous, one accidental answer and Eclipse becomes leaky. Accidental answers can happen regardless of which approach we use. Obviously, we would need a preference system for changing the preference after the initial prompt. Persisting only until the next Eclipse restart seems like a good idea. That seems highly unworkable. I don't know of any user who would tolerate constant prompting like that. Thanks, - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink Sent: Wednesday, July 22, 2015 9:28 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Hi IMHO, the 20% who explicitly enabled message anonymization will also enable method anonymization because they are avoiding the problem of needing corporate approval of any release of data. A method name such as SHA4096 may reveal what algorithm is being exploited/developed. Too risky if you are not sure. My proposal: When a we detect a non-OSS stack frame, we actively ask the user to make a choice that’s then persisted for that instance of Eclipse. 'instance of Eclipse' is ambiguous. If the choice is persisted in the workspace that seems too dangerous, one accidental answer and Eclipse becomes leaky. Persisting only until the next Eclipse restart seems like a good idea. Regards Ed Willink On 22/07/2015 22:39, Marcel Bruch wrote: My proposal:… Sounds okay to me. I wonder if the short cut „not to enable 3rd party class names in stack traces by default“ would be acceptable as well since it’s right on the configure dialog and easy to grasp (IMHO). Wayne, any thoughts on this? I can change the defaults (for SR1) if the EF would agree. FWIW, during the milestone build (until June 20th) 20% of the users explicitly enabled „message anonymization“ because they feared that the message may contains sensitive data. I’d expect that users are less concerned about method names. I’d need to validate this number with the current reporter base to give a more reliable statement, though. I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. I brought up the issue of better handling third-party plugins several times from the very beginning and was brushed off. I did a quick search for earlier discussions on this topic and found [1] from August 2014. I don’t have the impression you were brushed off in that discussion - but nevertheless: If I did (there or somewhere else) I apologize for that. Best, Marcel [1] https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03193.html Thanks, - Konstantin ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.6081 / Virus Database: 4392/10286 - Release Date: 07/22/15 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
