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

Например:

>>> r = '(a+)*b'

Просто — да. Невинно — вроде да. Конечно неумно, потому что скобки и звездочка лишние, но должно работать. Попробуем:

>>> re.findall('(a+)*b', 'aaaaaab')
['aaaaaa']

Круто, работает, пошли пить пиво.

А нет…

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

Перехватить функции open, mmap и прочие невозможно, так как ld.so слинкован с библиотекой си статически, исполняемые файлы, загруженные же своим загрузчиком, «неполноценны» (даже с перехватом функций в libdl): они не регистрируются в списке загруженных библиотек и/или их символы не видны через dlsym. Следовательно, остается только перехват системных вызовов.

Несколько недель назад я объяснялся на Хабре в своей любви к электронным читалкам. Где-то в статье я упомянул свой небольшой сайт LiveKniga.Ru с рецензиями на прочитанные книги и был приятно удивлён тем, что многие заинтересовались этим сайтом даже больше, чем моими могучими аргументами в пользу читалок. :) Несмотря на то, что ссылка была незаметной и расположена под катом, трафика было много, и мне пришлось немного поволноваться за свой сервер. Слава богу, испытание хабраэффектом было с блеском выдержано, и я подумал, почему бы когда-нибудь не рассказать чуть подробнее об этом сайте (естественно, в соответствующем блоге). И вот сегодня «когда-нибудь» настало.

Помимо чисто маркетинговых целей, возможно, заурядная история этого сайта будет интересна тем, кто хочет запустить или лишь недавно запустил свой тематический блог. Никакой success story или назидательности не ждите — это cool story bro в чистом виде.

Изначально пост планировалось посвятить ошибке 64х-битового компилятора xlc которую я безуспешно отлавливал многие часы и которая имеет место быть на серверах фирмы IBM архитектуры AIX. Но так уж получилось, что подобная ошибка затрагивает многие компиляторы, не стал исключением и Visual Studio 2010 с установленным пакетом обновления SP1. Что в итоге кажется забавным, так как наводит на мысли, что специалисты Microsoft сотрудничают с разработчиками из IBM в деле создания оптимизирующих компиляторов.

Немного предыстории. Есть один научный проект, который был написан на С++ достаточно давно и сейчас успешно переносится на многие платформы, среди которых можно отметить мейнфреймы HP-UX, IBM AIX, Oracle Solaris. Перенос по большому счету состоит в том, что исправляются ошибки времени компиляции, запускается группа тестов и если все тесты проходят, то делается вывод о работоспособности кода.

Так как скорость выполнения математических процедур очень даже важна, компиляция проходит с включенным ключом оптимизации по скорости -O2. Но на архитектуре IBM AIX компилятор xlc почему-то не может создать работоспособный код, удовлетворяющий набору тестов. В то же время без ключа -O2 все работает нормально.

Я бы, конечно, мог попробовать отловить эту ошибку непосредственно на мейнфрейме IBM AIX, будь у меня в запасе достаточно времени, но за отсутствием отладчика (в debug mode ошибка не проявлялась) ловить приходилось по-старинке, методом вставки printf в участки кода. Удаленный доступ к IBM AIX мне так и не дали, приходилось работать непосредственно в дата-центре и за те несколько часов, проведенных за терминалом, ничего внятного понять не удалось, кроме того, что ошибка имеет место быть и достаточно устойчивая. В итоге, ошибка так и сидела в коде на протяжении долгого времени.

Так продолжалось до тех пор, пока я не попробовал перенести код на Visual Studio 2010 SP1.

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

Суть её очень проста: если хранить перечисления как сущности (@Entity), то с ними получается крайне неудобно работать, база данных нагружается лишними запросами даже несмотря на кэширование, а сами запросы к БД усложняются лишними JOIN'ами. Если же перечисление определять как enum, то с ними становится удобно работать, но возникает проблема синхронизации с базой данных и отслеживания ошибок таковой синхронизации.

Особенно актуально это в том случае, когда поле, содержащее перечисление, аннотировано как @Enumerated(EnumType.ORDINAL) — всё мгновенно ломается при смене порядка объявления значений. Если же мы храним значения в строковом виде — как @Enumerated(EnumType.STRING) — возникает проблема скорости доступа, так как индексы по строковым полям менее эффективны и занимают больше места. Более того, вне зависимости от способа хранения значения поля при отсутствии в базе данных таблицы со списком допустимых значений мы никак не защищены от некорректных или устаревших данных и, как следствие, проблем.

Однако сама идея хранения в базе данных заманчива простотой построения запросов вручную, очень ценной при отладке ПО или решении сложных ситуаций. Когда можно написать не просто SELECT id, title FROM product WHERE status = 5, а, скажем, SELECT id, title FROM product JOIN status ON status.id = product.status_id WHERE status.code = 'NEW' — это очень ценно. В том числе и тем, что мы всегда можем быть уверены в том, что status_id содержит корректное значение, если поставим FOREIGN KEY.

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

У меня в последнее время с завидной частотой спрашивают: «Как защитить данные, летающие между Flash Player и сервером?». Вместо ответа я предлагал прочитать любые книжки по криптографии, а от сильно наглых отбивался следующим кодом.

var myAge:Number = 23; //Ключ
var someTextToEncode:String = 'Sometext, or xml, or anything else'; //Текст для шифрования
var arr:Array = new Array();
var l:Number = someTextToEncode.length;
var encodedText:String = '';
for (var i:Number = 0; i< l; i++){
encodedText += String.fromCharCode(someTextToEncode.charCodeAt(i) + myAge); //Шифруем методом сдвига позиции кода символа. Просто и со вкусом. 90% "хакеров" на этом этапе уже отсеятся.
}
post(encodedText); //Метод, посылающий шифрованные данные на сервер

И от меня отвязывались, копипастя код. И всё у меня было хорошо, до тех пор, пока один из любопытных не спросил: «А как же защитить ключ? Ведь любую флешку можно утащить с сайта и декомпилировать!»

Способ, как оказалось, очень прост и не требует наличия никаких обфускаторов. Речь пойдёт о стендалон-флешках, скомпилированных одним файлом.

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

Введение

Основной целью на данном этапе было получение данных с MEMS гироскопа, подключенного к макетной плате по I2C шине. В этой статье мне хотелось бы рассказать, что получилось. Кому интересно прошу под кат(осторожно трафик).

С помощью @font-face вы можете загружать значки (иконки) не в виде PNG или GIF, а внедрить внутрь шрифта и подгрузить пользователю через директиву @font-face. CSS3 позволяет поворачивать такие значки, добавлять тени или даже анимированные эффекты с плавным изменением цвета при наведении курсора мыши (раньше такое было возможно только на Flash).

Вот здесь инструкция по использованию набора шрифтов IconPack (.eot, .woff, .ttf, .svg) и загрузке значков с помощью псевдо-элемента :before и тега span.

<style>  
.staricon {  
  font-family: 'IconPack';  
}  
.staricon:before {  
  content: 'a';  
}  
.show {  
  display:block;  
}  
.hide {  
  display:none;  
}  
</style>  
  
<div class="staricon">  
  <span class="show">star</span>  
</div>

Как известно, в большинстве европейских языков принято начертание текста слева направо, а у некоторых ближневосточных языков принято начертание текста справа налево. Если символ Юникода не является буквою алфавита (таковы знаки пунктуации и арабские цифры), то по умолчанию в браузере он принимает ориентацию предшествующего текста (например, появляется слева от текста, предшествующего ему в HTML-коде, если этот текст был семитским).

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

Традиционным средством такого экранирования является задание тексту соответствующего CSS-свойства (кодом <span style="unicode-bidi: isolate">…</span>). Однако это и долго записывать, и тег span (как известно) не семантический, да и браузерам всё ещё разрешено игнорировать CSS, если такова их настройка. Было бы лучше, кабы был специальный тег HTML для такого экранирования.

И такой тег действительно оказался введён WhatWG в подразделе 4.6.23 черновика стандарта HTML5.

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

Выглядело это примерно так:



html

<div class="large_button"><br>  <span class="buttons submit_v2-button clickable"><br>    <i class="left left2"></i><br>    <i class="body"><br>      <b>В архив</b><br>      <i class="end"><br>        <i></i><br>      </i><br>    </i><br>  </span><br></div>

Видно, что запутаться в таком коде проще простого, тем паче, что вариантов кнопок на проекте накопилось не менее 30. Попытка создать такую кнопку на серверной стороне вызывала негодование у коллег «пехапистов».

Поэтому моей негласной задачей стало максимальное упрощение кода.

В чём проблема?

Бывали ли у вас случаи, когда во время долгого заполнения нудной формы или написания красноречивого и пылкого комментария *внезапно* крашился браузер? Или вы закрывали вкладку, в которой работаете, или отключалось электропитание (а ИБП, по известному закону, нет)? Если нет — то вам повезло, но страховки от подобных происшествий ни у кого нет.

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

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

В данном статье я расскажу как интегрировать возможность просмотра карт для мобильных устройств на основе Android, на примере Yandex Карт и Google Maps.
Функционал библиотек этих компаний позволяет:

• Перемещать карту
• Изменять масштаб
• Изменять виды карт
• Получать события от карты

Начиная рабочий проект под Linux, я застрял в поисках С++ библиотеки, которая бы 1) была free, 2) умела работать с сокетами и можно быстро было поднять свой сервер, 3) нужна была оббёртка над потоками для плюсов. Сперва я наткнулся на Qt, но через некоторое время Qt стал слишком тяжелым для поставленной цели. В итоге поиски подтолкнули к cxxtools.

Кратко

Кратко о том, что умеет делать библиотечка:

• умеет работать с TCP сокетами и поднимать на их основе слушающий сервер;
• умеет парсить http запросы и отдавать ответы;
• умеет работать с SSL;
• реализован быстрый механизм сигналов (как раз похожий на Qt);
• имеется похожий на boost-овский, но более удобный шаблон Function / Method; необходим для callback-функционала
• умеет работать с потоками (threads): attached и detached threads;
• удобный шаблон пула (pool);
• гораздо удобнее smart pointer (ну имхо конечно), чем тот же std::smart_ptr и auto_ptr. Позволяет использовать разные политики управления классом и подсчёта ссылок, что удобно и необходимо для многопотоковых реализаций
• удобный механизм логирования
• ini-парсер

Сколько раз мне приходилось настраивать GC, чтобы вылечить приложение, у которого время от времени случается приступ, и оно перестает временно выполнять свои функции. Работа, скажу, не самая занимательная и требует хорошего знания матчасти. В данном топике я опишу какие еще есть способы решения данной проблемы.

Заметил я как-то, что на моём компьютере карты в WoT загружаются очень долго — больше минуты. Заходишь, бывает, в бой, а он уже секунд 30 идёт. А иногда вообще обнаруживаешь свой танк уже в виде горящих обломков. Компьютер мой, конечно, старенький и давно просит апгрейда, но вначале можно попытаться сделать что-то программным путём.

Начиная с версии 5.1 в MySQL появилась такая полезная фича как партиции. Конечно же большинство разработчиков БД сразу не побрезговали ей воспользоваться. Спустя пару лет работы я наконец пожал плоды всей ущербности реализации этой технологии специалистами MySQL AB …

Если вы запускаете новый сайт и заканчиваете его оформление, то есть смысл посмотреть коллекцию Subtle Patterns: отлично оформленную коллекцию фоновых текстур (паттернов) под лицензией Creative Commons Attribution 3.0 Unported. Их можно использовать без ограничений.

Сайт привлекает удобным предварительным просмотром: каждую текстуру можно мгновенно применить на всей странице в качестве фона. Сейчас там 93 работы, коллекция еженедельно пополняется отличными новинками.

Все текстуры на сайте Subtle Patterns являются повторяющимися, то есть склеиваются в бесшовную заливку.

Вчера я наконец-то выпустил первую публичную версию Lamer News, это одновременно и реальный пример использования Redis в виде сайта напободие Hacker News, и проект совершенно независимого сайта про новости из мира программирования.

Проект был хорошо принят сообществом, и был в топе HN в течение некоторого времени. Спасибо за обратную связь.

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

# Turn the password into an hashed one, using
# SHA1(salt|password).
def hash_password(password)
    Digest::SHA1.hexdigest(PasswordSalt+password)
end

Этот код использует SHA1 с солью. Как отметили читатели, это не самый безопасный выбор, поскольку есть способы вычислить SHA1 очень быстро. Через некоторое время люди хором начали твитить и писать в комментах одно и то же предложение: «используй BCrypt». Я предложил использовать вложенные SHA1 в цикле, чтобы избежать добавления новых зависимостей в коде (если вы проверите README, одной из целей является сделать код простым и с как можно меньшим количеством зависимостей). И тут это случилось: догма шифрования. Никаких рассуждений о криптопримитивах и их возможных применениях и комбинациях, просто тупо «используй BCrypt». В глазах этих товарищей программисты — просто тупые дроны, исполняющие гайдлайны, которые не могут ни в коем случае рассуждать о криптографии. Но об этом позже…

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

Поднявшаяся в этом топике дискуссия о криптостойкости многократного применения хеша над паролем (проскальзывавшая, кстати, и в других форумах), подтолкнула меня к этому немного математическому топику. Суть проблемы возникает из идеи многократной (1.000 и более раз) обработки пароля перед хранением каким-либо криптостойким алгоритмом (чаще всего хеш-функцией) с целью получить медленный алгоритм проверки, тем самым эффективно противостоящий brute force-у в случае перехвата или кражи злоумышленником этого значения. Как совершенно верно отметили хабрапользователи Scratch (автор первой статьи), mrThe и IlyaPodkopaev, идея не нова и ею пользуются разработчики оборудования Cisco, архиватора RAR и многие другие. Но, поскольку хеширование – операция сжимающая множество значений, возникает вполне закономерный вопрос – а не навредим ли мы стойкости системы? Попытка дать ответ на этот вопрос –