там обычный PC под вендой. Откуда там «защита»? Может и реестр наружу торчит, я не буду удивлён, если это так. Другое дело, что сломать эту венду - ещё далеко не всё. Наверное можно снять тысяч 5, но крупные суммы не получится. А по мелочи - загребут, причём без всяких криптографий. Просто силами ментов.
С двойкой включается проверка переполнения буфера для операций а-ля strcpy. А переполнение буфера у нас это что ? Правильно, вектор для атаки. OpenCPN - прикладной софт, тут это не сильно важно, может быть, но пример показывает, что по-умолчанию стоит не двойка. Стало быть, важные компоненты тоже собираются без такой проверки, если мантейнер лично не позаботился.
В ALT это не отдано на откуп мантейнера, а введено централизованно. Так же, централизованно и давно, включены и некоторые другие фичи gcc. Причём, заметь, это ещё даже не ноу-хау альтовой сборочницы, это ни портировать не надо никуда, ничего. Просто надо махнуть шашкой и включить для всех (или надеяться на попадание в ALT и, как следствие, ремонт в апстриме, если апстрим вменяемый ;-) ). Да, какие-то пакеты, возможно, отвалятся, их придётся чинить, но польза очевидна. А есть ещё проверка зависимостей, более хитрая, чем по soname, есть всякие другие тесты.
непонятно, каким образом из плохособираемых под openSUSE сырцов вырастает божественность Альта
мне тоже это интересно. Ещё и слакварь приплели, хотя в слаке такого пакета вообще нет (openvnc), нет его даже на slackbuilds.org, а если собирать его как сказано в его же INSTALL, то он отлично собирается. При чём тут какой-то криворукий слакварщик, который не осилил?
А пакет mysql-5.5.29-x86_64-1.txz, и там такого нет.
Только не 5.5: 5.2.x самый новый.
Ну не знаю. Следы есть, значит, есть где-то, наверное. Я не знаю структуру каталогов репозитариев Слаквари, а изучать смысла не вижу сейчас. И, всё равно, в академическом смысле спора имеет смысл смотреть более ранний пакет, так как, где-то с 5.2.25 проблема была устранена. Интересно, было бы посмотреть, попадал ли в репозитарий 5.2.20, например.
С двойкой включается проверка переполнения буфера для операций а-ля strcpy. А переполнение буфера у нас это что ? Правильно, вектор для атаки. OpenCPN - прикладной софт, тут это не сильно важно, может быть, но пример показывает, что по-умолчанию стоит не двойка. Стало быть, важные компоненты тоже собираются без такой проверки, если мантейнер лично не позаботился.
дык такая проверка будет тормозить и тупить по чёрному. Если у тебя кривые руки, нафейхуяж ты на pure C пишешь? Питон в руки, и вперёд, там такие проверки искароппки, и не тормозят.
The patch certainly doesn't prevent all buffer overflows,
but should prevent many common ones.
With -D_FORTIFY_SOURCE=2 some more checking is added, but
some conforming programs might fail.
т.е. это конечно полезная и нужная фича, например для sshd или чего-то подобного, но довольно глупо применять её везде, где только можно. Впрочем, для школьников это непонятно. Если у школьника есть халявная железная дверь со сканером отпечатка пальца, то он её обязательно поставит в свой туалет.
В ALT это не отдано на откуп мантейнера, а введено централизованно.
ага. Ставим везде железные двери, и везде со сканером. А то, что обосрёшься, чем эту дверь откроешь - это мало кого волнует. Как и вопросы безопасности, кстати (ага - заживо сгореть в сортире только-лишь потому, что эта дверь не вовремя заклинило).
Да, какие-то пакеты, возможно, отвалятся, их придётся чинить, но польза очевидна.
для меня не очевидна.
А есть ещё проверка зависимостей, более хитрая, чем по soname, есть всякие другие тесты.
да-да. Для /bin/true это очень нужно. Как и для 99% остальных утилит.
Тут бы не помешала статистика, а не пара примеров.
Могу про модуль на CPAN рассказать с аналогичной проблемой (надо только вспомнить, какой), могу ссылку на OpenWRT найти. Специально статистику я не веду, а так можно, наверное, посмотреть ченьджлоги альтовых пакетов. И про переполнение буфера, и про as-needed, и про всякое другое, а, потом, сравнить с аналогичными версиями того же софта по другим дистрибутивам.
т.е. это конечно полезная и нужная фича, например для sshd или чего-то подобного
У меня есть уверенность, что это сделано в ALT. А вот сделано ли в Слаквари, у меня уверенности, теперь, нет. Хотя, если уж упомянули ssh, то тут есть совсем прикольный аргумент уже личностного свойства. И, тоже, в пользу ALT. ;-)
Ставим везде железные двери, и везде со сканером. А то, что обосрёшься, чем эту дверь откроешь
Клёвое сравнение. А, главное, верное. :-) Я так понимаю, других аргументов нет ?
Да, какие-то пакеты, возможно, отвалятся, их придётся чинить, но польза очевидна.
для меня не очевидна.
Понятно, школоло выбирает слакварь - там легче на качество кода наплевать. Ну выбирайте, что там. С такми подходом спорить не о чем.
это MySQL Workbench (GUI Tool), оно да, OSS только 5.2 доступно. Но оно слакварщикам и не нужно. Есть на slackbuilds.org, сейчас попробую собрать. Но к Патреку этот пакет отношения НЕ имеет. Так-то.
У меня есть уверенность, что это сделано в ALT. А вот сделано ли в Слаквари, у меня уверенности, теперь, нет.
с какими опциями компилировать код решает вообще-то автор кода, а не маинтейнер. Причина проста - бездумное и автоматическое применение даже самых хороших опций - плохая идея, и приводит к понижению надёжности и безопасности. Очевидно же!
Я так понимаю, других аргументов нет ?
у тебя вообще никаких аргументов в пользу применения -D_FORTIFY_SOURCE=2 для OpenCPN. Зачем оно для этих карт? Я вижу только один аргумент: «чтоб было», и вот теперь докажи, что ты не школьник.
Понятно, школоло выбирает слакварь - там легче на качество кода наплевать. Ну выбирайте, что там. С такми подходом спорить не о чем.
дяденька, тебя в школе разве не учили, что быдлокод останется быдлокодом, даже с -D_FORTIFY_SOURCE=2? Да ещё и собираться будет прекрасно.
С чего взял ? Это, как раз, пример, где компилятор может отловить ошибку ещё на этапе компиляции.
с какими опциями компилировать код решает вообще-то автор кода, а не маинтейнер.
Как всё запущено... Вот тут, как раз, с точностью до наоборот. Это любой гентушник докажет. :-)
Я вижу только один аргумент: «чтоб было»
А у тебя есть уверенность, что софт не грохнется при исполнении этого кода ? Причём вот что касается OpenCPN, если заметил, это не просто карты, это ПО для навигации. Бумажные лоции, конечно, никто не отменял, да и навигаторы нормальные тоже, но определённая ценность в бесперебойной работе у OpenCPN имеется.
что быдлокод останется быдлокодом, даже с -D_FORTIFY_SOURCE=2?
Ничего подобного. В правильной ситуации OpenCPN 3.2 собраться был не должен. А он у тебя собрался. Так что, попадание засчитано. :-)
я собирал не так, как Патрик (Пэт вообще не предоставил слакобилд), а так, как написано в файле INSTALL автора программы. Афтор программы дебил? Ну не я же именно эту программу раскопал как пример?
Почему я должен собирать программу с какими-то _твоими_ опциями?
Я про него и говорю всё время. OSS, в названии тарбола, поменяли на GPL в какой-то момент.
нет такого пакета в слаке. Успокойся. К чему ты претензии предъявляешь?
К нему отношение имеет система сборки пакетов.
пакеты в слаке собираются слакобилдами. А в слакобильде они собираются так, как указано в INSTALL программы, а не так, как захотелось какому-то школьнику.
Если у тебя не собирается - проблема в твоих руках или в руках разраба программы. При чём тут слакобилд? Да и где этот кривой слакобилд, дай хоть посмотреть.
С чего взял ? Это, как раз, пример, где компилятор может отловить ошибку ещё на этапе компиляции.
до твоих постов я думал - альтовцы адекватные люди. Теперь я уверен, что вы школьники. Вот смотри, у тебя не собирается OpenCPN, ты _уверен_, что это потому, что там - дыра, и программа РЕШЕТО. Адекватный человек отписался-бы на http://www.opencpn.org/flyspray/ (который почему-то сломался, что символизирует), а ты создаёшь посты на ЛОРе, с «школоло - патрег облажался, не заметил РЕШЕТА в opencpn!».
с какими опциями компилировать код решает вообще-то автор кода, а не маинтейнер.
Как всё запущено... Вот тут, как раз, с точностью до наоборот. Это любой гентушник докажет.
гентушники ССЗБ. Это у них не баг, а фича.
А у тебя есть уверенность, что софт не грохнется при исполнении этого кода ?
неа. Я вообще не в курсе, что это такое, и почему оно не нужно
что быдлокод останется быдлокодом, даже с -D_FORTIFY_SOURCE=2?
Но это уменьшает его количество.
будут собирать с 1, делов-то? Треккер у них сломался, писать некуда. Да у тебя и в мыслях нет это исправлять - тебе важнее твоё «школоло, как у нас всё круто!».
При том, что не обеспечена возможная дополнительная защита от плохого кода.
Адекватный человек отписался-бы на http://www.opencpn.org/flyspray/ (который почему-то сломался, что символизирует), а ты создаёшь посты на ЛОРе
Ты меня не знаешь, а делаешь какие-то непонятные и необоснованные выводы. :-) В отличие от тебя, я отписывался не раз и не два. И не десять даже. И до OpenCPN дело дойдёт, если я сочту этот софт интересным для себя, а проблема ещё останется. Баг с OpenCPN я только в последнее воскресенье обнаружил, смотреть и разбираться времени не было ещё.
При том, что не обеспечена возможная дополнительная защита от плохого кода.
никто не запрещает использовать свои опции.
Ты меня не знаешь, а делаешь какие-то непонятные и необоснованные выводы.
непонятные и необоснованные выводы делаешь как раз ты, опираясь не на факты, а на слухи и домыслы. Как ты говоришь «следы». Если у тебя есть информация о том, как Патрег проворонил какую-то дыру где-то — выкладывай, с интересом почитаю. А у тебя только «ололо».
Напомню ещё раз, что mysql workbench в слаке просто нет. Как нет и OpenCPN. Потому несколько непонятно, чем именно ты недоволен? Ведёшь себя как школьник - «а вот у Васи из пятого б было 3 двойки в году, и его не выкинули на мороз!»
Потому несколько непонятно, чем именно ты недоволен?
Тем, что у тебя собралось приложение, которое, вообще-то, не должно было собраться при должном контроле.
никто не запрещает использовать свои опции.
Ты же их не использовал сам почему-то ? Если бы использовал, не было бы вопросов. Тогда можно было бы утверждать, что у слакварщиков уровень разумности такой, что им контроль не требуется.
Потому несколько непонятно, чем именно ты недоволен?
Тем, что у тебя собралось приложение, которое, вообще-то, не должно было собраться при должном контроле.
о каком контроле ты говоришь, если я собирал как написано в INSTALL? У вас в альте такой метод сборки не собирает разве? А у нас другого тупо и нет. Нету слакобилда.
Ты же их не использовал сам почему-то ?
потому-что их не было в INSTALL.
у слакварщиков уровень разумности такой, что им контроль не требуется.
а мы просто всякую НЁХ в систему не тащим. В отличие от…
У вас в альте такой метод сборки не собирает разве?
Вообще-то, ни в одном дистрибутиве с нормальным пакетным менеджером так не принято. :-)
А у нас другого тупо и нет.
беда-беда... Обычно, формируют сценарий сборки пакета, по которой эта сборка происходит. По стандартам дистрибутива, а не отдельно взятого приложения со своими тараканами. В случае rpm-образных это spec-файл. При этом, при сборке, могут использоваться стандартные, для дистрибутива, макросы, тесты и т.п.
Весь вменяемый мир давно перешёл на контроль качества процесса, а не отдельно взятого результата. :-) Если что - это вообще, а не про софт.
Брать, и делать пакет. Потому, что если make install, то это будет не дистрибутив, а непонятно, что. Про всё, что поставлено мимо пакетного менеджера, он не знает, соответственно, сразу нарушается контроль зависимостей, и, неожиданно, можно получить всякие «ништяки» однажды.
Брать, и делать пакет. Потому, что если make install
а кто делал make install?
Про всё, что поставлено мимо пакетного менеджера, он не знает, соответственно, сразу нарушается контроль зависимостей, и, неожиданно, можно получить всякие «ништяки» однажды.
это ты в здешней wiki напиши. С примерами из своего дистра. Я из своего подкину. А мне об этом рассказывать не нужно.
Спор идёт о правильной сборке, а ты зачем-то критикуешь установку, которой я и не делал.
Спор идёт о правильной сборке, а ты зачем-то критикуешь установку, которой я и не делал.
Ну сборка-то делается, в конечном итоге, для установки, так ведь ? Потому, в конечном итоге, всё заворачивается в пакет, и тут всё и происходит. Просто вот именно обсуждаемый случай с OpenVPN - это даже не какой-то послесборочный ALT-специфичный тест, а использование параметров gcc, которые сделаны по умолчанию вот такими. Практика показывает, что среднестатистический человек ленив, и не будет делать что-то просто так. Так что, закручивание гаек на усмотрение собирающего лучше не оставлять, пусть он их лучше раскручивает сам, если с закрученными что-то пошло не так.
Если, в случае использования слакобилда, всё это задействуется само собой, ну, тогда, значит, я не прав. Если же про всякие FORTIFY_SOURCE, as-needed и т.п. надо помнить каждый раз, когда пакет готовишь, это не есть хорошо.
Ну сборка-то делается, в конечном итоге, для установки, так ведь ?
нет. Точнее да, но установка бывает разная. Часто программы ставятся в $HOME программиста, а не в систему. Или в /usr/local. Конечно, обычному пользователю этого-то и не нужно, но я и не про пользователя.
Практика показывает, что среднестатистический человек ленив, и не будет делать что-то просто так. Так что, закручивание гаек на усмотрение собирающего лучше не оставлять, пусть он их лучше раскручивает сам, если с закрученными что-то пошло не так.
среднестатистический пользователь и не должен пакеты собирать.
Если, в случае использования слакобилда, всё это задействуется само собой, ну, тогда, значит, я не прав. Если же про всякие FORTIFY_SOURCE, as-needed и т.п. надо помнить каждый раз, когда пакет готовишь, это не есть хорошо.
не надо конечно. Сборка идёт внутри слакобилда, и все параметры прописываются прямо в нём. И не пользователем, а создателем этого слакобилда. Типа как в генте, только в отличие от генты нет(почти) всяких юзфлагов, с помощью которых можно всем пакетам сразу задать какую-то опцию.
А что до пользователей слаки, то они пакеты ставят, уже собранные. Сборка пакетов в слаке == исключение. Можно и опции покурить иногда.
В здешней, не в здешней, но, вообще, вот тут есть немного:
вот тут НЕПРАВИЛЬНО написано. Вопрос «где» имеет второстепенное значение. Самое главное - «ОТ КОГО» эта программа. Если уж поставил alt, то и доверять должен команде alt, а не какому-то куску пластика, под названием «CD-ROM». Понятие дистрибутива не раскрыто, причём даже для составителя данной вики.
Про make тоже плохо написано - аффтору курить НЛП, про «негатив». Ну не поймут вас. Пусть собирают, пусть ставят. Если --prefix=/usr/local, то вреда от этого мало. Работать скорее всего не будет, ибо… Вот пусть и разбираются, если это им так интересно.
Зависимости autoconf таки проверяет, тут вы людей обманываете.
Не вижу главной рекомендации - не работать под рутом. Устанавливая программу в HOME юзер ничем не рискует, кроме своего HOME конечно. Что мешает сделать свой HOME для тестов? В отличие от венды, практически все программы в Linux «мобильные», т.е. их можно ставить куда угодно, под любым юзером. Глупо это не использовать.
Самое главное - «ОТ КОГО» эта программа. Если уж поставил alt, то и доверять должен команде alt, а не какому-то куску пластика, под названием «CD-ROM».
Вообще-то, там открытым текстом написано, в разделе «Почему нельзя ставить пакеты из других дистрибутивов».
Зависимости autoconf таки проверяет, тут вы людей обманываете.
Тут речь о межпакетных зависимостях. Сборочные, и для себя, он, конечно, проверяет. Но вот если это, вдруг, будет какое-то обновление для ПО, от которого зависит что-то ещё, эта зависимость не будет проконтролирована со всеми вытекающими.
Не вижу главной рекомендации - не работать под рутом.
А это, тоже, сделано на уровне взмаха шашкой: 1) вход под root в иксах не предусмотрен вообще; 2) попытка запуска иксов из рутовой консоли, если в init 3 рутом залогиниться, начинается с предупреждения «не надо так делать» (правда, ввиду п4, на английском); 3) rpmbuild работает только под юзером; 4) локаль у root - POSIX, что не добавляет комфорта обычному пользователю.
В общем, сама попытка что-то делать под рутом, вызывает у новичка кучу вопросов, это не так просто сделать. ;-)
Вообще-то, там открытым текстом написано, в разделе «Почему нельзя ставить пакеты из других дистрибутивов».
я (и 99% юзеров, если не все 100%) понимают это как «нельзя ставить пакеты с других сайтов, и с других CD». Понятие «дистрибутив» вы же не раскрыли? Вот.
Тут речь о межпакетных зависимостях. Сборочные, и для себя, он, конечно, проверяет. Но вот если это, вдруг, будет какое-то обновление для ПО, от которого зависит что-то ещё, эта зависимость не будет проконтролирована со всеми вытекающими.
это «восходящая» зависимость, и его должен проверять другой autoconf. Но это не важно, если ставим в /usr/local(не в /usr) - восходящую зависимость такой «пакет» не поломает. Другое ПО такой «пакет» тупо не заметит.
вход под root в иксах не предусмотрен вообще;
лечится sudo nautilus, sudo su, gksu, ksudo, да и ещё Over9000 костылей есть. И да, иксы, ЧСХ, работают от рута, и рута туда обычно таки пускают (хотя я против этого, но всем пофиг).
rpmbuild работает только под юзером;
не важно. rpm всё равно только под рутом.
локаль у root - POSIX, что не добавляет комфорта обычному пользователю.
можно подумать, запустить rm -rvf это кому-то помешает. Это как раз бред и вредительство, ибо под рутом работать(настраивать) НАДО, и если юзер забрёл туда, и увидел
ln x1 /tmp/x2
ln: failed to create hard link '/tmp/x2' => 'x1': Invalid cross-device link
то боюсь - не поймёт, особенно если англ. не родной и линуксы знает не очень хорошо. Даже для меня «не удалось создать жёсткую ссылку «/tmp/x2» => «x1»: Неверная ссылка между устройствами» понятнее.
В общем, сама попытка что-то делать под рутом, вызывает у новичка кучу вопросов, это не так просто сделать.
Вообще-то, это много где раскрыватся. У меня вот даже мысли не возникло, что это надо специально делать. Кроме того, косвенное раскрытие понятия и тут есть: «Поэтому даже в рамках ALT Linux, как правило, нельзя просто взять пакет из Sisyphus или 4.0 и установить его в дистрибутив на базе пятой платформы». Написано про «даже в рамках ALT Linux», так как может возникнуть мысль о вообще непонятном источнике ?
Но это не важно, если ставим в /usr/local
В общем-то да, но, часто, ставят и в /usr, не особенно думая. Про установку в /opt и $HOME там написано. /usr/local, правда, не обозначен.
лечится sudo nautilus, sudo su, gksu, ksudo, да и ещё Over9000 костылей есть.
А зачем ? Оно и от пользователя работает, а тут ещё sudo какое-то...
И да, иксы, ЧСХ, работают от рута, и рута туда обычно таки пускают
Я же написал - в ALT не пускают. Сделано специально.
Написано про «даже в рамках ALT Linux», так как может возникнуть мысль о вообще непонятном источнике ?
ну я же слаку с порносайта качал? Пока Патрегу не стуканули.
В общем-то да, но, часто, ставят и в /usr, не особенно думая. Про установку в /opt и $HOME там написано. /usr/local, правда, не обозначен.
а в README обычно таки /usr/local
А зачем ? Оно и от пользователя работает, а тут ещё sudo какое-то...
потому-что новички «лечат» проблемы с помощью sudo su.
Я же написал - в ALT не пускают. Сделано специально.
нельзя залогинится в X под именем рут. А вот _зайти_ можно. Т.е. можно запустить иксовую программу с правами рута. Чем народ активно и пользуется. А это - тоже самое.
На самом деле, неудобство пользователя - побочный эффект.
я в курсе. Сам Over9000 раз писал о том, какие дыры возникают из-за использования юникода… Меня даже с Эдуардом потому путают (хотя локаль у меня много лет UTF-8). Но тут дело-то в другом - следует разделять локаль рута, которую он по su - получает, с локалью, в которой работают системные демоны и скрипты. Это вообще говоря разные вещи.
Человек, по крайней мере, не забывает, что у него консолька рутовая. Ну или меньше шансов забыть.
Т.е. можно запустить иксовую программу с правами рута.
Сдуру можно и х сломать. Но, сам по себе, запуск через sudo, уже требует, хотябы, знаний про sudo. А про «не работать под рутом» написано на каждом заборе уже. Пока искать будут, 99%, что прочитают.
Но тут дело-то в другом - следует разделять локаль рута, которую он по su - получает
Как раз таки нет.
-, -l, --login Invoke the shell as a login shell.
Так что, по определению, положено делать аналог того, что получает root при прямом логине. Выставлять локаль отдельно для демонов, может, и интересная идея, но она таки чревата необходимостью использовать, даже при ручном запуске демонов, что-то, а-ля service, или какую другую запускалку. Кажется, это перебор уже.
Опять же, увидев непонятное, можно набрать LANG=ru_RU.KOI8-R ln x1 /tmp/x2
Или UTF-8. И, вообще, английский надо учить. :-)
Сдуру можно и х сломать. Но, сам по себе, запуск через sudo, уже требует, хотябы, знаний про sudo.
первая ссылка гугла подробно об этом расскажет. Я проверил.
Как раз таки нет.
Invoke the shell as a login shell.
ну. А вот демоны не регистрируются, не набирают логин и пароль. Они просто работают.
даже при ручном запуске демонов
ну бывают иногда некоторые неожиданности, когда в логах появляется «Чтв.» как день недели. Но это даже удобно - легко искать ручное вмешательство.
что-то, а-ля service, или какую другую запускалку. Кажется, это перебор уже.
если тебе _надо_ постоянно перезапускать какой-то сервис ручками - запускалка - годная идея.
Опять же, увидев непонятное, можно набрать
ага. Новичок и того не может прочитать, а ты его без ошибок ru_RU.KOI8-R просишь набрать.
Да и не работает это:
root@ksu:~# export LC_ALL=C
root@ksu:~# ln x x
ln: accessing 'x': No such file or directory
root@ksu:~# LANG=ru_RU.KOI8-R ln x x
ln: accessing 'x': No such file or directory
И, вообще, английский надо учить
это не ответ. Или в вашей вике это напишите в самом верху.
ага. Практика показывает, что любые негативные сообщения(а они все негативные), новичок считает костылями, которые ему такие как ты подкладывает, и решает вопрос с помощью рута. Почитай любой топик на убунтуру:
- у меня не работает это, пишет чё-то???
- попробуй с sudo
- спасибо, всё заработало! А скажите, почему звук пропал?
Другие форумы. :-) По крайней мере, sudo, без реальной необходимости, никто, как правило, не советует. А если советует, тут же находятся те, кто поправит.
не факт, что оно всегда и везде так работает.
Не факт. Но это уж смотря что ставил. Если не работает, надо дописать соответствующую локаль в %_install_langs в /etc/rpm/macros и переустановить, в данном случае, glibc-locales. Или вообще убрать install_langs, тогда все локали ставиться будут.