А теперь о Ruby и Redmine

[metaclass]

Я таки нашел, в чем причина вот этого бага:
no method error [] for class nil
https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/949011

Вкратце: недавно в большинстве реализаций хэш таблиц была найдена имманентная уязвимость к потенциальным DDOS атакам на веб-приложения, связанная с тем что атакующий мог посылать запросы такого вида, что внутри приложения они приводили к обращению к хэш-таблице всегда к одному bucket. Т.е. передавать ключи, которые после обработки hash-функцией всегда давали одно и то же значение, убивая эту таблицу из O(1) в O(N) и съедая тем самым процессор.

В руби это дело исправили:
https://launchpad.net/ubuntu/+source/ruby1.8/1.8.7.249-2ubuntu0.1
http://launchpadlibrarian.net/94639065/ruby1.8_1.8.7.249-2_1.8.7.249-2ubuntu0.1.diff.gz

конкретно эти строки:
++extern unsigned long rb_genrand_int32(void);
++
++void
++Init_st(void)
++{
++ hash_seed = rb_genrand_int32();
++}

+- register int key = 0;
++ register unsigned long key = hash_seed;

Формально, в норме бы ничего не поменялось, после этого.
НО: в редмайне оказалось место, где работа зависит от порядка элементов в хэше:
/usr/share/redmine/app/models/setting.rb,166
setting ||= new(:name => name, :value => @@available_settings[name]['default'])

тут происходит примерно такое: создается новый объект Setting и ему устанавливаются атрибуты name и value. И, это ключевой момент, установка атрибута value ЗАВИСИТ от наличия уже установленного атрибута name:

  def value=(v)
    v = v.to_yaml if v && @@available_settings[name]['serialized']
    write_attribute(:value, v.to_s)
  end

т.е. оно использует name чтобы получить значение по умолчанию из @@available_settings и далее пытается из него получить значение атрибута 'serialized'

Раньше это работало, а после секьюрити-фикса - работает в зависимости от rb_genrand_int32.

Так что ошибка, вообще говоря, в редмайне. Надеятся на порядок в хэш-таблице, это бред.

PS: а вот и фикс, месяц назад: http://www.redmine.org/projects/redmine/repository/revisions/8909/diff/trunk/app/models/setting.rb

Comments

[metaclass.livejournal.com]

Кстати в последнем редмайне исправили уже:
private
# Returns the Setting instance for the setting named name
# (record found in database or new record with default value)
def self.find_or_default(name)
name = name.to_s
raise "There's no setting named #{name}" unless @@available_settings.has_key?(name)
setting = find_by_name(name)
unless setting
setting = new(:name => name)
setting.value = @@available_settings[name]['default']
end
setting
end
end

[theiced.livejournal.com]

ну - и у людей с рвмом проблема решилась сама собой.

и мы ещё раз увидели что бабуинасты ничего не тестируют.

[avnik.livejournal.com]

Закладываться на порядок в хеше, супер чо. Очень агильненько.
и эти люди запрещают мне ковырять в носу.

[(Anonymous)]

В 1.9 порядок в хеше гарантируется, до этого разработчики были ССЗБ. Ну жабисты и прочие XMLщики ликуют, да.

[familom.livejournal.com]

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

[skif-by.livejournal.com]

Полный бред. Авторы редмайн укуренные.

[darkdrip.livejournal.com]

нужно использовать пыхыпышный mantis!

[inhate.livejournal.com]

Jira такой херней не страдает

[mr-s-o-u-l.livejournal.com]

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

[metaclass.livejournal.com]

ядро ок.
ломается после апдейта руби.

если сломается, прикрутишь фикс отсюда: http://www.redmine.org/projects/redmine/repository/revisions/8909/diff/trunk/app/models/setting.rb

:)

[mr-s-o-u-l.livejournal.com]

оу сенкс! тока я руби вроде тоже руками ставил, не из репозитория.Оно нихрена и не обновлялось :))
задача в принципе стояла не постоянно держать боевую проапдейеченную и пропатченную систему, а приучить дикарей пользоваться унитазом приобщить ограниченный контингент НИИ ГиТ к таск-менеджменту.

[dnnx.livejournal.com]

Немного ортогональный комент, но тоже про руби хэши.

Неоднократно сталкивался с тем, что в рубёвых гемах начинают валиться тесты при переходе с руби 1.8 на руби 1.9 только по той причине, что код основывается на порядке элементов в хэше. Кучу примеров видел и фиксил.

В 1.9 хэши стали сохранять порядок, в котором добавляются элементы. Такое изменение логично, потому что с теорией знакомы не все (пичаль-пичаль), а руби старается следовать принципу least surprise.

➜  ~  rvm use ruby-1.9.3-p125 && ruby -e "h = {}; h[:b]=2; h[:a]=1; p h"       
Using /home/dnnx/.rvm/gems/ruby-1.9.3-p125
{:b=>2, :a=>1}
➜  ~  rvm use ree-1.8.7-head && ruby -e "h = {}; h[:b]=2; h[:a]=1; p h" 
Using /home/dnnx/.rvm/gems/ree-1.8.7-head
{:a=>1, :b=>2}

[avnik.livejournal.com]

Равнение на идиотов -- это правильно.

PS Пока что из языков только питон предсказуем до тошноты, может луа еще (хотя там в стандартных библиотеках undefined поведение местами)

[x-a-e-p.livejournal.com]

питон пусть с таймзонами работать научится сначала нормально, ну и нифига он не предсказуем(например, изменения в 3.x по сравнению с 2.x).
lua да, весьма стабилен, хотя тут ещё все зависит от конкретной реализации

[theiced.livejournal.com]

ага, предсказуем. особенно когда кто нить где нить поставить один табик в исходниках. то то будет веселуха ;]

[mudasobwa.livejournal.com]

Хренассе least surprise.

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

[teewoon.livejournal.com]

А я чота всё больше смотрю в сторону chiliproject. Хотя там тоже не шоколадно. Полгода назад поломали древовидное отображение подтасков и родительских, обещают в следущем релизе поправить (к лету вроде), а пока что патч. Т.е. хотят - ломают, хотят - фишки прикручивают. Ну и в догонку - пачка core-девелоперов из редмайна ушла в chili, поэтому и там и сям случаются косяки.

[nivanych.livejournal.com]

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

[metaclass.livejournal.com]

В рубях, кложурах и прочих вебоориентированных лиспах хэш практически основная структура данных.

[aamonster.livejournal.com]

Блджад. Косяк, вообще говоря, и в ruby тоже: не должно быть итераторов по неупорядоченным коллекциям.

[metaclass.livejournal.com]

Да ну нахер, это же перечислимое множество очевидно.
А итератор никаких умолчаний на тему упорядоченности не предполагает вообще-то.

[mend0za.livejournal.com]

изумительный баг

[metaclass.livejournal.com]

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

[slonopotamus.livejournal.com]

Что характерно -аналогичная история была и с петоном, когда в очередном релизе dict'ы перестали быть упорядоченными (хотя они никогда порядка не обещали).

Метнем фекалий.

[livejournal.livejournal.com]

User inhate referenced to your post from Метнем фекалий. (http://inhate.livejournal.com/470287.html) saying: [...] траненное занятие. И судя по багу аффектящему алгоритмы работы основополагающих структур данных [...]