НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

Ужасы проприетарного программирования

Сергей Бобровский
04.03.2014 14:18:34

На помощь приходит Арнольд Шварценеггер.

В iOS найден серьезный баг, связанный с безопасностью, в реализации SSL/TLS.
Вот его подробный разбор: https://www.imperialviolet.org/2014/02/22/applebug.html

Код
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
   OSStatus        err;
   ...

   if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
      goto fail;
   if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
      goto fail;
      goto fail;
   if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
      goto fail;
   ...

fail:
   SSLFreeBuffer(&signedHashes);
   SSLFreeBuffer(&hashCtx);
   return err;
}


Как видно, ошибка в том, что программист, просто скопировав куски кода, забыл удалить один из операторов goto, который выполнялся всегда, и вторая проверка игнорировалась. В компаниях, где процессы разработки отлажены и доведены до промышленного качества, такого бага не должно быть по нескольким причинам: а) goto согласно классике структурного программирования вообще недопустим (в контексте исходников с багом -- абсолютно точно можно было обойтись без него); б) этот потенциальный баг легко ловится компилятором, который как минимум выдаст предупреждение (код с такой-то строки недостижим); в) проблему решило бы применение нормального текстового редактора для программистов с форматированием-подсветкой в сочетании с вечным методом пристального взгляда (инспекции кода, рекомендованные Институтом программной инженерии SEI при университете Карнеги-Меллона не один десяток лет назад). Как же тут Apple опозорилась, даже удивительно. Ну ладно бы задачка была второстепенной по важности.

Закончилась наконец и разборка дефекта в автомобилях Toyota Camrys и Corollas -- в 2009-м несколько человек погибли из-за залипания электронной педали газа, а сам дефект был выявлено массово, из-за чего были отозваны десятки тысяч машин. Оказалось, встроенный в машину софт, управлявший связью педали с двигателем, был написан ужасающе некачественно. Вот подробный разбор проблемы в суде от экспертов фирмы Barr Group:
http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf

Так, в коде оказалось 11 тысяч(!) глобальных переменных (которые вообще не рекомендуется использовать любой практикой программирования), а цикломатическая сложность кода (запутанность) зашкаливала за 50 баллов, то есть код фактически был нечитабельным. Более того, немало функций оказались рекурсивными! В обычных прикладных проектах с применением функциональных языков программирования, возможно, это и неплохо, однако в данном случае именно этот подход и привел к багу "Stack overflow causes unexpected acceleration" -- какой-то рекурсивной функции не хватило стека, который во встраиваемых системах-процессорах всегда сильно ограничен. Так, Motor Industry Software Reliability Association настоятельно не рекомендует применять рекурсию во встраиваемом софте автомобилей, а всего же она нашла в тойотовском коде 80 тысяч нарушений.

Возможно, эппловским и тойотовским кодировщикам больше подошел бы новый язык программирования ArnoldC (Arnold Schwarzenegger based programming language) https://github.com/lhartikk/ArnoldC
Тут два малозаметных goto подряд разместить сложно.

Код
IT'S SHOWTIME
TALK TO THE HAND "hello world"
YOU HAVE BEEN TERMINATED


А в качестве правильного девелоперского редактора можно порекомендовать свежак от GitHub -- Atom Editor для миллионов опенсорсных разработчиков: https://atom.io/

Фактически, кодировщикам "ведущих корпораций", которых мы подчас считаем чуть не "богами программирования", оказывается, очень и очень далеко даже до не самых идеальных участников опенсорсных проектов. Это впрочем объяснимо -- код проприетарный, заглянуть в него некому, а проджект-менеджеры обычно безграмотны и думают только о карьере, зарплате и пятнице. Поэтому можно лишь посоветовать им почаще учиться правильному кодированию на СПО-проектах -- например, только что выпущенном авиасимуляторе FlightGear v3.0 http://flightgear.org

Комментариев: 4

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

Donat Lipkovsky
05.03.2014 03:19:34

Сэр,
благодарю за предупреждение.
Я только что осознал весь кошмар нашего существования.
Не приведи господь купить ещё раз билет на самолёт или отправиться в круиз на белоснежном лайнере.
Москва разрослась, но ходить буду пешком.
Если куда подъехать срочно - только частники на жигулях.
А вообще пора подумать о отдалённой деревне.
Как мы, вообще, жили (точнее дожили) до сегодняшнего дня с этим ППО.
Кошмар.

PS У меня 43 игры в Steam и Origin. К утру надеюсь все снести. Буду играть FlightGear v3.0.

05.03.2014 07:41:53

Везде есть баги, никуда от них не денешся
А рекомендация на редактор с подсветкой синтаксиса выглядит смешно smile:-)
современные среды разработки давно ушли далеко вперёд

05.03.2014 11:49:43

То то и смешно, что IDE мощны как никогда, а эппловские кодеры делают детские ошибки. Баги есть конечно, так на то и тестеровщики))
Как минимум можно посомневаться, есть ли в Apple корпоративный стандарт на девлоперские фреймворки, на сам процесс кодирования, на технологии тестирования итд.

06.03.2014 06:13:35

Судя по коду тут труднопроверяемая "проверка на ошибки"
IDE тут мало чем поможет, а тесты написать будет ещё труднее (тесты по вашему без ошибок будут???)

Фактически тут проблемы самого языка, что он такое позволяет
Такое впечатление что С-линейка языков сделала всё что бы такое было как "за здрасте"

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии