Всех приветствую.

Столкнулся с необходимостью проверить стойкость веб-форм к прямому перебору. Есть одна единственная форма, без капч, без ханипотов и т.п., голый PHP без JS, но с cookie(уберу потом), метод POST. Какое ПО под Linux лучше всего подойдёт? Как местные админы экспериментируют?

Kali Linux не ставил, с Wi-Fi всё в порядке, я и правда из админского интереса, док-ва на странице профиля.

Можно залить на сервер и проверять localhost, но мне больше интересно, как на это отреагирует onion-сервис.

Спасибо.

Согласно RFC 4880, GnuPG использует симметричный сессионный ключ для шифрования сообщений даже в том случае, если этот сессионный ключ сам шифруется исключительно симметрично.

Это позволяет, например, шифровать сообщение одновременно и паролем, и открытыми ключами, и Диффи-Хеллманом(по схеме ECIES). Я экспериментировал на практике и столкнулся с одной странной особенностью GnuPG — цитирую RFC:

If the Symmetrically Encrypted Data packet is preceded by one or more Symmetric-Key Encrypted Session Key packets, each specifies a passphrase that may be used to decrypt the message. This allows a message to be encrypted to a number of public keys, and also to one or more passphrases.

Тем не менее, сколько я ни искал, так и не нашёл способа задать несколько паролей с помощью gpg. Поиски на официальных ресурсах GnuPG также ни к чему не привели. Не понимаю: это я что-то делаю не так или GnuPG действительно не поддерживает все возможности, описываемые тринадцатилетним RFC 4880, хотя уже сейчас активно стремится соответствовать свежему и ещё не принятому RFC 4880bis?

Как всё же использовать несколько паролей?

Продублирую сюда на всякий: Ликвидация EncroChat

Не так давно Европол, NCA, Национальная жандамерия Франции и совместная следственная группа, сформированная при участии Франции и Нидерландов, провели совместную спецоперацию с целью компрометации серверов EncroChat путём «установки технического устройства» на серверы во Франции(1), чтобы получить возможность «вычислять и идентифицировать преступников с помощью анализа миллионов сообщений и сотен тысяч изображений».(2)

Некоторое время спустя после операции, EncroChat, обнаружив вторжение, разослал сообщение пользователям с рекомендацией «немедленно отключить и утилизировать ваши устройства».

Только в Соединённом Королевстве было арестовано 746 подозреваемых, изъято:

• Более £54 000 000 наличными деньгами
• 77 единиц огнестрельного оружия, в том числе AK47(прим. ред: это AKM), пистолеты-пулемёты, пистолеты, 4 гранаты и более 1 800 патронов.
• Более двух тонн наркотических веществ класса A и B
• Более 28 миллионов таблеток этизолама(так называемый «уличный диазепам»)
• 55 дорогостоящих автомобилей и 73 штуки дорогих часов.

EncroChat представлял собой набор ПО и оборудования(модифицированные смартфоны) для организации коммуникаций с «гарантированной анонимностью, сквозным шифрованием, модифицированной платформой Android, двойной операционной системой, „самоуничтожающимися сообщениями“, „кнопкой паники“, уничтожением данных при множестве неверных попыток ввода пароля, secure boot, отключённым ADB и режимом восстановления»(3)

Платформа EncroChat на момент ликвидации насчитываля десятки тысяч пользователей(≈ 60 000) из разных стран, в том числе РФ. Стоимость модифицированных смартфонов составляла £1000, ПО — £1,500 за полугодовой контракт.

P.S. А вот пользовались бы они Tor + PGP не со смартфонов, а с нормального ноутбука со свободной ОС — не поймали бы никогда.

Немного саморекламы: есть анонимный Ящик, работает только через onion-сервис Tor, не требует javascript, cookie и регистрации. Из метаданных только дата отправки сообщения(без часов, минут и секунд) и его размер, всё остальное должен указывать сам пользователь.

Шифровать сообщения пользователь тоже должен сам, а простейшая инструкция есть тут: http://7apievo4h7gelatn.onion/contact.html

Приглашается sekreti-gollivuda и все неравнодушные.

Как вы наверняка знаете, сегодня(1 июля уже наступило по МСК) РКН «должен был заблокировать анонимные сети, такие как Tor, I2P...»

Что же, предлагаю обсудить итоги этой блокировки!

Заранее хочу оговориться: я очень надеялся успеть закончить свой сайт полностью, чтобы как можно жёстче простебать паникёров, но несколько форс-мажоров и необходимость администрировать не один десяток(*вставить другие отговорки*), так что прошу строго не судить — материал готовится, я обещал статьи по настройке Tor — они будут. То, что я сейчас выложу, сделано впопыхах, так что прощу простить за возможные глупые ошибки.

Но мы отвлеклись... Так вот, предлагаю объявить сегодняшний выходной день днём анонимных сетей в целом и onionland в частности! Как говорит мой коллега: «An onion a day keeps the bad guys away».

И вам, дорогие друзья, я дарю:

1. Ящик. Это сервис для анонимной и конфиденциальной личной переписки. Доступен только через .onion, не просит включить всякие гадости вроде javascript, cookie, равно как и не требует регистрации:

http://prf6ovijrqcv23rkkih6573em5xuve4dsl65dk5f2kzdjijio6w5uqyd.onion/

Лоровцам разрешаю пользоваться этой штукой как личкой на форуме. Ъ, полностью совместим с консольными браузерами, лично я тестировал с Elinks. Самые ЪЪЪ могут проверить telnet, может даже заработает :^)

Пример оформления подобной «лички» смотрите в моём профиле. Там же найдёте дополнительные инструкции, если нужно.

Только не злоупотребляйте особо, база данных будет очищаться примерно раз в 3 месяца, но при перегрузке может быть очищена раньше. Ъ хранят сообщения только локально, а удалённые хранилища чистят сами.

2. И самое, пожалуй, главное и трудоёмкое — список полезных onion-сервисов, без мошенников, барыг, скриптошкольников и прочего. Вот он тут:

http://7apievo4h7gelatn.onion/nav/onions.txt

Сюда попали только самые «чистые» сервисы. Сейчас в обработке у меня ещё несколько сотен. Сканировать сети вручную — не самое простое дело, однако. Об этом легко забыть без постоянной практики.

И вы, кстати, очень даже можете мне помочь с этим, если хотите внести свою лепту в развитие нормального интернета, без шпионящих и вездесущих сетевых гигантов, с обилием персональных сайтов(!) и прочего добра, казалось бы, давно канувшего в лету.

При чём тут Линукс? А всё просто — вы можете мне помочь, прислав .onion-адрес вашего любимого дистрибутива. *BSD тоже приветствуются. Сейчас именно с Linux в списке туговато.

Присылать лучше в этот самый Ящик. Мой ключ можно взять тут: http://7apievo4h7gelatn.onion/mykey.asc

Да, кстати, горячо приветствую всех сторонников федерализации и/или децентрализации, параноиков и всех, кого волнует анонимность и безопасность, и всемерно советую поднимать onion-сервисы!

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

Разумеется, подробная инструкция будет скоро доступна у меня на сайте, можно просто подождать. А пока попрошу особо по ссылкам не ходить — всё равно там только 404.

Так что можете присылать любые onion-сервисы, которые, на ваш взгляд, достойны быть известными. И заранее благодарю всех за помощь.

P.S. Для Ъ — в случае с onion-сервисами это не вы ходите по ссылкам, а ссылки ходят по вам.

Communicate!

Приветствую.

Интересует возможность использования (совершенной)прямой секретности с GnuPG(и другими реализациями PGP). GPG удобен своей гибкостью(пусть и требует от пользователя определённого опыта) и тем, что позволяет легко превращать любые данные в base64-шифротекст, предоставляя возможность обмениваться не только текстом, но и медиафайлами и целыми архивами.

Однако асимметричные криптосистемы, поддерживаемые GnuPG, статичны(ECC тоже) и работают только по «классической» схеме с использованием долговременных ключей. Использование постоянных ключей для шифрования подразумевает возможность восстановить переписку при компрометации единственного секретного ключа(дешифруются все сообщения одной стороны, легко предполагается содержание шифротекстов другой), что не позволяет обеспечить ни прямую, ни обратную секретности. Более того, единственный доступный способ аутентификации(ЭЦП) не предполагает отрицаемости сообщений, что ставит под угрозу обе стороны.

Должен уточнить, это вовсе не праздный теоретический интерес, на данный момент завершаются работы над системой обмена сообщениями через Tor, шифрование сообщений в которой возложено целиком на пользователя(защиту от стороннего наблюдателя, конечно, обеспечивает и Tor, но защиту от злого админа(меня) обеспечивают только сами пользователи). Соответственно, теоретические и практические наработки пойдут в руководство пользователя. Ссылку на систему я вам и всем желающим дам чуть позже, как только будет завершено оформление и наполнение сайта(сама система полностью готова).

Какой вариант я рассматриваю сейчас?

Рассмотрим ситуацию с двумя участниками обмена: Алисой(адресант, инициатор) и Бобом(адресат). Пошагово это выглядит так(предполагается использование RSA, но это работает с любым асимметричным алгоритмом, в т.ч. «постквантовым»):

• Алиса и Боб генерируют две пары долговременных ключей(одну каждый) и обмениваются открытыми ключами друг с другом.
• Алиса дополнительно создаёт одноразовую пару ключей.
• Алиса отправляет свой одноразовый открытый ключ Бобу, предварительно зашифровав его долговременным открытым ключом Боба и подписав своим постоянным секретным ключом.
• Боб, удостоверившись в аутентичности подписи, отправляет временный секрет(длинную псевдослучайную последовательность символов), его «срок жизни»(количество сообщений и срок годности) и предпочтительную схему симметричного шифрования(AES, Twofish, Serpent и т.п. с длиной ключа, прим AES-128.) Алисе, предварительно зашифровав сообщение одноразовым открытым ключом Алисы и подписав своим постоянным секретным ключом. На данном этапе аутентификация завершена.
• Алиса, уничтожив временную пару ключей, отправляет тестовое сообщение, зашифрованное уже общим секретом, благодаря чему обеспечивается аутентичность всех сообщений с тем же секретом, повышается(на порядки) скорость работы и стойкость шифрования(в разы).
• Полученный секрет используется до окончания его «срока жизни», после чего операция повторяется, начиная со второго шага.

При использовании такого подхода компрометация долговременных ключей раскроет только метаданные(когда и с кем устанавливалось соединение), но не позволит дешифровать основную информацию. Чтобы усложнить анализ содержимого по размеру криптограммы, каждое сообщение дополняется случайным количеством случайных данных в base64. Например так:

#!/usr/bin/env bash
randexp=$(cat /dev/urandom | tr -dc '1-3' | head -c1)
randbyte=$(cat /dev/urandom | tr -dc '0-9' | head -c$randexp)
cat /dev/urandom | head -c$randbyte | base64

Что насчёт анонимных сообщений? Всё просто - используется открытый ключ одной из сторон, но адресант не подписывает сообщение. Известен получатель, но не отправитель. А первоначальный обмен открытыми ключами можно произвести, например, с помощью OnionShare(«Trust» в Web of Trust, КМК, доверия не заслуживает).

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

На первый взгляд всё красиво, не так ли? Да и всю эту «рутину»(кроме первого шага) можно автоматизировать одним коротким исполняемым файлом.

Тем не менее, какие уязвимости есть у такого подхода? Интересует ваше мнение.

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

Как бы то ни было, заранее спасибо за помощь.

Постарался всё максимально красиво оформить и успеть раньше всех. Дабы не засорять главную страницу и не вынуждать сносить комментарии, думаю, стоит перенести обсуждение оформления новости сюда.

Новость большая, потому мог где-то ошибиться. С радостью исправлю всё, что потребуется.

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

Утилиты командной строки в GNU/Linux очень хорошо справляются с поиском текста в файлах, поиском файлов по названию и метаданным и т.п. Но они, к сожалению, совершенно не подходят для работы с файлами, содержащими графическую информацию, такими как документы pdf, фото, картинки, видео и т.п. Особенно тогда, когда речь идёт о десятках тысяч таких файлов, занимающих десятки гигабайт дискового пространства(полные копии целых сайтов, например).

Что я под этим подразумеваю?:

• Возможность быстрого и эффективного поиска подобных файлов не только по расширению, но и по фактическому содержанию
• Нормальная поддержка миниатюр
• Возможность сортировки по определённым критериям(размер, метаданные, название, тип файла) и даже сразу по нескольким
• Хорошая производительность. Расход оперативной памяти значения не имеет

До последнего времени подобные операции приходилось производить на оффтопике. Там даже встроенный(начиная с 7) в проводник поиск позволял довольно удобно работать, например, храня миниатюры в оперативной памяти и только те, которые используются прямо сейчас, а с установкой дополнительного ПО становилось совсем просто.

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

И если проблему с миниатюрами решить довольно легко(смонтировав папку с ними в tmpfs), то вот с остальным пока беда.

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

Соответственно, интересует возможное ПО для продвинутой работы с файлами.

Заранее спасибо за помощь.

Что-то в последнее время система так и норовит рассыпаться. Ладно, можно понять, почему clang не хочет «переваривать» переход на python3_7, но вот это:

~ # make oldconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --oldconfig Kconfig
scripts/Kconfig.include:39:  gold linker 'ld' not supported
make[1]: *** [scripts/kconfig/Makefile:73: oldconfig] Ошибка 1
make: *** [Makefile:567: oldconfig] Ошибка 2

Вот уточнение по заветному адресу:

sed -n 38p scripts/Kconfig.include 
# Fail if the linker is gold as it's not capable of linking the kernel proper

Уже совсем атас. Вот ума не приложу, ГДЕ он у меня в системе вообще нашёл ld.gold?

Само собой, ни menuconfig, ни nconfig, ни ручное копирование и редактирование .config с попыткой собрать это не работает - абсолютно та же ошибка.

Как системе без ядра-то работать? Тупик, копать дальше некуда, это только у меня или так и должно быть?

В чём суть: у меня в частном секторе стоит уже много лет подряд мощный сидбокс, собранный из списанного серверного оборудования, 24\7 качающий всякую всячину через I2P. IP выделенный, канал высокоскоростной.

Несколько дней назад стал замечать странные периодические просадки скорости с привычных нескольких мегабайт\сек до 200-400 килобайт. Чуть позже просадки стали постоянными, а скорость редко была выше 200 килобайт\сек. До последнего списывал это всё на «самоизоляцию», но сегодняшнее поведение сети едва ли можно объяснить только возросшей нагрузкой.

Дело вот в чём: в начале дня всё было вроде как обычно, но периодически скорость сети падала почти до нуля. Обычно этот спад наблюдался не более 20-30 минут(больно, но терпимо), ничего подозрительного. Но уже со второй половины дня спады стали происходить слишком часто, а недавно я обнаружил, что I2P жалуется на блокировку извне.

Я полностью перезагрузил систему, но это не особо помогло - стало писать, что IPv6 заблокирован, а IPv4 свободен, скорость держится в районе 10-30 килобайт\сек. Тут запахло жареным - это сильно похоже на целенаправленную блокировку со стороны провайдера. Floodfil с маршрутизатора быстро слетел, количество известных участников сети сократилось с 6-8К до 2.5К. Интересно, что Tor работает нормально, никаких просадок и чего-то подозрительного, даже без использования мостов.

Мне вот интересно, было ли у кого тут подобное? Если сможет кто у себя проверить работоспособность сети - буду крайне благодарен.

И всё же, ведь внешне трафик I2P сложно отличить от обычных торрентов, не так ли? Как в таком случае возможна адекватная фильтрация?

Собственно, впервые решил попробовать использовать MAC на домашнем компьютере, ибо нет желания, чтобы браузер и другие приложения с доступом в сеть имели возможность читать что угодно в /home/ и потенциально могли стащить\стереть ключи, памятки, заготовки и т.п.. AppArmor выглядит идеальным вариантом, ибо очень давно с ним знаком, да и особо тонкая настройка не нужна, а более простые системы потенциально ненадёжны(?).

Составил профиль для Firefox, запустил и сразу обнаружил, что при некоторых действиях нагрузка на не самый слабый процессор подскакивает до 30-50%. Вот в порядке убывания нагрузки:

• Медиа и динамичные сайты
• Загрузка страницы
• Прокрутка страницы

Журналы пустые, никаких предупреждений и запрещённых запросов не наблюдаю, более того - нагрузка не уменьшается в претензионном(complain) режиме.

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

Вопросы: есть ли у кого-то кроме меня подобные наблюдения при использовании AppArmor? Возможно ли это как-то исправить, или проблема в самом AppArmor(а с SELinux и другими MAC такого нет)?

Встроенный Unix DAC слишком топорный и вынуждает создавать по пользователю на каждое приложение, что неприемлемо(да и корень не защищает никак), соответственно, вопросы актуальны в любом случае.

Спасибо за помощь

(Не знаю, куда лучше бы написать, потому напишу сюда. Можно и перенести)

Платформа: Firefox >=67.0 на GNU/Linux & Windows 10(вплоть до 74.0a1)

Краткая суть: Firefox >=67.0 игнорирует пользовательские настройки параметра browser.sessionhistory.max_entries и использует значение по умолчанию

Развёрнуто: После изменения параметра через about:config браузер работает как ожидается, но при правке через user.js\prefs.js и\или после перезапуска браузера параметр игнорируется, используется значение по умолчанию(50), несмотря на корректное отображение параметра в about:config. Исправляется только ручной правкой значения в about:config сначала на произвольное, затем на необходимое.

Как воспроизвести:

1 Способ:

1. Установить Firefox >=67.0
2. Изменить значение параметра через about:config
3. Перезапустить браузер

2 Способ:

1. Установить Firefox >=67.0
2. Изменить параметр с помощью user.js\prefs.js
3. Запустить или перезапустить браузер

Способы проверки:

1 Способ:

1. Запустить браузер и посетить несколько страниц в одной вкладке
2. Выполнить этот скрипт в консоли на той же вкладке:

alert("Количество посещённых страниц - " + history.length +  "!")

2 Способ:

1. Запустить браузер
2. Перейти по адресу https://ip-check.info и пройти тест

Планирую написать на багзиллу. Обнаружил похожий репорт на багзилле, но он недостаточно подробен.

Прошу подтвердить пользователей Firefox любой версии. Возможно, баг присутствует не только в 67.0 и далее.

Спасибо за помощь.

Интресно мнение тех, кто так или иначе связан с администрированием сайтов и т.п.(потому в talks, но можно и перенести при необходимости)

Коротко о сути: решил поехать на время зимнего отпуска в тёплые арабские страны. Желания светить свою сетевую активность публичному wifi нет, как нет и желания светить сам факт использования своей ПВС. Решил использовать Tor и забыть о проблемах.

Но дело в том, что некоторые сайты банят выходные узлы даже в режиме read only. Ок, я могу понять, зачем блокировать регистрацию через тор. Ок, могу понять, почему всякие костыли «для защиты от DDoS и роботов» ругаются на тор, благо их легко можно усмирить. НО, зачем(зачем?!) блокировать тор полностью, без попытки регистрации? Кто-то правда думает, что это хоть чем-то поможет бедному сайту? Серьёзно?! Кто захочет зайти через тор - тот элементарно обойдёт эту шелуху.

На пальцах:

1) Берётся демонизированный Тор

2) Берутся правильные настройки iptables

3) Берётся список из нескольких тысяч открытых прокси

4) Берётся Firefox и настраивается на работу через эти прокси

5) Берётся и легко обходится любая «блокировка Tor». Легко и совершенно незаметно

Можно сделать даже проще: взять Tor Browser, зайти на любой сайт с анонимайзером и вбить туда несчастную ссылку. Всё. Справятся даже домохозяйки.

Мы отлично знаем, что ни ping, ни nmap и прочее через тор работать не будет. Вообще. Заработает только безобидный httping. Так есть ли хоть одна реальная причина блокировать выходные узлы тора?

Лично я вижу только такие:

1) Ваш эффективный менеджер «знает» о Tor и начинает биться в припадке, осознавая, что ваш сайт можно смотреть через него. Вы его успокаиваете и получаете бутылку вкусного напитка

2) Вы очень старательно и эффективно имитируете бурную деятельность, напевая окружающим, что «справились с блокировкой того, обо что даже спецслужбы пообломали зубы».

3) Вам было ужасно лень, вы взяли всякие примочки от «антиспама» или какой-нибудь ipban и заблокировали с их помощью вообще всё, до чего дотянулись руки, ибо было лень проводить тонкую настройку.

4) Вы зарабатываете благодаря тонкому профилированию каждого, кто посещает ваш сайт. А потом продаёте данные рекламщикам.

5) Вы сами рекламщик, либо вам приплачивают гуглояндексы.

Как бы то ни было, ясно одно - блокировка Tor неэффективна, никак(вообще) не защищает от «злобных хакеров» и прочих неприятностей.

Так зачем же провоцировать людей, вынуждая их вам это доказывать?

Всех с прошедшими праздниками!

Решил я на новый год сменить DE. Почитал, что на Gentoo можно поставить GNOME без systemd, ну и решил поглядеть, как там дела в третьем гноме. Скомпилировал, установил, поставил ещё дополнительно wayland потыкать.

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

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

Тиринг этот очень странный - он выражен только ближе к самому верху экрана, ниже всё плавно. На wayland он выражен ощутимо слабее, но всё равно заметен. Соответственно, плавная прокрутка в firefox стала ужасно вырвиглазной, сломалось и воспроизведение видео, в т.ч. в разных плеерах. При этом окна перемещаются плавно и без разрывов, как и консольный vim и man.

Уже много часов подряд пытаюсь пробить решение, но ничего полезного найти так и не вышло. Взял несколько видео с 60 fps для тестов, вот недавно вернулся на fluxbox(оставив при этом gdm) и запустил их же - всё мигом прошло, хотя от многочасового повторения одних и теж же кадров у меня уже глюки пошли, да так, что иногда тиринг видится там, где его никогда и быть не могло.

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

Заранее спасибо за ответ.

Вновь приветствую всех.

В прошлой теме посоветовали копать в сторону pentoo для проверки безопасности сервера. Pentoo был подключен, дерево синхронизировано. Но попытка установки банального routersploit завершается со странной ошибкой:

# emerge -av routersploit
...
>>> Emerging (1 of 10) dev-python/bluepy-1.3.0::pentoo
 * Fetching files in the background.
 * To view fetch progress, run in another terminal:
 * tail -f /var/log/emerge-fetch.log
>>> Downloading 'https://gentoo.c3sl.ufpr.br/distfiles/bluepy-1.3.0.tar.gz'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   227  100   227    0     0    112      0  0:00:02  0:00:02 --:--:--   112
!!! Fetched file: bluepy-1.3.0.tar.gz VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got:      227
!!! Expected: 217933
Refetching... File renamed to '/usr/portage/distfiles/bluepy-1.3.0.tar.gz._checksum_failure_.pdwlxdvq'

Дальше он начинает перебирать зеркала, но эта ошибка затрагивает их все. С основой таких проблем было всего несколько, их было довольно легко обойти.

Поначалу пенял на VPN\proxy, к которым подключен всё время, но сброс всех настроек прокси и iptables ничего не дал. Не сбросил только автоматическое назначение прокси в консоли - вместо этого всегда сбрасываю вручную. Wget отлично достаёт все файлы с зеркал, то же самое можно сделать в firefox даже через VPN\proxy, а из FTP всё успешно скачивается с помощью MC.

Долго пытаюсь понять, в чём проблема, но неудачно. ЧЯДНТ? Понять не могу, почему такое происходит...

Заранее спасибо за ответы.

Привет лоровцам.

Вот уже некоторое время использую gentoo, недавно на ней же поднял сервер в локальной сети на одном из ПК. Нашпиговал SSH, SFTP, VPN, локальным DNS, апачем и прочим добром.

Всё это ныне светит мордой в глобальную сеть, пусть и через относительно неплохой роутер.

Доверять удаче не привык, а потому решил провести аудит безопасности, хоть бы скрипткидди отпугнуть. И тут у меня возникли проблемы... Но прежде, чем строчить репорты, я решил выяснить, работает ли оно у других тут.

К сути. Пытаюсь установить metasploit и получаю такой вывод:

~# emerge -av metasploit
These are the packages that would be merged, in order:

Calculating dependencies... done!

emerge: there are no ebuilds built with USE flags to satisfy ">=app-crypt/johntheripper-1.7.9-r1[-minimal]".
!!! One of the following packages is required to complete your request:
- app-crypt/johntheripper-1.8.0::gentoo (Missing IUSE: minimal)
(dependency required by "net-analyzer/metasploit-4.17.21-r5::gentoo" [ebuild])
(dependency required by "metasploit" [argument])

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

Если это не локальная проблема - репорт напишу, но спрошу: как это исправить-то, и возможно ли самому? Не хочу ради этого искать флешку и запускать другие дистрибутивы.

Привет, ЛОР. Не так давно собрал Gentoo на ноутбуке, флаги процессора подогнал, ядро оптимизировал насколько можно, но наслушался предупреждений от ветеранов(и даже на вики об этом сказано), что-де -O3 на всю систему лучше не ставить, как и флаги pgo, lto и graphite.

Но это, кажется, несколько устаревшие рекомендации. Знаю, что собирается так всегда дольше, но сам не пробовал. Копал поиск и наткнулся на вот это:

1) https://www.phoronix.com/scan.php?page=news_item&px=GentooLTO-28-Results 2) https://www.reddit.com/r/Gentoo/comments/8r8uqx/which_packages_are_worth_opti...

Вопрос к тем, кто пробовал гонять эти флаги: действительно ли -O3 толще -O2, и какой быстрее? Не ломает ли систему lto? Хочется протестировать их именно глобально, делая исключения для отдельных билдов, а не наоборот. Время терпит, но до Пн ноут должен быть боевой.

P.S на одном и том же железе генту потребляет где-то на 15% меньше памяти, чем арч. По скорости совсем чуть быстрее, на относительно современном оборудовании заметить тяжело. Разумеется, только при правильно подогнанном make.conf

Спасибо за советы.