Спустя полтора года с момента выхода прошлой версии вышел (http://www.proftpd.org) релиз ftp-сервера ProFTPD 1.3.4 в котором исправлено 219 ошибок и внесено несколько улучшений. Одновременно выпущен корректирующий релиз ProFTPD 1.3.3g в котором устранена уязвимость (http://secunia.com/advisories/46811/), которая может привести к выполнению кода злоумышленника на сервере через манипуляцию с пулом соединений при помощи команд xfer_stor и xfer_recv. Всем пользователям рекомендуется срочно обновить ProFTPD. Интересно, что в примечании к релизу ProFTPD 1.3.3g не упомянуто о наличии уязвимости, проблема помечена лишь как "ошибка, приводящая к повреждению памяти".
В настоящее время опубликована подробная инструкция (http://bugs.proftpd.org/show_bug.cgi?id=3711) с изложением принципа эксплуатации. Уже подготовлен рабочий эксплоит, который не опубликован (http://www.zerodayinitiative.com/advisories/upcoming/) публично. Пакеты с устранением уязвимости пока недоступны, проследить выход обновл...URL: http://www.proftpd.org/
Новость: https://www.opennet.ru/opennews/art.shtml?num=32272
То есть вчера вышедший Solaris 11, перешедший на ProFTPD, будет ещё месяц с дырой без обновлений ?
> То есть вчера вышедший Solaris 11, перешедший на ProFTPD, будет ещё месяц
> с дырой без обновлений ?Скорее всего не месяц а несколько месяцев - учитывая скорость латания дырок в солярке
> Скорее всего не месяц а несколько месяцев - учитывая скорость латания дырок в соляркеНу, хакеры тоже халяву любят же. Оракл заботится о них :))
>> Скорее всего не месяц а несколько месяцев - учитывая скорость латания дырок в солярке
> Ну, хакеры тоже халяву любят же. Оракл заботится о них :))Хотя бы один пруф достоверного взлома Соляры за период с 1983 года - в студию. Или балабол.
> Хотя бы один пруф достоверного взлома Соляры за период с 1983 года
> - в студию. Или балабол.Как минимум на покойном ныне milw0rm были сплойты/руткиты/прочий милый софт и для соляры.
>> Хотя бы один пруф достоверного взлома Соляры за период с 1983 года
>> - в студию. Или балабол.
> Как минимум на покойном ныне milw0rm были сплойты/руткиты/прочий милый софт и для
> соляры.Я сказал не линк на малварь, а пруфлинк на подтвержденный взлом продакшена. Пойди, возьми мой Солярис 10 с ежедневным апдейтом, поднятый по защите до B1. Ы?
Да что ты ведешься на этих трепачей. Они Солярис в телевизоре на Ютубе видали. Тут одни красноглазы.
> Пойди, возьми мой Солярис 10 с ежедневным апдейтом, поднятый по защите
> до B1. Ы?Факты упрямая вещь. Апдейт дыры к proftpd пришел ? Нет ! DoS в Apache запатчили почти через месяц после обнаружения. В разных libpng, libpango и libxml2 дыры вообще по три месяца латали, а все использующие данные библиотеки программы всё это время оставались уязвимыми. В недавно пришедшем апдейте Tomcat исправлена дыра годичной давности. Делайте выводы.
> Делайте выводы.Неуловимый Джо!
> Пойди, возьми мой Солярис 10 с ежедневным апдейтом, поднятый по защите до B1. Ы?Адрес mymegasolaris.local ?
> Пойди, возьми мой Солярис 10 с ежедневным апдейтом, поднятый по защите до B1. Ы?Вы кажется забыли сказать айпишник вашего соляриса, для начала. Кстати не хотите там поставить непатченый ProFTPD? Для более острых ощущений пониже спины? :)
Ух ты - у нас похоже эксперт в студии ... или балабол :)
Ибо как же ты пропустил эпический ping of death - который только на соляре и был?
Да дыр там было ну никак не меньше чем в других, просто ты как Ыкперт не в курсе :)
Да не ты чё, на винде ещё был :)
> Да не ты чё, на винде ещё был :)А теперь в винде udp packed of total kernel pwnage...
Ты б не трындел о чем не знаешь. Особенно если никогда не имел официального саппорта. Дырки в Солярке латают раз в два-три дня вот уже на протяжении последних 10 лет. Я его ежедневно использую, так что знаю - в отличие от тебя - скорость латания.
Вы только что прослушали рекламу компании Оракл :)
> То есть вчера вышедший Solaris 11, перешедший на ProFTPD, будет ещё месяц
> с дырой без обновлений ?Вменяемые соляристы не используют FTPD в соляре с тех пор, как в нее включен SSHD. Примерно с 2001 года.
Певец! :)
Там даже NIS не брезгуют юзать, а ты всё песни пляшешь :)
> Вменяемые соляристы не используют FTPD в соляре с тех пор, как в
> нее включен SSHD. Примерно с 2001 года.Интересно, много секретарш на ssh переучили? :)
ктото ещё использует не vsftpd?
Как правило хостинг-компании используют именно ProFTPd
> Как правило хостинг-компании используют именно ProFTPdИ по этому поводу хакеры теперь получат много халявных хостингов, ибо "может привести к выполнению кода злоумышленника".
Они всегда их имели. Видишь ли, недоумки-хостеры не знают о том, что SFTP изобрели уже о-очень давно. По меркам ИТ-мира - вечность назад.
> Они всегда их имели. Видишь ли, недоумки-хостеры не знают о том, что
> SFTP изобрели уже о-очень давно. По меркам ИТ-мира - вечность назад.А ssh хакерам тоже нравится, судя по наглости брутфорса оного ;)
А нехрен оставлять SSHD на 22м порту, чтобы скриптами ловился. Да и рут ремоутный в туннеле, разрешенный в некоих линаксах по дефолту - тоже. Ну и SSHD версии 4.7 в 2011м - тоже веселуха.
> А нехрен оставлять SSHD на 22м порту, чтобы скриптами ловился.Сие полезно только в плане снижения нагрузки на проц, которая при интенсивном брутфорсе может и не порадовать.
> Да и рут ремоутный в туннеле, разрешенный в некоих линаксах по дефолту - тоже.
Это где такое счастье?
> Ну и SSHD версии 4.7 в 2011м - тоже веселуха.
А это у кого?
> А нехрен оставлять SSHD на 22м портуспециально оставляю на 22-ом порту. и да, вход руту - ёк, вход по паролям - ёк. И да, sshguard на борту. А вообще конечно knockd хотелось бы привинтить - идея красивая.
> рут ремоутный в туннеле, разрешенный в некоих линаксах по дефолту -
o_O можно подробнее?
> тоже. Ну и SSHD версии 4.7 в 2011м - тоже веселуха.
O_o
это быдлоскрипты которые по словарику долбятся - "хакеры"?
Угу - зазеркаль какой нить debian repo по SFTP ... :)
Иди уже в дупу пионер, пока не сделают 0-crypt в ssh им все FTP-шные дырки заткнуть увы нельзя.PS: 0-crypt - это когда auth & so - в зашифрованном канале, а сам траффик - нет.
> а сам траффик - нет.В принципе, сам траффик тоже можно шифровать на скорости канала - каким-нибудь arcfour-like алгоритмом. Быстро работает. Но опенссшники до такого пока не доперли.
да, я использую pure-ftpd, а что?
> релиз ftp-сервера ProFTPD 1.3.4 в котором исправлено 219 ошибокНифига себе багов в всего лишь ftpd! 8[ ]
"helloworld.c: 11 errors, 19 warnings".
напиши чтоб меньше было
> напиши чтоб меньше былоFTP? В 2011 году? Вы еще UUCP попросите!
>> напиши чтоб меньше было
> FTP? В 2011 году? Вы еще UUCP попросите!Не поверишь - эти недоумки еще с десяток лет не будут пользовать SFTP, как "недостаточно зрелый". Они до сих пор - в 2011м - используют R-команды. Так шта.... UUCP там недалеко.
Пыонер. Иди в ... (С)Ф.РаневскаяВыше дали задачу - отзеркалить че нить типа Deban repo ч\з sftp.
Сделаешь и расскажешь. Если ты на IX-е каком нить - как раз через год закончишь.
Если (как водится) непризнанный гений из мухосранска ... ну и ладно, че-ж теперь.
> Выше дали задачу - отзеркалить че нить типа Deban repo ч\з sftp.Не, лучше не так.
Выше дали задачу: подмести ломом плац и покрасить траву в зеленый цвет, ибо ноябрь на дворе. Ведерко с зеленой краской получи у завхоза.
>> Выше дали задачу - отзеркалить че нить типа Deban repo ч\з sftp.
> Не, лучше не так.
> Выше дали задачу: подмести ломом плац и покрасить траву в зеленый цвет,
> ибо ноябрь на дворе. Ведерко с зеленой краской получи у завхоза.То есть - в сухом остатке после сброса всей словесной шелухи - НЕТ! нельзя взять и отказаться от ftp в пользу sftp. О чём вам и говорили. Так что пионеры всенепременно воспользуйтесь советом Ф.Раневской! :)
А, простите, причем тут IX? SFTP не увеличивает (точнее, увеличивает только маргинально) объемы трафика. Все, в чем проблема — упор в проц, из-за требований по шифрованию. Не более того.Невозможность зеркалить терабайты по SFTP никак не повод пользоваться FTP там, где этих терабайтов нет в помине. У типичного хостинг провайдера дается, в самом лучшем случае, пара десятков гигов. Вот нафига там FTP?
А, да, чуть не забыл. Привет пионерам, зеркалящим репу Дебиана по FTP. В нормальном мире зеркалят по rsync, а раздают по HTTP.
> А, да, чуть не забыл. Привет пионерам, зеркалящим репу Дебиана по FTP.
> В нормальном мире зеркалят по rsync, а раздают по HTTP.не пугай страусов.
Кстати, пару ошибок я указывать не стал, чтобы не расслаблялись :-)))))
> Кстати, пару ошибок я указывать не стал, чтобы не расслаблялись :-)))))Зато их указали в вашей любимой винде. Особенно доставляет MS11-083 - систему можно удаленно поиметь с правами ядра UDP пакетом. Epic failure/Эпическая неисправность.
void sqrtroot(double a,double b,double c,double &x1,double &x2)
{
double d=b*b-4*a*c;
if(d>=0)
{
x1=(-b+sqrt(d))/2*a;
x2=(-b-sqrt(d))/2*a;
}
}А теперь разберём все ошибки :).
1. "а" может быть 0, делить на 0 нельзя.
2. "х1" и "х2" могут быть NULL или ссылаться на недоступную память.
3. "а", "b" и "с" могут быть подобраны так, что операции над ними превысят предел точности double.
4. ситуация когда d<0 не обрабатывается, что чревато ошибками в других функциях. А теперь посмотрим на функцию sqrt, вы уверены что она не написана столь же "безграмотно", как и приведённая мной?Ну, кто возьмётся переписать код с исправлением ВСЕХ ошибок? Только, пожалуйста, не предлагайте решения через try...catch, если вы работаете на i7 с 10 Гб ОП, то не всем так повезло.
А затем увеличьте размер кода с приведённых 4 (всего лишь) до ~100.000 и сделайте выводы. Обратите внимание во сколько раз увеличитсяся размер кода если выполнять все проверки.
> 1. "а" может быть 0, делить на 0 нельзя."Да ладно, профессор!" (C)
В IEEE libm, ЕМНСКНИМС, для любого финитного a > 0 верно, что a/0 = Inf и -a/0 = -Inf.
Для а=0 a/0=NaN.
благодарим за демонстрацию, мы и так знаем, как написана винда. зачем сюда-то с этим лезть?
> благодарим за демонстрацию, мы и так знаем, как написана винда.Я вот даже пруфлинк накопал. Именно так и написана - см http://www.securitylab.ru/news/409632.php
Ну или что это за система где в ядро можно ремотно вломиться просто отправив "расово верный" UDP пакет?! Тут даже ProFTPD по лютости бага отдыхает.
> Ну или что это за система где в ядро можно ремотно вломиться
> просто отправив «расово верный» UDP пакет?! Тут даже ProFTPD по лютости
> бага отдыхает.на самом деле не всё так страшно, конечно. хотя забытое dereference — это забавно. как и вся концепция «заката солнца вручную» (то бишь, сборки мусора без помощи компилятора и рантайма).
Не вижу проблемы. Кто смотрел Затоичи помнит, как прикидывающийся слепым мужик 1,5 часа рубил козлов, а в конце фильма споткнулся о камень на пустой дороге и упал.Вообще ваша логика "дайте мне одну белую ворону и я докажу что чёрных не существует" мне кажется ошибочной.
А где здесь деление на a?
Я вижу только умножение суммы/2 на a.
> void sqrtroot(double a,double b,double c,double &x1,double &x2)
> {
> double d=b*b-4*a*c;
> if(d>=0)
> {
> x1=(-b+sqrt(d))/2*a;
> x2=(-b-sqrt(d))/2*a;
> }
> }
> А теперь разберём все ошибки :).Давайте сразу перейдём от никуда не годного к более правильному решению: http://ipg.h1.ru/lessons/ci/les31.html
> 1. "а" может быть 0, делить на 0 нельзя.
Не может — уравнение не будет квадратным, решение по приведённой функции бессмысленно.
> 2. "х1" и "х2" могут быть NULL или ссылаться на недоступную память.
Це-проблемы?
> 3. "а", "b" и "с" могут быть подобраны так, что операции над
> ними превысят предел точности double.Для вычислений, требующих точного результата, не используйте типы float и double. Правильный путь решения вычислительной задачи заключается в применении для расчётов типов BigDecimal, int или long © Джошуа Блох.
> 4. ситуация когда d<0 не обрабатывается, что чревато ошибками в других функциях.
Классический пример неучёта всех без исключения требований ТЗ и сути проблемы.
> А теперь посмотрим на функцию sqrt, вы уверены что она не
> написана столь же "безграмотно", как и приведённая мной?"Доверяй, но проверяй"?
> Ну, кто возьмётся переписать код с исправлением ВСЕХ ошибок? Только, пожалуйста, не
> предлагайте решения через try...catch, если вы работаете на i7 с 10
> Гб ОП, то не всем так повезло.А причём тут 10 Гб ОЗУ?
> А затем увеличьте размер кода с приведённых 4 (всего лишь) до ~100.000
> и сделайте выводы. Обратите внимание во сколько раз увеличитсяся размер кода
> если выполнять все проверки.А вы оставляете assert'ы в готовом коде?
> Давайте сразу перейдём от никуда не годного к более правильному решениюЦель: демонстрационный пример кода, содержащего ошибки. Какое "более правильное решение" ты мне предлагаешь?
> "а" может быть 0, делить на 0 нельзя
> уравнение не будет квадратным, решение по приведённой функции бессмысленноА функции как-то всё равно бессмысленно или осмысленно :). Будет ERROR.
Кстати, здесь была первая намерено допущенная "ошибка": нужно не "/2*а", а "/(2*а)". Её заметили, это хорошо, не всё ещё забыли квадратные уравнения.> "х1" и "х2" могут быть NULL или ссылаться на недоступную память.
> Це-проблемы?"Программа обратилась к недопустимой памяти и будет закрыта". Ничего не напоминает?
Здесь была вторая намерено допущенная "ошибка": "x1=..." - это присвоение указателю, чтобы обратиться по значению, указатель нужно разименовать. Я специально оставил ошибки чтобы показать что даже внешне корректно написанный код может содержать ошибки.> > 3. "а", "b" и "с" могут быть подобраны так, что операции над
> ними превысят предел точности double.
> Для вычислений, требующих точного результата, не используйте типы float и double. Правильный путь решения вычислительной задачи заключается в применении для расчётов типов BigDecimal, int или long © Джошуа Блох.Глупость написал. Ещё раз: значения могут быть подобраны так, что превысят предел точности типа данных. Неограниченных типов данных не бывает. К тому же, приведённые тобой типы целочисленные, а задача требует вычислений с плавающей точкой.
да хватит уже бугуртить. мы уже поняли, что новость про epic fail с upd-пакетами никак не может оставить тебя равнодушной.
> Давайте сразу перейдём от никуда не годного к более правильному решению:
> http://ipg.h1.ru/lessons/ci/les31.htmlПисец годное решение: #include <windows.h>
Портабельность консольной программы прибита на ровном месте. За такое расстреливать надо.
> А вы оставляете assert'ы в готовом коде?
Некоторые в сомнительных оставляют. Лучше если программа сразу упадет и баг будет локализован и починен, чем когда вместо падения сразу будет полчаса глюкания, потом все навернется, но баг никто никогда не обнаружит, потому что бэктрейсить на полчаса назад - нереально напрочь.
> void sqrtroot(double a,double b,double c,double &x1,double &x2)Если ты такой умный, тогда смотри сюда:
int i = 5;
i = ++i + ++i;Чему будет равно i после этого? В компилер не подсматривать, обоснуй вместо этого почему именно так.
Зависит от компилятора
Точно, ты прав. У меня на gcc получилось 13, а у соседа на том, который в vc - 14.
Это один из классических примеров неоднозначного кода. По-хорошему компилятор должен был выдать предупреждение (warning). То же самое проще: i+++j, что может быть как (i++)+j, так и i+(++j).Таким же примером является значение переменной цикла после его завершения, напр.: for(i=0;i<5;i++), после завершения значение i неоднозначно и не может быть использовано.
> Таким же примером является значение переменной цикла после его завершения, напр.: for(i=0;i<5;i++),
> после завершения значение i неоднозначно и не может быть использовано.лолшто? нет, может у вас в m$vc и это смогли поломать, но то исключительно интимные проблемы рабов m$. никто не виноват, что ваш компилятор очень плохо умеет компилировать C. а в C значение i после цикла очень даже однозначно и может быть использовано.
учи матчасть, студент.
Программный код должен быть переносимым. Поведение компиляторов не всегда соответствуют стандартам.
> Программный код должен быть переносимым. Поведение компиляторов не всегда соответствуют
> стандартам.я тебе страшный секрет открою: для переносимости стандарты и придумали. а если твой m$vc клал на стандарты болт — это не повод писать так, чтобы m$vc был доволен, а повод выкинуть m$vc на помойку.
Майкрософт не "мой", мир несовершенен, но я как разработчик вынужден заботиться о работоспособности кода. Моим заказчикам без разницы кто там чего не соблюдает, они платят за результат. Если вы "не в теме", зачем флудить?
> Если вы "не в теме", зачем флудить?Не, так не пойдет. Покажите место в стандарте где указано что на переменную после цикла полагаться нельзя. Это какое-то странное требование. Если я объявил переменную до цикла, цикл закруглился с ее значением 10 то на основании чего вдруг это значение 10 может быть потом потеряно? В упор не могу вспомнить куска стандарта который бы допускал столь неочевидную подставу. А вот что там и где для чьих багов и особенностей приходится закостылить - другой вопрос. Может, MS'у баг надо вообше написать? У них багов, особенно в последнее время - во всех продуктах легионы целые. Чтож теперь, баги в рамки стандарта чтоли возводить? Поэтому на веру да еще MS такое не принимается, извините.
Оно не будет потеряно, но если условие "for(i=0;i<10;i++)", то после исполнения i может быть равно 9 или 10, в зависимости от того выполнит ли компилятор финальный инкремент или соптимизирует код. Если нужна 100% увереность - доверять компилятору это нельзя. И не важно что написано в стандартах, за ошибки в моём написанном по стандартам коде рублём наказывают меня :).
> Оно не будет потеряно, но если условие «for(i=0;i<10;i++)», то после исполнения i
> может быть равно 9 или 10, в зависимости от того выполнит
> ли компилятор финальный инкремент или соптимизирует код.аааааааааа!
АААААААААААААААА!!!нет, а я ведь говорил, говорил, что оно стандарты даже в глаза не видело? говорил? вот вам, получите и распишитесь.
чудище, запомни: если в этом случае компилятор «соптимизирвал финальный инкремент» — это гуано, а не компилятор. ним даже «приветмир» нельзя собирать, а то наглючит. зачем ты пользуешься такими глючными компиляторами — не ясно. напиши вендору своего компилятора, что у них мегабаг.
любой адекватный компилятор, увидев, что значение i используется после цикла, бережно приведёт его в ожидаемый программистом вид. даже если он в цикле вообще эту i не использовал и цикл тупо развернул.
бедные, бедные рабы m$: мало того, что они жрут гуано, так они ещё и утверждают, что гуано жрать нормально, и что все остальные должны учитывать: m$ кормит людей гуано.
неа, что-то мне это жрать не хочется. я лучше возьму нормальный компилятор, который не ломает стандарты, потому что три индуса их ниасилили прочитать.
Много шума из ничего, и Майкрософт о котором не было ни слова.Данное поведение было в Watcom C, на счёт MSVC не уверен. Повторяю: предпочитаю не наступать на грабли, даже будуч полностью увереным что по носу они меня не ударят.
> предпочитаю не наступать на грабли, даже будуч полностью увереным что по
> носу они меня не ударят.шапочку из фольги и противометеоритный зонтик носишь? а если нет — то почему?
> Много шума из ничего, и Майкрософт о котором не было ни слова.
> Данное поведение было в Watcom C, на счёт MSVC не уверен.Звиздунчик. Watcom был почти лучшим по поддержке стандарта. Давай номер версии - у меня они все сохранились - я проверю.
есть подозрение, что оно собирало проект с какими-то опциями максимальной оптимизации, которые у многих компиляторов ломают стандарт вполне документировано. но как мы выяснили, документацию оно читать не любит, потому что многабукав.
> Данное поведение было в Watcom C,А у них много каких еще багов было. Мне теперь что, привыкать вообще все баги воркэраундить до самой смерти чтоли? А древние компилеры в архаичных *nix не поддерживают например C99. Мне что, не пользоваться им чтоли?
> Мне что, не пользоваться им чтоли?нет, конечно. писать как наш корреспондент — в машинном коде. а то всё остальное с багами.
> нет, конечно. писать как наш корреспондент — в машинном коде. а то
> всё остальное с багами.Можно подумать что в машинном коде багов не бывает. Баги делает программер, поэтому какой там язык - похрену. Единственная причина по которой на машинном коде меньше багов - он слишком геморроен и непонятен для рапидчиков и прочих дилетантов не понимающих как работают компьютеры.
> Можно подумать что в машинном коде багов не бывает.а какой у бедного ванюши-то выбор остаётся?
> эту i не использовал и цикл тупо развернул.Кстати нынче разворачивать циклы часто довольно тупая идея: чем жирнее код, тем меньше вероятность что он влезет в кеш проца. А латентность доступа к RAM в сравнении с кешом такова что проигрыш от непопадания в кеш на раз съест выигрыш от отсутствия закольцовывающих переходов. Мозилла по этому поводу пользует -Os в гцц. Так быстрее получается.
А портить значение переменной используемой далее оптимизацией, так что это повлияет на результат - выглядит как полное западло. Такое западло должно быть описано во всех мануалах жирным шрифтом на видном месте, если оно действительно есть и так и задумано в языке. Но я не припоминаю такого факта в упор.
> Кстати нынче разворачивать циклы часто довольно тупая идеяэто, в принципе, к теме беседы не относится. ну мало ли, может это цикл типа
for (i = 0; i < 10; ++i) array[i] = 0;
его вообще можно заменить на интринсик memset. но это ни в коем разе не повод забыть присвоить i десятку, если это i дальше используется.
> не повод забыть присвоить i десятку, если это i дальше используется.Похоже на откровенный баг оптимизатора, если честно.
> Похоже на откровенный баг оптимизатора, если честно.ну, лично я такого бага воочию не видел. на другие баги, правда, в gcc натыкался. с volatile, с длинной арифметикой на -Os, ещё на что-то. однако никогда не считал это причиной раз и навсегда в будущем впиливать в код для всех них workaround'ы.
>> Похоже на откровенный баг оптимизатора, если честно.
> ну, лично я такого бага воочию не видел.Я тоже. Господин утверждает что это на ваткоме. Ну то что у ваткома по жизни хватало багов вроде и не новость. А учтя что бобик сдох и его баги теперь мало кого волнуют... в свете этого идея воркэраундить до усера баги ваткома выглядит довольно странно.
> навсегда в будущем впиливать в код для всех них workaround'ы
Ну вот это то и смешно :))
> после завершения значение i неоднозначно и не может быть использовано.А это откуда следует? Что-то не припоминаю такого в стандартах.
>> после завершения значение i неоднозначно и не может быть использовано.
> А это откуда следует? Что-то не припоминаю такого в стандартах.оттуда, что в delphi так. ну, и в некоторых компиляторах цпп тоже. а стандарты он не читал, не барское это дело.
О каком из стандартнов языка С (или С++?) конкретно вы ведёте речь?
> О каком из стандартнов языка С (или С++?) конкретно вы ведёте речь?тебе-то какая разница, коли ты ни один не читал? O_O
> оттуда, что в delphi так. ну, и в некоторых компиляторах цпп тоже.Да мало ли что там в дельфи и некоторых компиляторах. Надеяться можно лишь на то что в стандартах прописано.
> а стандарты он не читал, не барское это дело.
Просто его заявление оказалось для меня сюрпризом. Я думал может он на стандарт осилит ткнуть, где такое это явно прописано.
8.80За бесплатно готовить аналитическую заметку по стандартам и их соблюдению я, разумеется, не стану.
> 8.80Это чего?
> За бесплатно готовить аналитическую заметку по стандартам и их соблюдению я, разумеется, не стану.
А, нормально, рассказать как оно у MS - можно и забесплатно, а как оно должно быть по стандарту - за денежку? На мыло таких "программистов".
MSVC и gcc - на этом ваши знания закончились? У меня их 5, и я не помню у кого какие грабли, я помню что они есть.
> MSVC и gcc — на этом ваши знания закончились? У меня их
> 5, и я не помню у кого какие грабли, я помню
> что они есть.дададада. «то ли он украл, то ли у него украли…» пиши багрепорт, бери починеную версию. с gcc я именно так и делал, например.
> Я думал может он на стандарт осилит ткнуть, где такое это явно прописано.есть подозрение, что он только что сочинил себе какой-то компилятор, который «может соптимизировать финальный инкремент», и теперь яростно сражается со своей фантазией.
> как (i++)+j, так и i+(++j).с какого испугу? у ++ больший приоритет, чем у +, поэтому оно будет съедено первым. ты и тут умудрился облажаться, бедняга. хотя я, конечно, допускаю, что на свете есть больные на голову авторы компиляторов, у которых разбор выражений сделан задом наперёд.
зыж это, если чо, особенность любого адекватного парзера.
Программный код должен быть переносимым. Поведение компиляторов не всегда соответствуют стандартам.
> Программный код должен быть переносимым. Поведение компиляторов не всегда соответствуют
> стандартам.https://www.opennet.ru/openforum/vsluhforumID3/81276.html#82
> Программный код должен быть переносимым. Поведение компиляторов не всегда соответствуют
> стандартам.В лично моем понимании если кто не соответствует устоявшемуся и общепринятому стандарту - так это называется БАГ и подлежит починке. Почему чужой баг должен быть моей проблемой мне как-то не очень очевидно.
> Почему чужой баг должен быть моей проблемой мне как-то не очень очевидно.Есть задача написать код, за это платят хорошие деньги. Компиляторо-независимый код (математическая библиотека без ассемблерных вставок), который должен компилироваться напр. в MSVC и GCC. Пишете по стандарту - результаты различны, разбираемся - первопричина в различном поведении компиляторов. И? Отказываемся от работы? Или засовываем стандарты и гордость за них в задницу и делаем чтобы работало?
> И?пишем багрепорт вендору компилятора, работающего неверно. в документации к библиотеке указываем, что в компиляторах ниже такой-то версии наличествует ошибка, и пользоваться ними не надо. если людям уж очень сильно хочется пользоваться компиляторами с багом — накидываем к цене, делаем workaround, в документации пишем, что workaround не поддерживается и в следующих версиях библиотеки может отсутствовать. если людям хочется, чтобы поддерживался… ну, ты понял? выставляем счёт за поддержку. для каждой новой версии. такие дела.
Итог твоей клоунады: требования ТЗ выполнены не в полном объёме со всеми вытекающими.
> Итог твоей клоунады: требования ТЗ выполнены не в полном объёме со всеми
> вытекающими.нет. итог моих дествий: внизапна! получил больше денег. итог твоих действий: за ту же сумму, что и в начале, ты имеешь немеряно радости обходить баги всяческих кривокомпиляторов.
я же не виноват, что у вас такие кривые ТЗ. мы вот ТЗ без согласования не принимаем. и согласовываем *долго*. именно для того, чтобы не жрать потом гуано. а ты продолжай, конечно, думать, что дополнительную работу надо делать бесплатно: таким, как вы, очень удобно скидывать занудные заказы. с клиента денег за доработку берёшь, а вам — шиш. мне это по нраву.
> Итог твоей клоунады: требования ТЗ выполнены не в полном объёме со всеми
> вытекающими.А что за ТЗ такое хитрое, что требует нахаляву воркэраундить чужие баги?! Кто мне оплатит время просраное на сношание с чужими багами???
> Кто мне оплатит время просраное на сношание с чужими багами???а это из разряда «солнце светит — негры пашут. солнце село — неграм включили электричество.»
> а это из разряда «солнце светит — негры пашут. солнце село —
> неграм включили электричество.»А, ну если кто хочет бесплатно воркэраундить баги в оптимизаторах всякой кривизны и полагает что так и надо - это его право, конечно. А я полагаю что стандарты не для красоты, а дрюкаться с глюками вообще всех экзотов и их воркэраундингом можно и подзадолбаться.
Стандарты не для красоты: http://mobile.opennet.ru/opennews/art.shtml?num=32287> пишем багрепорт вендору компилятора, работающего неверно. в документации к библиотеке указываем, что в компиляторах ниже такой-то версии наличествует ошибка, и пользоваться ними не надо. накидываем к цене, делаем workaround, в документации пишем, что workaround не поддерживается. итог моих дествий: внизапна! получил больше денег
При этом проблема заключалась лишь в том чтобы вместо "i+++j" написать "i+(++j)".
Линуксоиды, они такие линуксоиды...
> Стандарты не для красоты: http://mobile.opennet.ru/opennews/art.shtml?num=32287Это вообще к чему? Если уж говорить о стандартах то по идее BIOS должен выставить флаг что ASPM поддерживается. Если уж следовать букве стандартаю. Но как обычно, биосописатели на стандарты клали и реализуют свои глюко-биосы абы как.
Радует одно: кой-кого с таким подходом все-таки малость проучили, хотя-бы на поприщах документов и веба. Но я надеюсь что и остальным криворуким уродцам постепенно достанется на орехи.
>> пишем багрепорт вендору компилятора, работающего неверно. в документации к библиотеке
>> указываем, что в компиляторах ниже такой-то версии наличествует ошибка, и пользоваться
>> ними не надо. накидываем к цене, делаем workaround, в документации пишем, что
>> workaround не поддерживается. итог моих дествий: внизапна! получил больше денег
> При этом проблема заключалась лишь в том чтобы вместо "i+++j" написать "i+(++j)".
> Линуксоиды, они такие линуксоиды...Да, линуксоиды настолько зажрались что привыкли что можно написать апстриму баг и его, ВНЕЗАПНО, починят. Зачастую даже оперативно. Чего от проприетарщиков нифига не дождешься. А потом проприетарщики еще и удивляются - о, оказывается нас довольно много народа не любит?! А оказывается - есть за что. Практически все виденные мной проприетарщики очень плохо реагировали на багрепорты. А какого рожна я должен адаптироваться под чужие баги вместо того чтобы они их чинили, а? Это их работа а не моя!
>> как (i++)+j, так и i+(++j).
> с какого испугу? у ++ больший приоритет, чем у +, поэтому оно
> будет съедено первым. ты и тут умудрился облажаться, бедняга.:) Тут от кстати прав - а облажался - ты. Ибо у (i++) и (++j) приоритет одинаковый, так что implementation behavior - 100% :)
> :) Тут от кстати прав — а облажался — ты. Ибо у
> (i++) и (++j) приоритет одинаковый, так что implementation behavior — 100%
> :)а я и не говорил, что в этом случае я про стандарт речь веду. просто любой нормальный парзер обычно старается слопать токен максимального размера — так и писать проще, тащемта.
скажем так: да, тут он *может быть* прав, но такие извращённые парзеры ещё надо поискать. а вот что говорит по этому поводу стандарт я, честно говоря, не помню. кажется, там таки есть упоминание, что парзер должен быть жадный, но привести пруф я не готов.
>что может быть как (i++)+j, так и i+(++j).не может. "компилятор должон взять в лексему максимум.." т.е. (i++)+j и никак иначе
> Зависит от компилятораНе надо было ему подсказывать, мне было интересно что из себя представляет MS-студент, а вы всю малину обосрали :))
> Чему будет равно i после этого?6 + 7 = 13
Да, я сверился с компилятором.
>> Чему будет равно i после этого?
> 6 + 7 = 13
> Да, я сверился с компилятором.это лишь один из возможных ответов. а правильный ответ — undefined.
> 6 + 7 = 13Только в допущении что преинкремент более приорететен чем суммирование. Для си например такое допущение неверно, даже если иногда действительно так.
> Да, я сверился с компилятором.
Не, на самом деле это лишь частный случай. В данном случае порядок действий не определен стандартом и в зависимости от того какие действия будут отработаны первыми - результат может быть разный.
интересно (чисто академически), какой ёбнутый на голову вертухай удалил мой камент. и совершенно неакадемически интересно, за что. за то, что нихуя не знает си и не понял, что камент имеет ровно столько же смысла, сколько и вопрос? это прямо как в бебиане с криптографией: не знаем, а лезем править.
> интересно (чисто академически), какой ёбнутый на голову вертухай удалил мой камент.А мне интересно что там было написано. Господа модераторы, а может вы не будете стирать осмысленные и интересные комменты, но зато будете стирать хамливые и бессмысленные, а? Метете все без разбора, утомили.
там всего лишь было написано, что в результате i равняется куску зелёного сыра.
Мне кажется, что vsftpd по меньше дырок имеет.
vsftpd, pure-ftpd вполне гибкие и безопасные решения.зачем нужен вечно дырявый proftpd? в конце ноября и начале декабря прошлого года вообще подмена сорцов произошла, даже в портах freebsd. Хотя любителей наверняка много. Никода не использовал и не собираюсь.
> vsftpd, pure-ftpd вполне гибкие и безопасные решения.Ага, особенно pure-ftpd. Помнится, когда в нем нашли remote root дыру и по сети вовсю гулял сплойт, главный разработчик проекта даже не почесался что-то исправлять - тупо материл и банил всех, кто сообщал ему об уязвимости.
Что касается гибкости, то тут, извините, у proftpd конкурентов нет и не предвидится. Поэтому остается выбирать - либо гибкость (proftpd), либо безопасность (vsftpd).
> Что касается гибкости, то тут, извините, у proftpd конкурентов нетДа, гибкость обалденна! Он до кучи еще и средство удаленного администрирования оказывается :-]
> Ага, особенно pure-ftpd. Помнится, когда в нем нашли remote root дыру и
> по сети вовсю гулял сплойт, главный разработчик проекта даже не почесался
> что-то исправлять - тупо материл и банил всех, кто сообщал ему
> об уязвимости.Пруф или не было.
http://secunia.com/community/advisories/search/?search=pure-...
не вижу
> Пруф или не было.Во деграданты пошли! Оказывается набрать "pure-ftpd exploit" в поисковике - это уже слишком сложно. Ну вот например такой экспонат сходу нашелся: http://www.governmentsecurity.org/forum/topic/10150-remote-r.../
Выглядит как вполне себе боевой вариант эксплойта для раритетных версий pure-ftpd.
А как серверу proftpd указать интерфейсы, на которых ему разрешено слушать подключения?Мне надо разрешить слушать только локалку 192.168.0.0/16 (или весь местный интерфейс sk0, главное, чтоб инет не слушал).
Пока сделал
<Limit LOGIN>
Order allow,deny
Allow from 192.168.
Deny from all
</Limit>Но это ж не дело, он всё-равно слушает на всех интерфейсах, просто на левых интерфейсах отбивает соединения:
421 Service not available, remote server has closed connection.А надо чтоб вообще не слушал левые интерфейсы.
http://www.proftpd.org/docs/directives/linked/config_ref_Def...
а лучше - делайте уроки, Василий Степанович. рано вам еще FTP серверы поднимать.
>> Одновременно выпущен корректирующий релиз ProFTPD 1.3.3g в котором устранена уязвимость, которая может привести к выполнению кода злоумышленника на серверехехе. Это у профтпд уже традиция такая