[cross-project-issues-dev] Disk usage report for Hudson/Build
Compiled 2015-07-22T12:07 build.eclipse.org - Usage exceeding 1GB for: Hudson master jobs and workspace (2015-07-22T10:00) 2.8G papyrus-trunk-nightly 2.3G ep45I-unit-lin64 2.1G ep46N-unit-lin64 1.6G ep45N-unit-lin64 1.5G ep45N-unit-mac64 1.5G ep45N-unit-win32 1.5G ep44M-unit-lin64 1.4G ep45I-unit-win32 1.4G ep44M-unit-mac64 1.4G ep46N-unit-win32 1.4G ep46N-unit-mac64 1.4G ep44M-unit-win32 1.2G emf-cdo-integration 1.2G ep45I-unit-mac64 1.2G papyrus-trunk-extra-nightly 1.2G m2m-atl-master 1.1G mylyn-release - Usage exceeding 1GB for: /shared (1000G capacity) (2015-07-22T10:00) 538.1G hipp 150.0G eclipse 139.2G rt 49.3G webtools 47.5G jobs 45.4G technology 23.1G SLES 18.3G common 11.7G tools 8.9G simrel 6.7G cbi-ng 5.3G modeling 3.1G orbit 1.9G download-staging.priv 1.6G mylyn 1.5G cbi 1.4G soa - Usage exceeding 1GB for: /shared/modeling 3.1G build - Usage exceeding 1GB for: /shared/tools 4.6G tm 2.8G objectteams 1.4G mtj 1.1G aspectj - Usage exceeding 1GB for: /shared/technology 18.6G epp 10.3G sapphire 5.2G babel 4.8G stem 2.4G cosmos 1.6G m2e END: build.eclipse.org hudson-slave1.eclipse.org /dev/xvda1158G 27G 131G 18% / - Usage exceeding 1GB for: Hudson workspace on hudson-slave1 (50G capacity) (2015-07-21T21:00) END: hudson-slave1.eclipse.org hudson-slave2.eclipse.org - Usage exceeding 1GB for: END: hudson-slave2.eclipse.org hudson-slave3.eclipse.org /dev/xvda1 55G 22G 34G 40% / - Usage exceeding 1GB for: Hudson workspace on hudson-slave3 (50G capacity) (2015-07-21T18:00) END: hudson-slave3.eclipse.org ___ 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
Konstantin, let me send this at the beginning: this discussion is greatly appreciated - although my personal answer might not be satisfying yet… Library projects like Sapphire or Nebula are somewhat special because they are (more or less) exclusively used by third-party plugins. Hence they do not benefit that much from the privacy defaults. First question… Why are third-party stack frames hidden? Although your questions may give a different impression, I assume that you and everyone else understands why classnames from non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default. No matter if one does or not, one may ask the following questions (again) and judge differently now (after ten thousands of users reported ~170K errors in the last 30 days): (i) whether a class name in a stacktrace should be considered as potentially private information“, and (ii) whether it should be anonymized by default. When we (Eclipse Foundation staff and me) discussed the legal implications of the error reporting we came to the conclusion that a class name may reveal sensitive information and thus should be anonymized by default. Are the notes from when this was originally considered captured somewhere? The discussion about what to anonymize and how took place on August 2014. First with the Eclipse Foundation Staff in a couple of conference calls and then published and summarized in several mails to cross-projects-issues-...@eclipse.org. 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. Let me know if you need me to pull up all emails and slides I sent to cross-projects regarding the error reporting at that time. I’m pretty sure the whole process was quite transparent at any time and visible to everyone starting from M1 to RC4 :-) I have contact info for many Sapphire adopters. If I knew who to contact, I could actually follow up on these error reports. IMHO this is more a legal question then a technical one. It all depends how lawyers (and users) judge on the two questions above. I can imagine that - if member companies agree to collect their error reports at eclipse.org OR to opt-in to disable anonymization for their bundles and namespaces - we can reduce the number of HIDDEN in your error reports. But as I said, this would need the support of the Eclipse foundation and like of the member companies. 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? Regards, Marcel ___ 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
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
Re: [cross-project-issues-dev] Error reporter and third-party code
I assume that you and everyone else understands why classnames from non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default. I can imagine cases, such as pre-release products and internal solutions, where stack frames contain sensitive information, but that isn’t the general case. 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. Companies that worry about this sort of thing scramble their bytecode. User should not be expected to know how to change preferences to turn off filtering as none of them will bother to do so, especially as the error reporting system gives them the impression that the error reports are actionable with information omitted. 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. If they make a choice indicating that non-OSS references are sensitive, we don’t even bother sending an error report. I have yet to see an error report with hidden frames that was actionable. This active choice should be viewed as equivalent to user making a choice to grab a stack from the log and post it on the forum. 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. Thanks, - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch Sent: Wednesday, July 22, 2015 11:37 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Error reporter and third-party code Konstantin, let me send this at the beginning: this discussion is greatly appreciated - although my personal answer might not be satisfying yet… Library projects like Sapphire or Nebula are somewhat special because they are (more or less) exclusively used by third-party plugins. Hence they do not benefit that much from the privacy defaults. First question… Why are third-party stack frames hidden? Although your questions may give a different impression, I assume that you and everyone else understands why classnames from non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default. No matter if one does or not, one may ask the following questions (again) and judge differently now (after ten thousands of users reported ~170K errors in the last 30 days): (i) whether a class name in a stacktrace should be considered as potentially private information“, and (ii) whether it should be anonymized by default. When we (Eclipse Foundation staff and me) discussed the legal implications of the error reporting we came to the conclusion that a class name may reveal sensitive information and thus should be anonymized by default. Are the notes from when this was originally considered captured somewhere? The discussion about what to anonymize and how took place on August 2014. First with the Eclipse Foundation Staff in a couple of conference calls and then published and summarized in several mails to cross-projects-issues-...@eclipse.org. 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. Let me know if you need me to pull up all emails and slides I sent to cross-projects regarding the error reporting at that time. I’m pretty sure the whole process was quite transparent at any time and visible to everyone starting from M1 to RC4 :-) I have contact info for many Sapphire adopters. If I knew who to contact, I could actually follow up on these error reports. IMHO this is more a legal question then a technical one. It all depends how lawyers (and users) judge on the two questions above. I can imagine that - if member companies agree to collect their error reports at eclipse.org OR to opt-in to disable anonymization for their bundles and namespaces - we can reduce the number of HIDDEN in your error reports. But as I said, this would need the support of the Eclipse foundation and like of the member companies. 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? Regards, Marcel ___ 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
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
