[devel] I: debuginfod.altlinux.org for KDE

[Anton Farygin]

On 02.12.2020 14:32, Andrey Savchenko wrote:
> On Wed, 2 Dec 2020 14:29:02 +0300 Vitaly Chikunov wrote:
>> On Wed, Dec 02, 2020 at 02:21:32PM +0300, Andrey Savchenko wrote:
>>> On Wed, 2 Dec 2020 14:13:30 +0300 Vitaly Chikunov wrote:
>>>> On Tue, Dec 01, 2020 at 09:31:20PM +0300, Andrey Savchenko wrote:
>>>>> On Tue, 1 Dec 2020 15:16:45 +0300 Vitaly Chikunov wrote:
>>>>>> On Tue, Dec 01, 2020 at 01:40:34PM +0300, Andrey Savchenko wrote:
>>>>>>> On Fri, 27 Nov 2020 19:05:11 +0300 Anton Farygin wrote:
>>>>>>>> On 27.11.2020 13:50, Sergey V Turchin wrote:
>>>>>>>>> On Friday, 27 November 2020 13:34:26 MSK Anton Farygin wrote:
>>>>>>>>>> On 27.11.2020 13:30, Vitaly Chikunov wrote:
>>>>>>>>>>> On Fri, Nov 27, 2020 at 01:29:01PM +0300, Anton Farygin wrote:
>>>>>>>>>>>> On 27.11.2020 13:11, Vitaly Chikunov wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> В _тестовом_ режиме запущен сервер debuginfod.altlinux.org позволяющий
>>>>>>>>>>>>> (при наличии elfutils 0.182-alt2 и/или gdb 10.1) получать debuginfo
>>>>>>>>>>>>> (DWARF и исходники) для отладки и получения читабельных stack traces без
>>>>>>>>>>>>> инсталляции -debuginfo пакетов.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Как пользоваться:
>>>>>>>>>>>>>       $ export DEBUGINFOD_URLS="http://debuginfod.altlinux.org/"
>>>>>>>>>>>> Класс! На него как-то загружаются пакеты ?
>>>>>>>>>>> Он периодически сканирует архив.
>>>>>>>>>>>
>>>>>>>>>>>> Пакеты из бранчей есть ?
>>>>>>>>>>> Есть.
>>>>>>>>>> Спасибо! Очень нужный сервис.
>>>>>>>>>>
>>>>>>>>>> @zerg: можно прикрутить к KDE5 ?
>>>>>>>>> Думаю, да.
>>>>>>>>>
>>>>>>>> Вообще отлично будет, если вы это сделаете по умолчанию для обработки
>>>>>>>> падений.
>>>>>>> Т.е. чтоб сегфолтнулось, а потом не пойми что в инет лезло?
>>>>>>> Нет спасибо, из коробки такое не нужно. Это прямая угроза
>>>>>>> безопасности и конфиденциальности. Особенно с точки зрения админа
>>>>>>> системы, а не разработчика такого решения.
>>>>>> При этом, подобные сервисы работают, например, у Федоры по ~60000
>>>>>> автоматических багрепортов в сутки:
>>>>>>
>>>>>>    Статистика:
>>>>>>    https://retrace.fedoraproject.org/faf/summary/
>>>>>>    https://retrace.fedoraproject.org/faf/stats/today/
>>>>>>
>>>>>>    Репорты:
>>>>>>    https://retrace.fedoraproject.org/faf/reports/
>>>>> Федора никак не может являться образцом для подражания в вопросах
>>>>> безопасности.
>>>> Я предполагаю, что 98% пользователей хотят нам дать эту информацию
>>>> (анонимизировао, естественно) для улучшения качества репозитория.
>>>> Особенно, для не стабильно бранча, где подразумевается тестирование.
>>>> При этом, понятно, что нельзя такое включать для тех кто категорически
>>>> не хочет.
>>> Пользователи часто недооценивают серьёзность ситуации. Здесь очень
>>> много каналов утечек: как косвенных, один из которых описан выше,
>>> так и прямых, например, backtrace может содержать части ключей или
>>> иной конфиденциальной информации (по сути дела всё, что аргументы
>>> функции попадёт и не только).
>>>
>>> Поэтому включать из коробки такую функциональность категорически
>>> нельзя. Для продвинутых пользователей, осознающих риски
>>> и последствия, безусловно должен быть способ включить данную
>>> функциональность.
>> Такой подход тождественен тому, что её включать вообще никогда и нигде
>> нельзя. Потому что "продвинутый пользователь" один на миллион и он не
>> будет её включать. А делать систему ради одного пользователя, которому
>> это не нужно - напрасный труд.
> В таком случае её не следует делать.
>
> Аргумент, что пользователи должны жертвовать своей безопасностью
> и конфиденциальностью потому, что разработчики затратили ресурсы
> и время на создание сервиса — неприемлемый.
>
Я думаю что правильнее в момент отправки bug-report'а предупредить 
пользователя о возможной утечке конфиденциальных данных.

Т.е. - не надо решать за пользователя, готов ли он нам помогать за счёт 
собственной безопасности - давайте дадим выбор именно ему.