ShoreLine Reporter is in Pharo 4

> On 08 Dec 2014, at 14:27, Tommaso Dal Sasso <[hidden email]> wrote:
>
> Hello everybody,
>
> I am excited to announce that ShoreLine Reporter is now part of Pharo 4.
> ShoreLine Reporter is a tool to detect and report errors in Pharo: whenever a user encounters an exception, she can select the "Report" option from the Pre Debug Window and send a stack trace to the ShoreLine server.
>
> We are using the collected data to identify bugs in the system faster. We are also building a set of tools that the community can use to visualize the information from Pharo exceptions. More on that soon ;-)
>
> If you want to help the Pharo development just press the "Report" button to submit your exceptions. You can also decide to submit every exception without being bothered by selecting the "always submit" checkbox.
>
> We do not want to intrude your privacy: this option is opt-in and does not send any data without your explicit consensus. Also, we are working to introduce the possibility to filter the stack trace data that involves proprietary code, and include only information regarding the core system.

> Hi Tommaso,
>
> I think this is a cool initiative, many environments have something similar, so this is a welcome addition.
>
> However, you must be clearer about the security implications (and/or tell us how these concerns are dealt with in other places). Say I execute:
>
> ZnEasy
>    get: 'http://zn.stfx.eu/nuclear-launch-codes.txt'
>    username: '[hidden email]'
>    password: 'michele'.
>
> This will leave sensitive hosts, ports, URIs, usernames and above all passwords on the stack. Will these be reported/uploaded as well ?
>

> On 08 Dec 2014, at 16:34, Tommaso Dal Sasso <[hidden email]> wrote:
>
>
> On 08/12/14 14:47, Sven Van Caekenberghe wrote:
>> Hi Tommaso,
>>
>> I think this is a cool initiative, many environments have something similar, so this is a welcome addition.
>>
>> However, you must be clearer about the security implications (and/or tell us how these concerns are dealt with in other places). Say I execute:
>>
>> ZnEasy
>>   get: 'http://zn.stfx.eu/nuclear-launch-codes.txt'
>>   username: '[hidden email]'
>>   password: 'michele'.
>>
>> This will leave sensitive hosts, ports, URIs, usernames and above all passwords on the stack. Will these be reported/uploaded as well ?
>>
> Hi Sven,
>
> you are right, I stressed the idea when I first presented ShoreLine Reporter to the mailing list but it is important to be clear: We do not collect any kind of sensitive data. The stack trace we collect is in text in the format ClassName>>methodSignature:, to be sure that we exclude any parameter, password or repository.
>
> In addition to the stack trace, we collect the author name, the date and the pharo version, to cluster the data and have an idea of the evolution of the system during time.
>

> On 08 Dec 2014, at 17:12, Marcus Denker <[hidden email]> wrote:
>
>>
>> On 08 Dec 2014, at 16:34, Tommaso Dal Sasso <[hidden email]> wrote:
>>
>>
>> On 08/12/14 14:47, Sven Van Caekenberghe wrote:
>>> Hi Tommaso,
>>>
>>> I think this is a cool initiative, many environments have something similar, so this is a welcome addition.
>>>
>>> However, you must be clearer about the security implications (and/or tell us how these concerns are dealt with in other places). Say I execute:
>>>
>>> ZnEasy
>>>  get: 'http://zn.stfx.eu/nuclear-launch-codes.txt'
>>>  username: '[hidden email]'
>>>  password: 'michele'.
>>>
>>> This will leave sensitive hosts, ports, URIs, usernames and above all passwords on the stack. Will these be reported/uploaded as well ?
>>>
>> Hi Sven,
>>
>> you are right, I stressed the idea when I first presented ShoreLine Reporter to the mailing list but it is important to be clear: We do not collect any kind of sensitive data. The stack trace we collect is in text in the format ClassName>>methodSignature:, to be sure that we exclude any parameter, password or repository.
>>
>> In addition to the stack trace, we collect the author name, the date and the pharo version, to cluster the data and have an idea of the evolution of the system during time.
>>
>
> We should add this explanation to the tool itself…
>
> Marcus