Pull to refresh
39
0
Alexey Galygin @MiF

User

Send message
Полностью согласен.
Вертоятностный метод лишь дополняет существующие тесты.

Просто ещё раз подчеркну, что нормальные тесты не позволили выявить проблем. Проблемы начались при неупорядоченном импорте файлов в словари.

Точно установить причину не удалось, а вероятностный тест помог не только найти проблему, но и минимизировать путь к воспроизводству ошибки. И устранить 4 наведённые проблемы, после исправления 1-й логической ошибки. Таким образом удалось исправить одну корневую и 4 наведённых ошибки во вспомогательных методах, в результате устранения 1-й. И причём весьма чёткие траектории получились.
Например выпадает ошибка на 1000-м проходе, сохраняем, прогоняем стресс тест ещё раз — выпадает на 249-м, не успокаеваемся и снова — 128, ну где-то в среднем от 100 итераций получается в этом случае.
Начинаем упрощать — выкидывать операции пока ошибка воспроизводится по журналу операций.
Удавалось сократить журнал до 10-20 операций.
Дальше в ход шёл двоичный анализ дампов с подтверждением целостности после каждой операции согласно документированному двоичному формату.
Удавалось найти артефакт и точку программы, которая воспроизвела на его.
Да, в примере разобранном выше состояние объекта было одно — он хранит определённый набор слов и важные операции для доступа дают совпадения с эталоном.

Дополнительные тесты пишутся для каждого компонента:
"… Разумеется на 1-м этапе придётся настроить подсистему контроля целостности, но потом всё пойдёт как по маслу..."

Для частного примера из статьи тест целостности был следующим:

if ([std count] != [sd wordsCount])
{   
 NSLog(@"Words count mismatch %u vs %u",(unsigned)[std count],[sd wordsCount]);
 status = 4;
}   
else
{   
 for (NSString * w in [std allKeys])
 {   
  NSString * entry = [sd lookupWord:w];
  NSString * stdEntry = [std objectForKey:w];
  if (![entry isEqualToString:stdEntry])
  {   
   NSLog(@"Entry mismatch for word '%@', expected '%@'",w,stdEntry);
   status = 5;
   break;
  }   
  unsigned wi = [sd indexForWord:w];
  if (wi == TIDNotFound)
  {   
   NSLog(@"Index-word error '%@'",w);
   status = 6;
   break;
  }   
  NSString * iw = [sd wordByIndex:wi];
  if (!iw)
  {   
   NSLog(@"Word-index error for index %u",wi);
   status = 7;
   break;
  }   
  if (![iw isEqualToString:w])
  {   
   NSLog(@"Mismatch '%@' vs '%@' at index %u",w,iw,wi);
   status = 8;
   break;
  }   
 }   
}


Пример конечно не сложный, для произвольного случая можно дать лишь общие рекомендации — как Вы и говорите — постараться пройтись по всем состояниям и произвести проверки. И постараться подобрать генераторы, которые прогонят систему по всем состояниям… Но это палка о двух концах — в погоне за всем и при излишней детерминированности входных параметров могут появиться случайные ограничения и мы попадём в иной класс ошибок. Вероятностная система очень чувствительна к входным параметрам. Оставляя место полному хаусу мы можем получить неожиданные результаты, а при попытке что-то фиксировать — мы теряем потеряем возможность что-то измерить — аналогия с принципом неопределённости Гейзенберга.
именно за проверку изменённого внутреннего состояния и отвечает проверка целостности:
"… а также проверяем дополнительными тестами целостность состояния компонента C..."
логика простая — если Хаос породил ошибки
то сам же Хаос и поможет их обнаружить.
клин клином.
спасибо, ссылка интересная, анализ приведён подробный
Итак, резюмирую укороченное решение шифрования-дешифрования с возможностью производить diff:
Вместо Perl-скриптов и для работы diff в определении фильтра прописываем:

[filter "private"]
clean = openssl enc -rc5 -k SecurePassword -nosalt
smudge = openssl enc -d -rc5 -k SecurePassword -nosalt
[diff "private"]
textconv = cat


Для нужных файлов в .gitattributes:

*.h filter=private diff=private

При модификации .gitattributes на стороне клиента после клонирования, достаточно выполнить git stash для применения новых настроек фильтра smudge. Чтобы не было недоразумений, не забудьте добавить .gitattributes в хранилище.
На самом деле можно.
Только не нужно ставить в директории не принадлежащие Вашему пользователю (например, в /usr, /usr/local).
Просто переопределите prefix при configure.
Не скажу по поводу «заморачиваться», но лично я за практику — попробовать стоит по любому.
Из моего опыта — удачно удалось развернуть Git на 301-м тарифе РуЦентра — там в SSH даже gcc есть — сначала собрал nginx, потом git, svn там из коробки идёт.
К счастью, в конкретный текущий момент времени один. Сразу после использования файл удаляется. Но использование tmp в home поддерживаю всё равно.
И как тут уже отмечалось, Perl скрипты остались от иследования фильтров.
Можно, действительно, обойтись openssl в одну строку без обёртки и без временных файлов.
Доверие доверием, а подстраховаться никогда не повредит.
Дополнительное шифрование — это второй уровень защиты.
К примеру, Вы платите за хостинг и размещаете там репозиторий.
Насколько Вы доверяете хостеру и местным специалистам, который день и ночь шныряют по SSH?
Это как замки в квартире — Вы можете их и вовсе не ставить, но тогда…
А когда Вы их ставите, разве Вы живёте не в скомпроментированном мире?
По поводу /tmp — предполагается, что это Ваша машина (клиент).
Иначе и редактировать файлы на ней не стоит.
Если Вы про метод кодов с картинки,
то это перехват/выуживание одного пароля
против
кучи из одноразового блокнота без возможности предсказать следующий.
Расшифрованными они будут только если установлены фильтры,
внутри хранилища они лежат в виде двоичного мусора даже на клиенте у которого в рабочей копии открытый файл.
Иначе получите двоичный закодированный файл.
Вопрос в том, где этот диск будет смонтирован (возможности TrueCrypt). Допустим, 100 разных человек в разных точках земли, смогут ли смонтировать этот диск и работать с репозиторием, так чтобы целостность данных была в порядке?
Ограничения этого метода:
1. Если внутри одной организации — то можно конечно расшарить один смонтированный диск между сотрудниками.
2. На GitHub такое не пройдёт
3. Возможна физическая порча репозитория (он уже не сокрыт за сервером, а вот он как локальный)
Может быть. Процесс эксперимента с фильтрами не сразу привёл к результату. Мне удобнее писать Perl-скрипты, вместо SH-скриптов, поэтому получилось именно так.
Да, это подойдёт для сокрытия всего. Но тогда хранилище уже не будет на сервере представлено в виде Bare-репозитория (тогда в этом уже нет смысла).
Смысл скрыть именно несколько файлов и при этом оставить штатный доступ к Git.
Если образ диска разместить на сервере — то сколько человек сможет с ним работать одновременно?
Лично я использовал FUSE + SSHFS и монтировал AES-тома через SSH. Но пока диск у меня, остальные не могут с ним работать безопасно — это плохо кончится. TrueCrypt свободен от этой проблемы?
Проверил штатный git diff,
к сожалению да, как двоичные файлы, но, возможно, это можно обойти дополнительными фильтрами.
В крайнем случае, можно получить копии открытых (расшифрованных) версий файлов и сравнить их в индивидуальном порядке.
Смысл метода скрыть не всё, а только что-то ну очень секретное.
Вы действительно думаете, что это неудивительно?
Софт исключительно внутреннего использования по определению не должен выкладываться в публичный доступ.
Я показал лишь дверь, каждый должен сам для себя решить как в неё войти.
Сложно подобрать ключ к двери, которую не было даже видно.
Это не вопрос о толке, а лишь вопрос необходимости. Мне за несколько лет потёмок и неведения относительно того, чем же Apple обслуживает протокол rdar://… (см. пример подобных вопросов: bit.ly/bsuLRA), удалось только вчера случайно (!) отыскать лишь эту крупицу информации. И никто из моих друзей программистов в разных странах, говорящих на разных языках, за многие годы не смог ничего сказать. Все пожимали плечами и говорили, что и сами бы не против хотя бы знать с чем это едят… или краем глаза посмотреть на софт.
Поэтому, эта находка софта на пару сотен мегабайт — это уже не просто крупица — это сразу булыжник сегодняшнего дня.
Формально, если бы Вам удалось найти подходящий туда логин-пароль — ёлочка бы заиграла разноцветными огнями… Но это как бы незаконно.
Что именно устарело? Что из этого Вы видели когда-либо раньше?
Radar, Sonar и NFA — всё это не для публичных глаз. Все продукты обновляются и имеют почти актуальные на сегодняшний день версии (за исключением последнего обновления).
В интернете про это вообще нет информации (даже англоязычной).
Можете считать этот хабртопик первым, единственным и возможно последним по этой тематике.
1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity