powerman
0

Для FF это плагины Spidermonkey и Stylish. Когда-то для IE это был Trixie, а для Safari NinjaKit, возможно сейчас уже другие. Плюс есть сайты вроде https://greasyfork.org/ для обмена модами между юзерами.

powerman
+1

Ну, вообще-то банковские трояны именно этим и занимаются уже очень много лет. И да, долбодятлом, почему-то, при этом принято считать именно пострадавшего — не обновлял ОС, не поставил правильный антивирус, качал из инета игрушки на комп с ДБО, запускал аттачи к письмам, etc. Я не говорю, что случай из статьи идентичен, там всё-таки неясно, что могли предпринять пострадавшие для своей защиты (ну, кроме выделения средств на аудит безопасности этого кода), но определённые параллели между этими ситуациями определённо наблюдаются.

powerman
+2

Хотя в общем направление мысли адекватное, но в статье всё настолько идеализировано и упрощено, что описанное скорее напоминает модель для настольной игры в разработку качественного ПО для детей среднего школьного возраста, нежели реалии нашей работы.

powerman
0

Именно. И так же есть решения для других упомянутых в статье проблем (использовать привилегированные порты обычный юзер может через setcap CAP_NET_BIND_SERVICE=+eip, фильтровать какие процессы он видит можно через GrSecurity, etc.). Но — вряд ли это взлетит. Докер удобно прячет всё это под капот, а что до большого размера образов… ну, с одной стороны это не такая уж большая цена, с другой если сервисы писать на Go или просто линковать статически то образ докера может занимать несколько мегабайт, а не гигабайт.

powerman
+1

Т.е. кейс тут один: сервис за NAT, к которому по своей инициативе подключается клиент не за NAT? Причём для подключения клиенту нужно заранее знать, на какой неиспользуемый IP отправляет пакеты конкретно этот сервис (их ведь за NAT может быть несколько, так что нужно дополнительно обеспечить уникальность этих неиспользуемых IP для всех сервисов за этим NAT), плюс клиент должен знать адрес самого NAT. И всю эту информацию клиент должен получить без использования промежуточного сервера.


Как по мне — всё это звучит крайне сомнительно. Для статических, штатных сервисов проще настроить форвардинг портов на NAT. Для динамических будет сложновато обеспечить распределение между ними на какие неиспользуемые IP они будут слать ICMP, плюс потребуется как-то доносить выбранный конкретным сервисом IP до клиентов, что ещё сложнее.


Либо я по-прежнему что-то упускаю, либо это странный и малополезный в реальных задачах хак, которым крайне сложно оправдывать поддержку спуфинга IP.

powerman
0

Если не ошибаюсь, когда-то amarao описывал в комментах почему провайдерам сложно реализовать защиту от IP-спуфинга. Если кто-нибудь найдёт этот коммент — добавьте ссылку сюда, плз.

powerman
0

А в чём именно ценность этих применений?


ReQrypt просто экономит немного скорости для пользователя и много трафика для своего сервера — это прикольно, но не настолько принципиально по сравнению с обычным прокси/VPN чтобы ради этого разрешать IP-спуфинг.


В чём ценность такого способа обхода NAT я, возможно, просто не понял — есть ведь немало других способов, чем конкретно этот лучше?

powerman
+2

К сожалению, разумные разработчики не настолько разумные, как нам бы хотелось. И психология этих разумных разработчиков не отличается от других людей. И работают они каждый над своим участком кода, зачастую не имея ни времени ни желания вникать в то, как что-то устроено на другой стороне или в следующем слое абстракции. Так что когда они видят не просто обычный набор параметров, а подписанный набор параметров — они обычно считают, что раз подпись есть, то она должна что-то да значить, в частности что параметрам можно верить (ведь зачем-то такую необычную подпись кто-то добавил… а разработчики, как известно, разумные, так что добавлять совершенно бессмысленную подпись они бы не стали :)). Да и просто подсознательно подписанным данным доверия всегда больше. Так что проверять подписанные параметры разработчики если и будут вообще, то совсем не так тщательно, как обычно.


Итого — вред есть, и значительный. Начиная с затрат времени на разработку и поддержку бессмысленного функционала, и заканчивая ослаблением безопасности из-за психологического фактора. А самое плохое то, что такой бессмысленный функционал часто со временем попадает в категорию "магическая хреновина, никто не знает зачем она нужна, но её нужно обязательно поддерживать в рабочем состоянии иначе неизвестно что может поломаться".

powerman
+1

Может, конечно. Я сам таким был. Но суть вопроса ведь не в этом. Всё описанное в статье по сложности реализации доступно и понятно начинающим разработчикам под андроид. Добавляем к этому желание взломать и хакерский склад ума — и всё, "защита" моментально обходится. Если начинающий разработчик может обойти эту защиту — зачем её вообще делали? Против кого, собственно? Где целевая аудитория хакеров, которые хотят это сломать, но не смогут этого сделать из-за недостатка квалификации/времени/средств? Кто и для чего придумывает глупости вроде этой "подписи" параметров HTTP, выполняемой кодом на клиенте, который контролирует хакер? Я бы ещё понял, если бы они этот код вынесли в C-шную библиотеку набитую антиотладочными приёмами — тоже не сильно поможет, но было бы видно, что они хотя бы пытались поднять планку требуемой квалификации для взлома. А в текущем виде это просто профанация.

powerman
+13

С чего Вы это взяли?


Я говорю "школьник" потому, что судя по упоминанию ЕГЭ в статье это сделал именно школьник. И какими бы умными не были школьники, квалификация людей профессионально занимающихся безопасностью обычно намного выше. Так что мой вопрос вполне уместен — если эта "защита" не в состоянии сдержать школьника, то хакера она тем более не сдержит — и зачем она тогда нужна вообще? Все остальные и так не будут пытаться подделывать HTTP-запросы.


Проблема в том, что от такой реализации "безопасности" больше вреда, чем пользы: на самом деле она ни от чего не защищает, но создаёт у разработчиков ложное чувство безопасности — якобы параметрам запроса можно доверять, раз они корректно подписаны. А доверять им, разумеется, нельзя, и код будет намного безопаснее, если об этом никто из разработчиков не будет забывать ни на секунду.

powerman
–3

И что, на масштабах mail.ru действительно дешевле потратить время и ресурсы на разработку и дальнейшую поддержку этого решения, вместо того чтобы просто воткнуть лишние 64GB памяти и ограничиться тривиальным идиоматическим кодом?

powerman
0
Эта библиотека сделана в лучших традициях security through obscurity, весь код надежно обфусцирован.

OMG… кто-то ещё такое использует в наши дни. Чего ради??? Чтобы потом это сломал школьник и VK с Mail.ru стало стыдно?

powerman
0
Если создать дополнительные издержки CA, за них заплатит конечный потребитель.

Не обязательно. Издержки CA более-менее фиксированные (не зависят от количества выпущенных сертификатов), так что их вполне реально покрывать за счёт платных EV сертификатов для средних/крупных компаний. Кроме того, их издержки могут покрываться гигантами вроде Google или дотациями из гос.бюджета — теми, кто заинтересован в безопасном вебе.


А вот если эти дополнительные издержки на обеспечивание высокого уровня защиты и контроля не создать, то какой в этих CA вообще смысл и чем они надёжнее моего собственного CA? По хорошему, используемый код и базовая инфраструктура CA должны быть выложены в открытый доступ для проведения публичного аудита. Поверх этого ядра они могут городить любые фичи/интерфейсы, но валидация того, можно ли выдать сертификат и сама выдача должна быть реализована одинаково у всех CA, и этот код должен лежать на гитхабе.

powerman
0

CA необходимо наказывать, причём максимально жёстко! И очень плохо, что это начинают делать только сейчас.


Сейчас на доверии CA держится почти полностью весь https (исключая редко используемые pinned сертификаты), и если CA не будут максимально серьёзно относиться к своей репутации и безопасности своей инфраструктуры — надёжность https может сильно пострадать.


Более того, я бы вообще список корневых сертификатов в браузерах сократил примерно на порядок — адекватно контролировать текущее количество должно быть очень сложно, поэтому стоит ужесточить требования к CA и отобрать корневые сертификаты у тех, кто будет не в состоянии выполнять эти требования.

powerman
0

Думаю, Вы правильно поняли автора статьи, но он ошибается. Дело в том, что Fog Creek — это очень «не репрезентативная выборка». Те плюсы, которые он описывает — не являются следствием работы с 9 до 5, дресскода или того, что такая "культура" позволяет брать на работу не только белых молодых хипстеров. Эти плюсы являются следствием того отношения к разработке, которое продвигает Джоэл Спольски.

powerman
0

Всё так, но, тем не менее, это шаг в правильном направлении.


По большому счёту сама идея CA не выдерживает никакой критики, особенно учитывая тот факт, что за нарушения эти CA зачастую не наказывают вообще, а если и наказывают, то недостаточно жёстко чтобы исключить такие нарушения в будущем. (Очень показательна история про WoSign и StartCom.)


Тем не менее, существуют механизмы, которые смогут обеспечить необходимый уровень безопасности. Просто у них есть своя цена. Скорее всего, постепенно всё это будет реализовано в массовых масштабах, но надо с чего-то начинать, и https в любом виде это неплохой старт.

powerman
0

Против отслеживания uBlock Origin и uMatrix вроде бы ставятся в любой браузер. Доверие у чистого chromium вроде примерно на том же уровне, что и у файрфокса.

powerman
+2

Проблема не в том, мелкие это разработчики или гиганты, а в том, что новое API в принципе не предоставляет необходимых возможностей для реализации многих плагинов. И эти плагины отвалятся в любом случае, вне зависимости от имеющихся ресурсов и желания их переписать под новое API. Вот пример мнения разработчика нужного мне плагина Tab Groups: http://fasezero.com/.

powerman
+9

Я думаю, что 57-я убьёт файрфокс.


В том смысле, что сейчас файрфокс — это браузер из которого можно сделать то, что тебе нужно плагинами. А после 57-й файрфокс перестанет быть файрфоксом, а станет таким же браузером, как и все остальные — жри что дают, и, да, ты можешь поменять фоновую картинку строки меню. Лично для меня это, вероятно, будет означать переход на вивальди, или какой-то другой браузер, который в режиме "жри, что дают" будет более похож на 12-ю оперу (поведение, которое сейчас реализовано в моём файрфоксе плагинами, которые не будут работать с 57-й версии).


В результате файрфокс потеряет свою основную изюминку, потеряет ещё больший процент юзеров, потеряет основных фанатов которые любили его тюнить под себя и советовали его за гибкость своим знакомым. И, в результате, через года три сдохнет совсем. Потому что новых юзеров взамен потерянных он этими изменениями не привлечёт.


Я понимаю, что текущая модель плагинов создаёт кучку проблем с безопасностью, и их надо как-то решать. Но выбранное решение больше всего напоминает лечение насморка гильотиной.

powerman
+2

Отказ вполне обоснованный — психология и моральные качества кандидата важны, они влияют на качество работы, на соблюдение как устных договорённостей так и NDA, на психологический климат в коллективе, etc. Всё это влияет именно на "деловые качества работника", так что нарушения закона в этом нет. А моральные качества вполне разумно определять и по тому, за какую работу кандидат брался в прошлом.


Я, например, не люблю нанимать людей, которые разрабатывали софт для спама. Если что-то такое всплывает — я стараюсь сначала выяснить, зачем он занимался такой работой, как долго и почему перестал, а уже потом принимаю решение.


Кроме того, на практике дискриминация была, есть и будет — где-то не наймут из-за пола, где-то из-за возраста, много где из-за того что судимый. А чаще всего — тупо потому, что ты не понравился на собеседовании. Чисто эмоционально/интуитивно не понравился, хотя формально "по деловым качествам" вроде бы подходишь. И можно размахивать ТК до посинения, но заставить взять себя на работу Вы не сможете.


Так что ничего нового/противозаконного мы там не обсуждали. На хабре полно статей о том, как проводить собеседования, как оценивать кандидатов — мы просто добавили ещё один пункт в список того, на что стоит обращать внимание при найме на работу. Более того, никто ведь в том обсуждении не предлагал как-то принуждать компании не нанимать людей работавших на роскомнадзор, речь шла только о том, что они должны иметь возможность сами решить, важно это для них или нет.

powerman
0

I2P/Tor лучше, чем тупо сервер зарубежом:


  • сервер быстро забанит роскомнадзор, а до блокирования I2P/Tor на практике доберутся не так быстро
  • сервер зарубежом даст повод обвинить участвующих в обсуждении что они продались врагу и вообще предатели родины
  • I2P/Tor дадут анонимность, без которой многие могут побояться участвовать
  • для упрощения доступа для остальных никто не мешает выставить статическое зеркало(а) сайта в обычном интернете, чтобы если не писать, то хотя бы читать могли все желающие
powerman
0

Как аудитория может быть меньше нуля? А на хабре её блокировкой сводят именно к нулю. Ну вот сейчас что произошло? Мы потрындели, статью забанили, мы разошлись. Выхлоп в результате равен нулю. Так что обсуждать надо там, где не банят. А вот рекламировать эти обсуждения и публиковать инструкции как в них поучаствовать — можно и на хабре, вполне себе ITшная тема — обсуждение IT-профсоюза в глубинах I2P.

powerman
0

Ну… я бы сказал, что неправильные темы надо обсуждать на правильных сайтах, где их не будут банить. Например, на внутренних сайтах I2P или Tor.

powerman
0

Не припомню там призывов к или рекомендаций по нарушению законодательства. Некорректные трактовки скорее всего были, но использовать это как повод для цензуры — это просто волшебно. Может попросите у администрации ссылки на конкретные "факты", которые они упоминают? Или это попадёт под "обсуждение действий администрации" и бан по этому, уже не выдуманному, поводу?


Резюмируя то обсуждение — профсоюз, забастовки и чёрный список на данный момент являются единственным законным способом выразить своё несогласие с происходящим, который ещё не используется.

powerman
+2
> Я уверен на 99,9%, что все разработчики и ПМ, имеющие авторизации в C/C++ и не только, после бюллетня от Интела и описания уязвимости, проверили свои кейсы на наличие теста пароля с нулевой длинной.

Просто Вы — романтик. А на практике те разработчики, которые беспокоятся о безопасности, ничего проверять не стали, потому что у них давно поставлены процессы и выработано определённое отношение к коду, при котором такие баги не проходят, а если и проходят, то в настолько неочевидных случаях, что просматривать быстренько код после чтения статьи на хабре бессмысленно. А те разработчики, которые о безопасности особо не задумываются — тоже не побегут ничего проверять, потому что им тупо пофигу.
powerman
0
наличие такой дыры делает очень вероятным наличие других дыр

Наличие «такой дыры» обозначает всего лишь недостаточное тестирование.

С точки зрения менеджера или админа — да. Потому что оценивается причина, по которой ошибка попала в продакшн.

С точки зрения разработчика — нет, это означает именно то, что написал я. Потому что оценивается причина, по которой такой код вообще попал в репо (был кем-то написан, прошёл чьё-то ревью, и был кем-то смержен в основную ветку). Если написанием кода в столь нежном и критичном месте занимается человек, который способен допустить такую грубую ошибку, и его код проходит ревью (либо ревью вообще не делается для таких критичных кусков кода) — это многое говорит о процессе разработки в целом и отношении к безопасности кода в целом. Такие ошибки в принципе не должны доходить до тестировщиков, если безопасность хоть как-то учитывается при разработке.
powerman
0

Понимаю Вашу мотивацию и нежелание отключать AMT, но наличие такой дыры делает очень вероятным наличие других дыр. Не знаю, есть ли они там на самом деле, была ли эта ошибка следствием трагической случайности или системного подхода "пофиг на безопасность" — но сейчас куча людей набросилась на новый лакомый кусочек в поисках новых дыр… или набросятся, как только эксплуатация этой дыры перестанет приносить достаточные дивиденды. Так что до проведения (желательно — публичного) внешнего аудита безопасности исходников AMT держать системы с доступом к AMT из интернета — значит нарываться на неприятности.

powerman
–4

И чем мне это поможет? Ставить ради этого dosbox, который всё-равно не получит доступ к портам из-за grsecurity?

powerman
0

Я там выше приводил ссылку на описание чипсета, и там сказано:


Intel® vPro™ Technology: No
Intel® ME Firmware Version: No
powerman
–1

Действительно, в ядре есть драйвер "Intel Management Engine Interface" и созданное им устройство /dev/mei0.


Устройств с указанными ID я не вижу, но есть вот это:


00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
        Subsystem: Gigabyte Technology Co., Ltd 6 Series/C200 Series Chipset Family MEI Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 25
        Region 0: Memory at f6607000 (64-bit, non-prefetchable) [size=16]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000feeff00c  Data: 41c1
        Kernel driver in use: mei_me

Упомянутая flothrone тулза MEInfo есть только под винду. Но я нашёл /usr/src/linux/Documentation/misc-devices/mei/mei-amt-version.c — теоретически она должна сказать активен ли AMT и показать его версию. Практически же она во-первых пытается работать с /dev/mei вместо /dev/mei0 (но это я поправил) и во-вторых выдаёт ошибку при попытке вызвать первый же ioctl после открытия /dev/mei0:


# ./mei-amt-version                                                                 
Error: IOCTL_MEI_CONNECT_CLIENT receive message. err=-1

В общем, странно всё это. Что-то вроде формально есть, но работать — не работает.

powerman
–1

Я не знаю, что на материнки с этим чипсетом ставится под винду, у меня линух и таких драйверов нет. Но даже если он ставится — не факт, что он реально работает, а не отвечает "no such device" на любые запросы.

powerman
–1
ME есть в любом чипсете Intel начиная с 5 серии (2010 год) и выше.

Даже SemiAccurate не утверждает этого наверняка. Вы более информированы на этот счёт? Есть пруфы или данное утверждение базируется на глубокой внутренней уверенности?


Z68 — это чипсет 6-й серии, ME там есть, и, уверен, он активен.

Не совсем понял, как может быть "активен" ME, если судя по официальной спеке Intel ME отсутствует на этом чипсете и даже по Вашим словам AMT выключена. Как можно проверить, что ME есть и даже активен?

powerman
–1

Тон там немного истеричный (хоть и не без причины), но в целом очень интересно было почитать, спасибо. Насчёт "любая система выпущенная за последние 10 лет" — у меня (десктопная) материнка 5-ти летней давности на Intel® Z68 Express Chipset, и судя по спеке интела там ME нет вообще.


В следующей статье разбирается как раз этот вопрос — если в спеке интела сказано что ME/AMT нет, то нет ли его на самом деле, или физически в железе он всё-таки есть, просто не активен. Я, конечно, не стал бы исключать такой вариант, но по-моему эта проблема несколько раздута. Возможность удалённо эксплуатировать громадное количество систем отправив им сетевой пакет, вне зависимости от OS этих систем и даже того, включены ли они — это одно. Теоретическая (на данный момент) возможность взломать текущую OS конкретной системы с целью прошить заточенную под материнку конкретно этой системы нестандартную прошивку, которая активирует "как бы отсутствующий" в железе AMT, с целью его эксплуатировать — это уже перебор, господа! Я уже молчу о том, что такой подход будет "применим" всегда и к любой системе — кто помешает после обновления/удаления ME использовать этот подход чтобы сначала вернуть старую уязвимую прошивку а потом захватить AMT?


В общем, проблема была бы понятнее и нагляднее, если бы вокруг неё было меньше восторженной истерии.

powerman
–1

Безусловно. Тем не менее, чтобы обычное приложение из юзер-спейса как-то достучалось до AMT, эксплуатировало уязвимость и в результате этого ускользнуло из под контроля OS, ему нужно сначала сделать что-то (напр. писать в I/O порты). В этот момент приложение ещё находится под контролем OS, и ему, теоретически, можно помешать — смотря каким образом реализовано взаимодействие с AMT (о чём я и спрашивал, собственно).


В случае удалённой эксплуатации помешать невозможно, потому что пришедший по сети пакет будет сначала обработан AMT, до того как его сможет увидеть OS. А вот в случае локальной эксплуатации, судя по всему, доступ к AMT реализуется через I/O порты, доступ к которым для приложений в юзер-спейсе полностью контролируется OS, так что тот же Grsecurity вполне в состоянии защитить систему.

powerman
–1

Вопросы в комментах на хабре задаются как раз тогда, когда времени и/или желания читать первоисточники нет. Я достаточно сильно интересуюсь безопасностью, но всё же не в такой степени, чтобы разбираться в таких вопросах профессионально — у меня и своя работа есть. Так что в данном случае я интересуюсь как обычный обеспокоенный пользователь этих продуктов: каким конкретно образом происходит доступ к ME на моей системе?


Доступ через I/O порты, похоже, заблокирован Grsecurity.
Прямой доступ через физическую память тоже заблокирован Grsecurity (/dev/mem).
Запись в /dev/cpu/*/msr тоже заблокирована Grsecurity.
Остаётся доступ через сеть, когда IPMI/BMC читают и перехватывают пакеты на уровне сетевой карты ещё до того, как их увидит OS (если OS вообще запущена в этот момент).
Есть ещё какие-то варианты помимо вышеупомянутых?


Что касается варианта с доступом через сетевые пакеты — насколько я понимаю, в десктопных материнках, в которых нет IPMI/BMC, это работать не должно (WakeOnLan я обычно в BIOS отключаю, не знаю, имеет ли это отношение к данной ситуации).


Так и в этом случае: как уже успели выяснить исследователи, эксплуатировать дыру можно и на консьюмерском чипсете, только не удаленно, а локально. То есть, например, какая-нибудь малварь из юзерспейса вполне способна получить неограниченную власть над системой.

Вот, собственно, то, что мне интересно: работает ли вышеупомянутый "локальный" способ эксплуатации при наличии Grsecurity, и если работает — то через что. Раз возможности удалённо эксплуатировать вроде бы нет, то не похоже, чтобы отправка/инжектирование специально сформированного сетевого пакета давала доступ к ME. А все остальные локальные способы вроде бы заблокированы Grsecurity.

powerman
0

Безусловно, но ведь до ME сначала надо как-то добраться. И вот добраться до ME grsec помешал.

powerman
0

Там есть ссылка на тулзу intelmetool, которая должна показать текущее состояние ME. Я попробовал у себя запустить, но ничего не вышло:


kern.alert: grsec: denied use of iopl() by /home/powerman/tmp/coreboot/util/intelmetool/intelmetool[intelmetool:12327] uid/euid:0/0 gid/egid:0/0, parent /bin/zsh[zsh:12020] uid/euid:0/0 gid/egid:0/0

Надо полагать, наличие Grsecurity в ядре помешает не только этой тулзе, но и попыткам эксплуатировать ME…?

powerman
0

У меня SSD нет, так что дисковый кеш я оставлю в покое. С ним:


% time zsh -f -i -c 'autoload -Uz compinit ; compinit -D'
0.113 real  0.086 user  0.024 sys  6MB RAM

% rm -f ~/.zcompdump*
% time zsh -f -i -c 'autoload -Uz compinit ; compinit'
0.167 real  0.132 user  0.029 sys  6MB RAM
% time zsh -f -i -c 'autoload -Uz compinit ; compinit'
0.026 real  0.018 user  0.007 sys  6MB RAM

% time zsh -f -i -c 'autoload -Uz compinit ; compinit -C'
0.021 real  0.020 user  0.000 sys  6MB RAM

Но ведь кеш compinit можно ещё и откомпилировать, как я упоминал выше!


% zcompile ~/.zcompdump
% time zsh -f -i -c 'autoload -Uz compinit ; compinit'
0.011 real  0.005 user  0.006 sys  6MB RAM
% time zsh -f -i -c 'autoload -Uz compinit ; compinit -C'
0.004 real  0.004 user  0.000 sys  6MB RAM

Вооот! Такие цифры мне нравятся намного больше. Хотя -C в реальной жизни использовать вряд ли получится, вручную за актуальностью следить как-то не хочется.


Update: Размеры:


-rw-r--r-- 1 powerman powerman 40264 апр 25 22:41 .zcompdump
-r--r--r-- 1 powerman powerman 88728 апр 25 22:43 .zcompdump.zwc
powerman
0

Что даёт compinit написано в man zshcompsys. Если всё работает — вероятно ваш фреймворк тоже вызывает compinit (они все это делают, что характерно) и ничего не потеряно.

powerman
0
100 мс — пустой .zshrc

Так не должно быть. Пустой это вот так:


% time zsh -f -i -c 'echo ok'                                                                  
ok

0.002 real  0.001 user  0.000 sys  8MB RAM

Система у меня чуть по-быстрее Вашей (i7 @ 4.5GHz, hdd, zsh-5.2, gentoo), но не настолько же.