Русский
Русский
English
Статистика
Реклама

Открытое по

Переведут ли госсофт на open source технологии возможности для развития этого тренда в США

22.11.2020 00:21:34 | Автор: admin

Ранее мы подробно останавливались на том, как власти США планируют развивать IT-инфраструктуру и линии связи по всей стране обсуждали, почему этому процессу мешают действующие стандарты, методы сбора отчетности с интернет-провайдеров и низкая точность так называемых карт широкополосного доступа, построенных на ее основе. Несмотря на эти сложности, регуляторы и телеком-компании все активнее двигаются от слов к делу.

Unsplash / Ayrus HillUnsplash / Ayrus Hill

Развитие в кризис

В качестве мер противодействия Великой депрессии конца 1920-х первой половины 1930-х годов Франклин Рузвельт, ставший президентом на пике кризиса, принял новый курс, включавший множество законодательных актов и экономических инициатив. Наиболее заметные из них предусматривали строительство и ремонт шоссе, транспортной инфраструктуры, зданий общественных и государственных организаций по всей стране. Позже при участии Дуайта Эйзенхауэра из этих начинаний, вовремя задействовавших сотни тысяч безработных граждан, вырос знаменитый Interstate c межштатными автомагистралями, связавшими всю страну.

Модернизации сетевых коммуникаций скорее всего станет частью аналогичной большой антикризисной стройки, которая растянется на несколько десятилетий в США. Уже сейчас на нее планируют выделить до 1,5 миллиардов долларов.

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

Согласно отчету лаборатории инноваций Гарварда и специалистов некоммерческого консорциума развития Linux, особое внимание стоит уделить вопросам информационной безопасности и устаревшим программным компонентам, в том числе и открытым.

Двигатель всего нового

Есть мнение, что с помощью повышенного внимания и поддержки open source технологий можно не только сократить расходы на проприетарный софт со стороны государства, но и мощнейшим образом стимулировать развитие всей технологической отрасли. Такую оценку высказал представитель бизнес-школы Гарварда в научной статье с обзором результатов внедрения подобных мер во Франции. Там всего за год добились роста доли организаций, использующих открытые решения, с 0,6 до 5,4%; повысили занятость в сфере информационных технологий с 6,6 до 14% и отметили косвенные эффекты вроде увеличения числа IT-стартапов с 9 до 18%.

Если говорить о рентабельности инвестиций в open source, то только для Apache этот показатель составил более 17%, не говоря о возможных оценках общего вклада в ВВП (таблица 1, стр. 29) за счет массового внедрения подобных технологий.

Эксперты предлагают учитывать и развивать такое влияние за счет косвенной поддержки контрибьюторов например, предоставлять им налоговый вычет. Законопроект, содержащий данную меру, а именно вычет в размере 200 долларов за расходы на разработку open source решений, выдвигают в Ассамблее штата Нью-Йорк ежегодно, начиная с 2009 года.

Unsplash / Markus WinklerUnsplash / Markus Winkler

Но пока существенного прогресса по этому вопросу не наблюдается. Более того, неизвестно, включат ли что-то в этом роде в новый законопроект по масштабному развитию инфраструктуры.

Что выделяет сообщество

В обсуждении этой темы на Hacker News заметили, что Федеральное правительство США постепенно открывает миру разработки, выполненные по его заказу. Этим занимаются сразу несколько агентств вроде GSA (General Services Administration), специального подразделения исполнительного офиса президента под названием US Digital Service и даже DARPA.

Еще резиденты HN поделились репозиториями нескольких лабораторий: в Ок-Ридже, Ливерморе, Ричленде, Аргоннской национальной лаборатории рядом с Чикаго и еще одной в штате Айдахо. Плюс вспомнили про один из старейших open source фондов в Европе NLnet.

В качестве опасений они выделили возможные проблемы со сложной отчетностью и ограничениями на участие иностранных граждан, которые могут возникнуть, если власти США все-таки решатся на прямое финансирование открытых проектов. Во-вторых в треде несколько раз указали на то, что подобная поддержка часто заканчивается разработкой всевдостандартов, а не заметными для общества прикладными проектами. Из отраслей, где последние действительно пригодились бы, пользователи Hacker News отметили образовательную нишу.

Unsplash / Annie SprattUnsplash / Annie Spratt

Пока развитие открытых технологий по большей части поддерживают сами энтузиасты и компании, заинтересованные в их экспертизе. Увидим ли мы масштабную поддержку таких инициатив на уровне долгосрочных госпрограмм в США и других странах, покажет будущее.


Дополнительное чтение в нашем блоге на Хабре:


Подробнее..

Перевод Блеск и нищета open source платформы RawCMS. Причины провала и выводы

23.04.2021 18:05:42 | Автор: admin

Я люблю открытое ПО. Я начал разрабатывать сторонний проект с открытым исходным кодом в 2006 году, и это был секрет развития моей карьеры. Благодаря моим экспериментам того времени, надеюсь, я вырос как разработчик и возвращаю что-то сообществу Open Source. По-моему мнению, открытый исходный код это драйвер роста компаний и разработчиков. И сегодня я хочу рассказать о своём опыте начавшейся в 2018 году работы над платформой low-code с открытым исходным кодом под названием RawCMS.


Провал

RawCMS начиналась как сторонний проект по улучшению будущего Asp.net core 3.1 и изучению возможности работы с неструктурированными данными для ускорения процесса разработки.

Во время разработки я столкнулся со многими проблемами и, наконец, пришёл к работающему доказательству концепции. Результат был колоссальным, и я должен много раз поблагодарить всех его участников (а их более 20).

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

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

Считал и до сих пор считаю, что в определении продукта не было пробелов. RawCms стремилась сделать то, что действительно понадобится разработчику в будущем, но RawCMS было слишком сложно понять.

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

Вся эта сложность пугала разработчиков на подходе.

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

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

Окончательный вывод: для наших нужд мы выбрали худшую технологию.

Чтобы убедить человека внутри меня, который отказался от правды, я переосмыслил проект с самого начала. Используя Symfony вместо .Net, я потратил на работу чуть больше двух дней и получил работающее доказательство концепции. Я реализовал не весь набор функций, но почти уверен, что в новых обстоятельствах мы не обнаружим большое количество проблем. Это многому меня научило.

Как я смог за два дня сделать то же, что за два года?

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

Подходящий инструмент

Я не опоздал с .Net. Работаю с платформой с 2005 года, реализовал множество крупных корпоративных проектов, и меня приглашали на множество конференций, чтобы я поделился своим опытом.

Но я просто подобрал не тот инструмент для стороннего проекта. Я по-прежнему считаю, что .Net вероятно, лучший фреймворк для корпоративных приложений, а язык C# не имеет себе равных, с точки зрения производительности и впечатлений от разработки.

Проблема заключалась вот в чём: я выбрал .NET только потому, что это был фреймворк, в котором я чувствую себя более уверенно. Для меня выбор .Net был возможностью успеха. И я ошибался.

С тех пор как я начал этот проект, мне пришлось справляться с некоторыми функциями, которые .Net не поддерживает нативно; каждая отдельная проблема была преодолением.Я говорю об управлении нетипизированными данными (в частности маппинг и GraphQL), имея плагинную архитектуру и встраивая в неё модульный SPA.

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

Упорствовать вошибке от лукавого

Ошибки от человека, но упорство в ошибке от лукавого. Пытаясь заставить всё работать, я понял это на собственном опыте. Для меня это был важный урок.Сдаться перед огромной проблемой не всегда проявление слабости, а иногда, может быть, доказательство того, что вы умны. Я не остановился перед трудностями и победил зверя, но что потом?

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

Что я понял? Вместе нам никогда не приходилось сдаваться перед проблемой, но столкнувшись со сложностью один на один...

Спросите себя, в чём проблема в самой проблеме или в вас?

Ещё до кодинга расскажите, как видите продукт

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

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

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

Этого бы не произошло, если бы система была проще и была основана на популярном фреймворке, таком как Symphony, с сообществом, где разработчики смогли бы найти ответы на свои вопросы.

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

Выводы

Мне по-прежнему нравится вносить свой вклад в мир открытого исходного кода. Думая о потраченном на RawCMS времени, на самом деле я не чувствую, что оно вообще потеряно.

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

И вот какую пользу я извлёк из этого опыта:

  • Многое узнал о современных технологиях, что умножает мою ценность как профессионала.

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

  • Помог начинающим разработчикам сделать первый шаг.

  • Встретил много замечательных людей, которые, как и я, верят в дух открытого исходного кода.

  • Вернул что-то сообществу открытого ПО.

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

Но ценный опыт можно получить и проще, например прокачав себя в разработке на направлении C#-разработчик. На нём можно не только повысить свою квалификацию, но и пообщаться с опытными менторами, которые разъяснят непонятные моменты.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Как Европа переходит на открытое ПО для госучреждений

25.07.2020 20:08:39 | Автор: admin
Говорим об инициативах Мюнхена, Барселоны, а также CERN.


Фото Tim Mossholder Unsplash

Снова Мюнхен


В государственных учреждениях Мюнхена переход на open source начался более 15 лет назад. Считается, что толчком к этому стало прекращение поддержки сетевой операционной системы Windows NT 4.0. Тогда у города было два варианта: обновится до Windows XP или мигрировать на Linux. Группа активистов убедила мэра города Кристиана Удэ (Christian Ude), что второй вариант сэкономит 20 млн евро и имеет преимущество с точки зрения информационной безопасности.

В итоге Мюнхен начал разработку собственного дистрибутива LiMux.

LiMux это готовое к работе десктопное окружение с открытыми офисным ПО. Формат Open Document Format (ODF) стал стандартом для делопроизводства в городе.

Но переход на open source шел не так гладко, как планировалось. К 2013 году 80% компьютеров в администрации должны были работать с LiMux. Но на практике госучреждения использовали проприетарные и открытые решения одновременно из-за проблем с совместимостью. Несмотря на трудности, к этому времени на открытый дистрибутив перевели более 15 тыс. рабочих станций. Также были созданы 18 тыс. шаблонов документов LibreOffice. Будущее проекта выглядело радужным.

Все изменилось в 2014 году. Кристиан Удэ не стал участвовать в выборах на пост главы города, и на его место пришел Дитер Райтер (Dieter Reiter). В некоторых немецких СМИ его называли поклонником проприетарного ПО. Неудивительно, что в 2017 году власти решили отказаться от LiMux и полностью вернуться к продуктам известного вендора. С другой стороны, стоимость обратной миграции в пересчете на три года оценили в 50 млн евро. Президент Free Software Foundation Europe отметил, что решение Мюнхена парализует городскую администрацию, а госслужащие будут страдать.

Ползучий переворот


В 2020 году со сменой политических партий у власти картина вновь изменилась. Социал-демократы и зеленая партия заключили новое соглашение, направленное на развитие open source инициатив. Там, где это возможно, администрация города будет использовать свободное ПО.

Все кастомное программное обеспечение, разработанное для города, также будет передано в open source. Такой подход представители Free Software Foundation Europe продвигают еще с 2017 года. Тогда они развернули кампанию Общие деньги, общий код (Public Money, Public Code). Её цель сделать так, чтобы программное обеспечение, разработанное на средства налогоплательщиков, выпускалось под открытыми лицензиями.

Социал-демократы и зеленая партия будут находиться у власти до 2026 года. Можно ожидать, что до этого момента в Мюнхене точно будут придерживаться курса на открытые проекты.

И не только там


Мюнхен не единственный город в Европе, мигрирующий на open source. До 70% IT-бюджета Барселоны уходит на поддержку местных разработчиков и развитие открытых проектов. Многие из них внедряют не только по всей Испании, но и по всему миру например, платформу Sentilo Platform для анализа данных со счетчиков и датчиков погоды используют в городе Тарраса, а также Дубае и Японии.


Фото Eddi Aguirre Unsplash

В 2019 году на open source решили перейти в CERN. Представители лаборатории говорят, что новый проект позволит снизить зависимость от сторонних вендоров и даст больше контроля за обрабатываемыми данными. Организация уже внедряет открытые почтовые сервисы и системы VoIP-связи.

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

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



Больше материалов в корпоративном блоге:

Большая часть суперкомпьютеров работает под управлением Linux обсуждаем ситуацию
Вся история Linux. Часть I: с чего все началось
Участие в open source проектах может быть выгодным для компаний почему и что это дает
Бенчмарки для Linux-серверов


Подробнее..

Recovery mode Архитектура Y messenger

18.06.2020 12:21:50 | Автор: admin


Y messenger разрабатывается чтобы быть одновременно и защищенным на уровне Tox, BitMessage, и удобным на уровне Telegram и WhatsApp. В этой статье я опишу как выглядит архитектура и какие решения были использованы чтобы достичь поставленных целей.


Какие преимущества современных мессенджеров мы собрали в нашем продукте:


  • Общение
    • Отправка текста, фото, файлов, голосовых сообщений;
    • Отправка сообщений, защищенных сквозным шифрованием (включая фото и файлы);
    • Реализация диалогов, многопользовательских чатов и каналов;
    • Получение push-уведомлений о новых сообщениях;
    • Высокая скорость отправки сообщений;
    • Возможность отображения онлайна пользователей и индикации набора текста;
    • Иерархия ролей пользователей в групповых чатах и каналах;
  • Регистрация и авторизация пользователей:
    • Возможность анонимной регистрации без номера телефона / эл.почты;
    • Возможность регистрации по номеру телефона / почте;
    • Возможность скрыть персональные данные или ограничить видимость определенным группам;
    • Возможность просматривать список сессий пользователя;
    • Отсутствие жесткой привязки пользователя к серверу и возможность переноса данных пользователя между серверами;
  • Работа с пользователями:
    • Поиск пользователей по доступным данным (имя, почта, телефон);
    • Поиск пользователей по идентификатору;
    • Хранение списка контактов и групп контактов;
  • Администрирование:
    • Возможность разворачивания собственного сервера;
    • Автообновление серверного приложения;
    • Автоматическое создание резервных копий;
    • Настройка под местные требования (законов и внутренних политик владельцев);
    • Возможность настройки доступности шифрования для пользователей сервера;
    • Возможность просмотра незашифрованных диалогов администратором сервера;
    • Хранение статических файлов в облаке.

Сетевая архитектура


Взаимодействие всех участников сети мы строим на базе протокола WebSocket. Файлы передаются по протоколу HTTP. Описание протокола доступно в нашем репозитории на GitHub.


Цели и задачи


  • Создать децентрализированный мессенджер.
  • Обеспечить равенство участников децентрализрованной сети.
  • Обеспечить отказоустойчивость сбоям отдельных серверов.
  • Оптимизировать нагрузку на мобильные устройства пользователей.
  • Обеспечить защиту пользовательских данных.
  • Обеспечить возможность общения между пользователями разных серверов.
  • Минимизировать зависимость пользователей от других элементов сети
  • Обеспечить возможность реализации функций современных централизованных мессенджеров.

Решение


Мы рассматривали различные варианты и пришли к выводу, что сетевая архитектура, способная наилучшим образом удовлетворить всем требованиям "федерализированная децентрализация".


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


Схема связи хабов и пользователей


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


Аналогичную сетевую архитектуру образуют почтовые сервера (E-mail).


Хабы


Задачи хабов:


  1. Авторизация, регистрация и верификация пользователей.
  2. Хранение данных о пользователе (профиль, сообщения, контакты, настройки).
  3. Обеспечение передачи данных между пользователями.
  4. Предоставление информации о пользователе в соответствии с его настройками конфиденциальности.
  5. Маршрутизация запросов от других хабов и пользователей.
  6. Хранение файлов (у себя или в S3-совместимом хранилище).
  7. Поддержание распределенного хранилища Blockchain.
  8. Резервное копирование данных.
  9. Проксирование запросов между пользователей других хабов при сбое хаба, к которому они принадлежат.
  10. Администрирование своих пользователей.

Хаб может быть запущен кем угодно, подобно серверу электронной почты. Команда разработчиков Y messenger не имеет доступа к хабам пользователей и не может читать / записывать / изменять / удалять данные в этих хабах.


Прочие элементы сети


Помимо хабов и пользователей, в сети Y messenger существуют общие микросервисы (shared microservice), к которым обращаются хабы:


  • Push shared microservice микросервис push-уведомлений. Обеспечивает отправку уведомлений на устройства пользователей по распоряжению хаба пользователя. Защищает пользователей от отправки спама через Push-уведомления.
  • Balancer shared microservice микросервис балансировки сети. Обеспечивает целостность сети и является одним из источников информации о действующих хабах. Обеспечивает верификацию хабов и защиту от подделки запросов хаба при взаимодействии хаб <-> хаб и хаб <-> пользователь.

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


Архитектура хранилища данных


Цели и задачи


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

Решение


Для достижения всех поставленных целей нам приходится использовать комбинацию разных хранилищ. На клиенте локальная СУБД. На хабах классическая РСУБД, распределенный блокчейн и кэш для быстрой отдачи горячих данных.


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


Где что хранится


  • Данные пользователей. Хранятся на устройствах и на привязанном хабе. Хаб шифрует данные на своем ключе и отправляет в блокчейн. Другие хабы не получают доступа к информации о пользователе, они видят только привязку ID пользователя <-> ID хаба для маршрутизации.
  • Незащищенные личные сообщения. Хранятся на устройстве пользователя и в СУБД на хабах собеседников. В блокчейн не отправляются, т.к. блокчейн не приспособлен для обработки быстрых вставок, а ожидание синхронизации между хабами сделает доставку сообщений неприемлемо долгой. При общении между пользователями разных хабов сообщения хранятся на обоих хабах.
  • Приватные ключи пользователя. Хранятся только на устройствах клиентов. Могут передаваться между устройствами пользователя через хаб в зашифрованном виде (на ключах пользователя), поэтому передача через хаб безопасна.
  • Ключи оконечного шифрования. Хранятся на устройствах собеседников. Могут храниться в зашифрованном виде на хабе, но для расшифровки нужен приватный ключ пользователя.
  • Оконечно зашифрованные сообщения. Хранятся на устройствах пользователей. Опционально могут храниться в зашифрованном виде на хабе.
  • Информация о групповых чатах и каналах. Хранится на хабах всех участников. Отправляется в блокчейн хабом администратора в зашифрованном виде.
  • Сообщения групповых чатов и каналов. Хранятся на хабах всех участников. При подключении нового участника чата / канала, его хаб загружает последние сообщения и подгружает более старые по запросу пользователя. Поиск сообщений в групповом чате выполняет поиск только по локальной копии истории сообщений на хабе запросившего пользователя.
  • Список участников чата/канала. Хранится на хабах всех участников чатов. Отправляется в блокчейн хабом администратора в зашифрованном виде.
  • Контакты пользователя и группы контактов. Хранятся на устройстве. При необходимости могут храниться на хабе и синхронизироваться.

Шифрование


Компоненты шифрования реализованы на базе OpenSSL. В своей работе Y messenger использует следующие алгоритмы шифрования и подписи AES-CBC, RSA-OAEP, RSA-PSS. Эти алгоритмы реализованы в большом количестве криптопровайдеров, а следовательно, у желающих и/или не доверяющих есть больше шансов самостоятельно разобраться в функционировании системы или выпустить свой альтернативный клиент.


Ключи


Y messenger, как и многие другие решения, использует комбинацию симметричного и асимметричного шифрования. У каждого пользователя и хаба есть следующий набор ключей:


  • ключи подписи (публичные и приватные);
  • ключи шифрования (публичные и приватные);
  • ключи симметричного шифрования.

Количество пар ключей подписи и ключей шифрования, а также симметричных ключей ограничено только емкостью Int64.


В настоящее время Y messenger использует для асиметричной криптографии ключи, полученные из модуля длинной 8192 бита. Большинство продуктов в данный момент используют ключи на базе модуля 4096 бит, хотя известны случаи применения ключей на базе модуля 16384 бита и более. Мы решили, что 8192 бита будет достаточно. Дальнейшее увеличение длины критическое увеличение времени работы алгоритмов, что негативно сказывается на пользовательском опыте.


Хранение ключей


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


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


Мы используем парольную фразу длиной от 40 символов, на основе которой генерируется Master-Key, используемый для шифрования ключей. Приложение может хранить парольную фразу прямо на устройстве для удобства использования, но для достижения наивысшего уровня защиты рекомендуется вводить эту фразу при каждом входе в приложение.


Механизм не исключает возможность кражи ключей и парольной фразы, но делает этот процесс еще более сложным.


Сквозное шифрование


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


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


Как происходит обмен симметричными ключами:


  1. Alice хочет отправить Bob'у зашифрованное сообщение.
  2. Alice получает со своего хаба публичный ключ асимметричного шифрования Bob'а.
  3. Alice генерирует симметричный ключ.
  4. Alice шифрует симметричный ключ на публичном ключе Bob'а и подписывает своим приватным ключом подписи.
  5. Alice отправляет Bob'у сообщение, в которое вкладывает зашифрованный симметричный ключ.
  6. Следом Alice уже может отправлять оконечно зашифрованные сообщения, шифруя их на сгенерированном симметричном ключе.
  7. Bob получает сообщение с вложенным зашифрованным симметричным ключом.
  8. Bob проверяет подпись с помощью публичного ключа подписи Alice.
  9. Bob расшифровывает вложение на своем приватном ключе.
  10. Bob получает симметричный ключ и может с его помощью расшифровывать сообщения, полученные от Alice.

Таким образом достигается конфиденциальность передаваемой информации, а также ее целостность, авторство и неотказуемость от авторства. По подписи можно легко установить отправителя сообщения, а модификации приведут к ошибке при верификации сообщений.


Обмен ключами между устройствами


Современный мессенджер должен быть cross-device, чтобы пользователь мог начать переписку на одном устройстве и продолжить ее на другом. При использовании хабов, сделать cross-device нешифрованную переписку не составляет никакого труда. Реализовать cross-device зашифрованную переписку становится сложнее из-за того, что контент зашифрован, а ключи шифрования находятся на другом устройстве. Существует несколько способов решения (список не конечный, но достаточный):


  1. Использовать один симметричный ключ на всех устройствах.
  2. Расшифровывать сообщения на одном устройстве и передавать их через хаб в незащищенном виде.
  3. Перекинуть ключи шифрования между устройствами через хаб.
  4. Перекинуть ключи шифрования между устройствами напрямую.

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


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


Третий вариант оптимален, но требует внимания со стороны безопасности. Мы не можем доверять хабу свои симметричные ключи, поэтому их нужно защищать. В общих чертах, процесс обмена между устройствами A и B выглядит так:


  1. Пользователь начал переписку на устройстве A.
  2. Пользователь решил перейти на устройство B (с ПК на телефон).
  3. Устройство B авторизировано и имеет свой набор ключей асимметричного шифрования и подписи, которые уже отправлены на хаб.
  4. Устройство B отправляет на хаб сообщение с командой передать ключи, передает один из своих публичных ключей асимметричного шифрования, идентификатор ключа подписи, подписывая всю команду своим приватным ключом подписи.
  5. Хаб определяет все подключенные устройства пользователя и отправляет им команду подготовить ключи для передачи на устройство B и передает им данные из предыдущего этапа.
  6. Устройство A получает команду от хаба и проверяет что запрос был создан с устройства пользователя путем проверки подписи (запрашивает с хаба публичный ключ по переданному идентификатору).
  7. Устройство A генерирует одноразовый симметричный ключ, шифрует его на полученном публичном асимметричном ключе.
  8. Устройство A шифрует набор ключей на созданном симметричном ключе и подписывает данные (зашифрованный симметричный ключ, зашифрованный набор ключей устройства, идентификатор ключа подписи) своим приватным ключом подписи и отправляет на хаб.
  9. Хаб отправляет эту информацию на устройство B.
  10. Устройство B проверяет подпись и расшифровывает одноразовый симметричный ключ на своем приватном ключе шифрования.
  11. Устройство B расшифровывает набор ключей с помощью симметричного.

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


Остается вероятность что при "взломе" аккаунта и успешной авторизации, злоумышленник может быстро получить доступ к зашифрованной переписке. Решается либо ручным подтверждением пересылки ключей устройством А, либо временным недоверием устройству B (устройство А не доверяет устройству B пока пользователь не авторизует сессию на устройстве А).


Исходный код


Мы опубликовали исходный код наших разработок:


Подробнее..

Опенсорс на уровне компании первые уроки участия в сторонних проектах

10.02.2021 22:13:33 | Автор: admin
Автор: Денис Цыплаков, Solution-архитектор, DataArtАвтор: Денис Цыплаков, Solution-архитектор, DataArt

В мае 2020 года, когда процент коллег без проектов оказался неожиданно высоким, мы решили привлечь желающих к работе с опенсорс. У DataArt есть опыт создания собственных продуктов с открытым исходным кодом: IoT-платформа DeviceHive, .NET-фреймворк Atlas, игровая платформа Kiddo. Но контрибьютором сторонних проектов на уровне компании мы раньше не выступали, и сходу вкладывать в новую инициативу большие ресурсы не планировали. Скорее, хотели посмотреть, как это работает и для чего может пригодиться в будущем.

Один из авторов идеи Solution-архитектор Денис Цыплаков поделился несколькими наблюдениями, которые могут быть полезны всем, кто хотел бы создавать открытое ПО не только в свободное, но и в рабочее время, или дать такую возможность своим командам.

1. Опенсорс может работать на продвижение компании, но это дорого

Наверное, вы и так об этом догадываетесь, но я могу вас уверить, сославшись на собственный опыт: даже с сильными разработчиками быстро создать что-то заметное в опенсорс не получится. Поэтому не стоит рассчитывать на работу с открытым ПО в качестве инструмента продвижения компании на внешнем рынке, если собираетесь направлять на такие проекты только желающих из idle. Тем более, от случая к случаю.

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

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

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

2. Опенсорс не принесет мгновенного признания среди программистов

Двадцать лет назад, программируя на Delphi, я вполне мог за выходные написать библиотеку для логирования, которой люди действительно пользовались она была выложена на Torry. Сейчас для любых фреймворков придумано столько, что привлечь внимание можно, разве что играя на ограниченном поле самых современных и эксклюзивных технологий, угадывая тренды и привлекая значительные ресурсы вряд ли менее тысячи человеко-часов в год. Согласитесь, что сделать крутую фичу, скажем, для React за неделю силами тех, кто сейчас оказался в idle, не выйдет.

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

Собственно, у DataArt как раз есть опыт создания собственных опенсорс-продуктов, и они развивались по классическому для продуктовой разработки пути. Думаю, в конечном итоге их успех зависит от продакт оунера здесь всегда нужен харизматичный и энергичный человек, абсолютно уверенный в ценности разработки, которую он представляет. Людей, для которых не просто работа, но и сам продукт важная часть жизни в аутсорсинговых компаниях не бывает много.

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

Любой полезный вклад в открытое ПО делает мир чуть-чуть лучше, но все равно придется разобраться, для чего это нужно вашей компании. Только так можно определить направление усилий и объем ресурсов, доступный для вложения в опенсорс-проекты.

3. В крупнейших опенсорс-проектах всем хватит небольших задач

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

Допустим, в опенсорсной библиотеке при создании шаблона проекта с чем-то интерферировала и неправильно обрабатывалась одна из опций. Мы это быстро поправили силами двух джуниор-разработчиков. Событие не эпохальное, собственно, потому никто с этим вопросом раньше не разобрался. Но кому-то стало чуть комфортнее работать.

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

4. Подходящий репозиторий легко выбрать на глаз

Понятно, что отталкиваться проще всего от технологии. В нашем случае на момент высокого idle без проектов больше всего оказалось JavaScript-разработчиков, и первыми на наше предложение откликнулись двое из них. Дальше самое удобное просто взять топ-100 проектов с GitHub, отфильтровать их по нужной технологии и выбирать те, на которые отзывается ваше сердце. Внутри симпатичных вам проектов остается выбрать тикеты, отмеченные самими разработчиками как важные. И оценить хватит ли вам времени, чтобы наверняка справиться с описанной в них проблемой.

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

Репозиторий Angular можно считать образцовымРепозиторий Angular можно считать образцовым

В хорошо настроенном проекте с выбранной проблемой можно справиться часа за два. Мы знаем, как искать подходящий тикет, поэтому рекомендуем коллегам в DataArt, кто ненадолго оказался без проекта, написать нам. Мы подскажем, куда идти, вместе выберем задачу. Иногда поделать что-то руками может быть полезнее, чем на один день погружаться в неизвестный вам раздел теории.

5. Порог для входа в опенсорс существует, но он очень низкий

Если в проекте настроен нормальный воркфлоу, участвовать в нем легко. Однако для компаний это все-таки чуть сложнее, чем для индивидуальных разработчиков. Репозитории Angular, React и другие, сопоставимые с ними по масштабу, защищены специальным юридическим фреймворком. Пока ты не пытаешься сделать pull request, ты его даже не видишь, а для участия в проекте в свободное время из дома хватит и простой галочки да, согласен. Но если ты с ним столкнулся как сотрудник компании, потребуется подпись от аналогичного лигал-фреймворка твоей компании в этом нет ничего сложного, но и тривиальной эту задачу я бы не назвал. Если ваши коллеги раньше в рабочее время опенсорс не занимались, юристы могут удивиться.

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

CLA Contributor Licence Agreement лицензионное соглашение для компаний, которые хотят участвовать в опенсорс-проектахCLA Contributor Licence Agreement лицензионное соглашение для компаний, которые хотят участвовать в опенсорс-проектах

При этом есть и либы, в развитии которых участвовать вряд ли получится. Ими занимаются стабильные команды, готовые принять только по-настоящему гениальное предложение. Почему неплохо объясняют, например, здесь. Собственно, поэтому так важно внимательно посмотреть на репозиторий, прежде чем хвататься за интересный тикет. Вдруг никто и никогда не примет вашей работы будет жаль потраченного времени.

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

6. В опенсорс есть чему поучиться

Прежде всего, это касается джуниор-программистов и тех, кто очень давно работает исключительно в одном закрытом проекте. Сам процесс здесь может выглядеть достаточно поучительно, а объем и сложность всегда можно подобрать по силам конкретному человеку. Как ни странно, все, что нужно для участия умение достаточно аккуратно писать код. С остальным в хорошем проекте помогут: подскажут, например, не выпадает ли написанное вами из code style. К тому же, большие проекты делаются на основе лучших практик участвуя в них непосредственно, можно немного набить руку.

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

7. Не стоит спешить с обещаниями

Интересно, что в опенсорс обнаружились настоящие серийные контрибьюторы небольшие компании и самостоятельные разработчики, которые берут на себя очень много задач. Доходит до смешного: человек пишет, что решит проблему через несколько часов, но не возвращается к ней годами. Даже тревожно становится все ли с человеком в порядке.

Бывают и обратные ситуации, когда программист, отправивший pull request, может очень долго ждать пока его обновление примутБывают и обратные ситуации, когда программист, отправивший pull request, может очень долго ждать пока его обновление примут

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

В любом случае это примеры, едва ли достойные подражания. Мы посылали pull requests, только завершив задачу и проведя необходимые тесты. Надо сказать, что не отмечаясь заранее, вы снижаете уровень собственной ответственности. Если человек, который взял тикет, внезапно уходит в проект к клиенту или просто не справляется, вы никого не подвели свой опыт ваш коллега все равно получил.

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

Вместо заключения

  1. Опыт коммуникации с лучшими опенсорс-проектами очень полезен. Любой программист может сразу посмотреть, как поставлено дело в высшей лиге, и даже немного в ней поиграть.

  2. Участие в опенсорс однажды позволит ответить на вопрос о знакомстве с технологией Х: Вообще-то, я один из ее контрибьюторов.

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

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

Подробнее..

Перестройка IT-монополий, слом cookie-стен и открытый госсофт быстрое чтение в облачном TLDR

04.10.2020 16:16:23 | Автор: admin
Продолжаем делиться (раз, два) TL;DR-версиями постов из нашего блога. Здесь только главные моменты из каждой статьи, а ссылки на развернутые тексты есть в подзаголовках дайджеста.


Фото Guilherme Cunha CC BY-SA



Кто и почему хочет сделать интернет общим




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

Как минимум, так складывается ситуация в западных странах. Но кто знает, что произойдет в остальном мире, если события вокруг этого вопроса начнут стремительно разворачиваться в США или Европе, и захотят ли лидеры других стран взять опыт своих коллег на вооружение.

Главное, что привлекает внимание сторонников левых движений, взявшихся делить IT, это всем известные бренды-лидеры потребительских сегментов рынка: поиск, браузеры, офисное ПО, смартфоны и ecommerce. Они создают существенный объем рабочих мест, проводят масштабные исследования и практически все открывают приличную часть разработок, но даже с учетом столь положительного влияния вызывают все больше волнений у регуляторов.

Некоторые представители власти не ограничиваются вопросами ИБ и обсуждают тему неконтролируемого сбора персональных данных. Левые и леворадикальные движения на западе говорят о необходимости трансформации IT-компаний в кооперативы утилитарные структуры, которые не приносили бы сверхприбыль и воспринимались бы как сервисные организации из условной сферы ЖКХ. По их задумке, этот подход отобьет стимул к эксплуатации персональных данных в массовом порядке, снизит вероятность утечек и даже риски для нацбезопасности.

Что удивительно, движение в эту сторону уже идет. Многие государства внесли поправки о базовом праве граждан на доступ к сети, а Лейбористская партия Британии даже предложила сделать его условно бесплатным. Все эти планы могут быть оплачены с помощью новых налогов и сборов с интернет- и телеком-корпораций. Пока политики обсуждают планы, местные общины начинают разворачивать свои сети так поступили в штате Теннесси и южной Миннесоте.

Тема действительно интересная, варианты развития событий все активнее обсуждают, взять хотя бы наш тред с комментариями к этому материалу на Хабре рекомендуем изучить его.



Кто хочет сделать из ИТ-гигантов кооперативы





Пока представителей власти интересуют телеком-бизнес, национальная инфраструктура и вопросы сетевого нейтралитета, IT-компании сами выходят с предложениями о защите ПД. В силу известного скандала вокруг выборов президента США Марк Цукерберг вынужден чаще говорить о проблемах утечек данных, но сторонники левого движения подталкивают его и других руководителей крупного технологического бизнеса к постепенному дроблению организаций.

Социалисты считают, что управление такими блоками стоит делегировать демократически избранным представителям, которые могли бы действовать в интересах граждан. Такие примеры есть в формате кооператива уже работает служба такси Green Taxi в Денвере и маркетплейс Fairmondo, оперирующий на рынках Германии. Противники столь радикального пересмотра принципов регулирования IT-сектора высказывают описание о его излишней бюрократизации. Они считают, что конфликты политических партий могут помешать технологическому развитию общества.

Чтобы ознакомиться с деталями происходящего и взглянуть на проблему с разных точек зрения, предлагаем проанализировать все 199 комментариев под этим хабрапостом.



Почему Евросоюз искореняет cookie-стены




Кажется, что в какой-то момент появление GDPR было одним из центральных событий в новостной повестке. Но этот год заставил нас забыть о каких-либо сложностях с повсеместными cookie-стенами и баннерами. С другой стороны, развитие в этой области не остановилось. Ранее суд Европейского союза запретил предзаполненные чек-боксы, но оставил возможность не спрашивать разрешения для служебных вещей вроде поддержки сессий, плагинов и загрузки видеоконтента.

В свою очередь, в начале мая европейский регулятор признал, что cookie-стены могут нарушать GDPR, если такой баннер закрывает доступ к содержимому сайта и требует согласия с условиями сбора данных для продолжения просмотра. Комиссия по защите данных (European Data Protection Board, EDPB) пояснила, что это решение должно быть добровольным, а не вынужденным.

Пока власти прорабатывают рекомендации о том, как все-таки получать согласие пользователей на обработку ПД, аналитики бьют тревогу. Так, только 11,8% британских consent management platforms (CMPs) соответствуют требованиям GDPR, хотя их и используют десятки тысяч веб-сайтов.

Поможет ли им стать лучше очередное обновление законодательства, еще предстоит увидеть. Но одними только cookie-стенами дело не ограничивается, как быть с расплывчатыми формулировками в самих соглашениях о работе с персональными данными, пока неизвестно.

В заключительной части материала мы приводим примеры сервисов для блокировки нежелательных cookies и переходим к обсуждению мнений аудитории (в треде 77 комментариев хабражителей).



Как Европа переходит на открытое ПО для госучреждений




Мюнхенский вопрос висит в воздухе уже более 15 лет, но он совсем не о том, что мог бы себе представить любитель популярных новостных программ. Речь о переходе госсектора на open source и многомиллионной экономии для бюджета города. Когда активисты только занялись этим делом, городские власти пошли навстречу и запустили разработку дистрибутива LiMux и открытого офисного ПО, но по тем или иным причинам процесс увяз. Начались проблемы с совместимостью, пока открытые решение использовали параллельно с классическими пакетами, потом мэр отказался участвовать в новых выборах, а его сменщик и вовсе оказался фанатом проприетарного ПО.

В этом году социал-демократы и зеленая партия дали новую жизнь борьбе за открытый софт в рамках кампании Общие деньги, общий код. Не сложно догадаться, в чем ее суть. Кстати, в Барселоне open source внедряют с меньшими проблемами, а местные решения находят спрос в Дубае и Японии. Получится ли развить эту тему в Европе, нам еще предстоит увидеть.



Какие есть открытые ОС для сетевого оборудования




На открытом ПО для офисной работы дело не ограничивается. Крупные телеком-компании и вендоры продолжают поддерживать независимые разработки в области open source инфраструктуры и соответствующего софта. В материале мы рассказываем всего о паре таких проектов сетевом Сонике на Linux'е и Redis-движке, который начали использовать в ЦОДах самих проектировщиков системы, и открытом Linux-дистрибутиве, входящем в стек NOS (Network Operating System) из проекта SONiC. Если вы только-только разбираетесь в этой теме, начните погружение с нашей публикации.



Что еще есть у нас в блоге:

Участие в open source проектах может быть выгодным для компаний почему и что это дает
Вся история Linux. Часть I: с чего все началось
Вся история Linux. Часть II: корпоративные перипетии
История Linux. Часть III: новые рынки и старые враги
Бенчмарки для Linux-серверов



Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru