Ну, не знаю. Мало того, что не нативное решение с соответствующими проблемами в поддержке при сколько-нибудь массовом внедрении, так и профит от него мне лично не очень ясен.
Чем пароль на keepass db отличается от пароля на id_rsa? А keeagent от ssh-agent'а? Если хочется большей безопасности - я бы смотрел в сторону аппаратных токенов или хранения ключей в TPM с привязкой разблокировки к windows hello (Да, в w11 оно умеет - но с поддержкой алгоритмов могут быть нюансы, ecdsa-sk у меня заработал, а вот ed25519-sk нет) - но "для себя лично" можно и так, почему нет?
Эээээ... Что значит "нет"? Оно в том или ином виде и в OpenSSF (Signed reseases, signed commits) и в SLSA и даже во ФСТЕКовских мУ что-то навроде "криптографической защиты целостности и подлинности изменений в репозиториях кода." имеется. И да, в этот самый ФСТЕК на сертификацию первое, что просится - "К заявке прилагается руководство по безопасной разработке программного обеспечения, разработанное в соответствии с пунктом 5.1 настоящего Порядка. (в ред. Приказа ФСТЭК РФ от 30.06.2025 N 230) "
Персонально мне - нет, но de-facto это уже стандартное требование к "контролю целостности", "неотказуемости", "защиты авторства" и т.д., кочующее от NIST к ФСТЕКу и далее по внутренним регламентам и реализованное на уровне возможности примерно во всех продуктах.
Не то, чтобы я хоть капельку думал, что ФСТЕК удовлетворит подпись ключом ed25519 - но лучше иметь что-то, чем одно большое ничего, тем более что стоит оно - около "бесплатно".
Конкретно в этой статье - туториал по настройке подписи коммитов в git в различных рабочих окружениях. Всё. Централизованного управления ключами - в этой статье нет. Complience-policy и регламента безопасной разработки (Я посмотрел!) - тоже нет. Обеспечения автоматизации следования этому регламенту я, опять же - не описывал (Но таки скажу, что в gitlab "Reject unsigned commits." - штатная настройка небесплатных редакций).
Ну и да - конечная цель в том, чтобы принимать коммиты, подписанные работниками организации - а неподписанные или подписанные не работниками - не принимать.
Подпись это половина дела, как на счет проверки этой самой подписи?
Exactly. Но как бы ээээ... вся эта бабуйня как раз таки и затевалась, чтобы не иметь примерно "никакого" отношения к инфраструктуре PGP.
Хотелось бы увидеть как реализована эта часть, используются pgp инфраструктура keyserver?
"... но это уже саааавсем другая история". В корпоративной разработке примерно в 100% случаев есть single-source-of-truth в виде gitlab\guthub\gitea\gogs - и все, что вам нужно - это добавить туда соответствующий ключ.
Проблемы тут примерно две - открытый ключ должен "принадлежать организации" - мы "доверяем ключу, пока его владелец работает в организации", а после увольнения, соответствено - уже не очень и два - закрытый ключ "по соображению безопасности" должен быть в одном (А лучше ТОЛЬКО одном) экземпляре без всяких передач туда-обратно по сети.
В идеальном мире при устройстве тебе генерируют keypair на с закрытым ключом на неизвлекаемом носителе и выдают под роспись какой-нибудь yubikey - но где ж тот идеальный мир? В реальности приходится расширять схему AD, писать открытый ключ туда и делать интеграции с gitlab'ом и, например, теми серверами куда конкретному пользователю нужен доступ.
Соответственно решать несколько задач - сами интеграции с жонглированием открытыми ключами, генерацию закрытых ключей на оконечных устройствах (Тот же openssh в windows умеет хранить закртые ключи в TPM устройства... а linux из коробки - не умеет. У маководов как всегда - своя свадьба) - ну и автоматизировать процесс записи открытого ключа в аттрибуты LDAP после генерации + описывать процесс с заменой пролюбленного\зафейленного.
В общем совсем, совсем, совсем другая история еще на две-с-половиной статьи.
Когда в инфраструктуре десятки сервисов и баз данных разных типов,
... обычно уже понимаешь, что "dump" != "backup". Вот прям совсем-совсем "не". "Не годится", можно даже сказать. А в остальном - да-да, без "данных" и "нагрузки" можно пользоваться. Наверное - даже удобно...
Самое забавное, что нет ). Они база данных временных рядов (tabular или wide columns) БД - может, немного "гибридного дизайна" - но выбор в качестве kvstore и впрямь, странный.
Ну т.е. типа опять происки "злобного запада", "англичанка гадит", "пиндосы проклятые".
Та ни, это вот - ваши персональные проЭкции. А тут - opensource, в котором НИКТО НИКОМУ НИЧЕГО НЕ ДОЛЖЕН(ТМ)
Вот пошто в ванильке нет 64х битного счетчика транзаций, который нужен ВОТ ВООБЩЕ ВО ВСЕХ крупных инсталляциях? Набор патчей - есть. Реализация (На основе этого же патчсета, ага) во всех коммерческих дистрибутивах - есть. А в апстриме - не-а, нету. Тоже 1С должен, небось?
А пошто 1с все еще свою сборку postgresql таскает, а не "влил в апстрим"? А апстриму - внезапно - на проблемы одноэсенных положить. У них свой "проджект вижн" и делать из слоника мысыкуель они - н-ннегодяи! не хотят. Даже вот за деньги и чужими руками.
Вам надо - вы в своем приложении и. Вот 1С и. На удивление даже - небезуспешно.
Эммм... если что - то заказчик примерно так это и считает. Количество пользователей == количество активных УЗ в системе, затраты разносятся пропорционально, в результате в KPI СМ'а торчит аудит этих УЗ и "лишнего" там не то, чтобы много.
Так, чтобы кто-то из заказчиков выполнял профилирование пользователей и\или опирался на это профилирование при составлении ТЗ - ну... околонаучная фантастика. Реально у тебя будет выкопировка из того же APDEX в разделе "требования к эрогономике и технической эстетике" ну и вот "количество одновременно работающих пользователей", шт. Причем что это за "пользователь" такой - зооказчег тебе не скажет, "хоть дерись".
Я бы сказал - что проведенный тест вполне релевантен условиям задачи, как я их понимаю.
Но если что - в последнюю пару-тройку лет тесты показывают, что на postgresql (Наконец-то!) 1с стала работать быстрее, чем на mssql. "В среднем", конечно же - по тому же apdex'у.
"не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн"(C)
Это, в общем, изрядно режет эффективность оффлоада, усложняет логику и увеличивает пространство для возможных ошибок, поскольку в жизни у тебя цепочка может быть сильно развесистей - а ловятся такие редко всплывающие гонки ох, как хреново.
По личному опыту - вынос аналитики на слейв "да", разнесение обычных запросов на ro реплику - неа. Не стоит того.
Условно - увеличиваем количество позиций товара на 2 шт - делаем запрос на чтение того, что есть - RO запрос, идет на слейв, увеличиваем-записываем, ой - а слейв отстал! Что оказалось в базе?
Эта ситуация ничем не отличается от ситуации когда между результатом выборки данных и нажатием кнопки "сохранить" проходит какое-то время.
не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн
Тут как бы это сказать? Нюансы. Если делать синхронную репликацию - то она весь выигрыш съест, если асинхронную - то в случае, когда на основании результата выборки данных производится запись - возможны нехорошие варианты.
Опять же, в оффлоад readonly-запросов на slave умеют не только лишь все...
Да не то, чтобы - скорее, программистам она изначально и не нужна была. Таска в трекере, постановка в вики, код в git'е - и "Программировай!"
А вот координация работ в рамках крупного проекта, который ведет *цать участников - таки ой. Скорее всего почта окажется "общим знаменателем" - распределенная, fault-tolerant за счет этой самой "распределенности", дает минимальный уровень "неотказуемости" с практически нулевыми накладными, даже поиск больмень работает - в общем, если не пытаться превращать в "систему электронного документооборота" или прости осспыдя, "файлообменник" - то живее всех живых и альтернатив на горизонте того-этого... не вырисовывается.
Ну, не знаю. Мало того, что не нативное решение с соответствующими проблемами в поддержке при сколько-нибудь массовом внедрении, так и профит от него мне лично не очень ясен.
Чем пароль на keepass db отличается от пароля на id_rsa? А keeagent от ssh-agent'а? Если хочется большей безопасности - я бы смотрел в сторону аппаратных токенов или хранения ключей в TPM с привязкой разблокировки к windows hello (Да, в w11 оно умеет - но с поддержкой алгоритмов могут быть нюансы, ecdsa-sk у меня заработал, а вот ed25519-sk нет) - но "для себя лично" можно и так, почему нет?
Эээээ... Что значит "нет"? Оно в том или ином виде и в OpenSSF (Signed reseases, signed commits) и в SLSA и даже во ФСТЕКовских мУ что-то навроде "криптографической защиты целостности и подлинности изменений в репозиториях кода." имеется. И да, в этот самый ФСТЕК на сертификацию первое, что просится - "К заявке прилагается руководство по безопасной разработке программного обеспечения, разработанное в соответствии с пунктом 5.1 настоящего Порядка. (в ред. Приказа ФСТЭК РФ от 30.06.2025 N 230) "
Ну, у меня было ни на чем не основанное предположение, что человек, взявшийся настраивать подпись коммитов чуть-чуть представляет зачем оно ему нужно.
Эээээто же от другой стенки гвоздь, нет? Про подпись артефактов\релизов я тоже ничего не писал ).
Персонально мне - нет, но de-facto это уже стандартное требование к "контролю целостности", "неотказуемости", "защиты авторства" и т.д., кочующее от NIST к ФСТЕКу и далее по внутренним регламентам и реализованное на уровне возможности примерно во всех продуктах.
Не то, чтобы я хоть капельку думал, что ФСТЕК удовлетворит подпись ключом ed25519 - но лучше иметь что-то, чем одно большое ничего, тем более что стоит оно - около "бесплатно".
Ээээ... точно перечитали?
Конкретно в этой статье - туториал по настройке подписи коммитов в git в различных рабочих окружениях. Всё. Централизованного управления ключами - в этой статье нет. Complience-policy и регламента безопасной разработки (Я посмотрел!) - тоже нет. Обеспечения автоматизации следования этому регламенту я, опять же - не описывал (Но таки скажу, что в gitlab "Reject unsigned commits." - штатная настройка небесплатных редакций).
Ну и да - конечная цель в том, чтобы принимать коммиты, подписанные работниками организации - а неподписанные или подписанные не работниками - не принимать.
Exactly. Но как бы ээээ... вся эта бабуйня как раз таки и затевалась, чтобы не иметь примерно "никакого" отношения к инфраструктуре PGP.
"... но это уже саааавсем другая история". В корпоративной разработке примерно в 100% случаев есть single-source-of-truth в виде gitlab\guthub\gitea\gogs - и все, что вам нужно - это добавить туда соответствующий ключ.
Проблемы тут примерно две - открытый ключ должен "принадлежать организации" - мы "доверяем ключу, пока его владелец работает в организации", а после увольнения, соответствено - уже не очень и два - закрытый ключ "по соображению безопасности" должен быть в одном (А лучше ТОЛЬКО одном) экземпляре без всяких передач туда-обратно по сети.
В идеальном мире при устройстве тебе генерируют keypair на с закрытым ключом на неизвлекаемом носителе и выдают под роспись какой-нибудь yubikey - но где ж тот идеальный мир? В реальности приходится расширять схему AD, писать открытый ключ туда и делать интеграции с gitlab'ом и, например, теми серверами куда конкретному пользователю нужен доступ.
Соответственно решать несколько задач - сами интеграции с жонглированием открытыми ключами, генерацию закрытых ключей на оконечных устройствах (Тот же openssh в windows умеет хранить закртые ключи в TPM устройства... а linux из коробки - не умеет. У маководов как всегда - своя свадьба) - ну и автоматизировать процесс записи открытого ключа в аттрибуты LDAP после генерации + описывать процесс с заменой пролюбленного\зафейленного.
В общем совсем, совсем, совсем другая история еще на две-с-половиной статьи.
... обычно уже понимаешь, что "dump" != "backup". Вот прям совсем-совсем "не". "Не годится", можно даже сказать. А в остальном - да-да, без "данных" и "нагрузки" можно пользоваться. Наверное - даже удобно...
Самое забавное, что нет ). Они база данных временных рядов (tabular или wide columns) БД - может, немного "гибридного дизайна" - но выбор в качестве kvstore и впрямь, странный.
Ну, с учетом того, что cassandra - ниочень-то key-value database, а скорее wide columns\tabular database - претензий должно быть не мало...
Та ни, это вот - ваши персональные проЭкции. А тут - opensource, в котором НИКТО НИКОМУ НИЧЕГО НЕ ДОЛЖЕН(ТМ)
Вот пошто в ванильке нет 64х битного счетчика транзаций, который нужен ВОТ ВООБЩЕ ВО ВСЕХ крупных инсталляциях? Набор патчей - есть. Реализация (На основе этого же патчсета, ага) во всех коммерческих дистрибутивах - есть. А в апстриме - не-а, нету. Тоже 1С должен, небось?
А пошто 1с все еще свою сборку postgresql таскает, а не "влил в апстрим"? А апстриму - внезапно - на проблемы одноэсенных положить. У них свой "проджект вижн" и делать из слоника мысыкуель они - н-ннегодяи! не хотят. Даже вот за деньги и чужими руками.
Вам надо - вы в своем приложении и. Вот 1С и. На удивление даже - небезуспешно.
Эммм... если что - то заказчик примерно так это и считает. Количество пользователей == количество активных УЗ в системе, затраты разносятся пропорционально, в результате в KPI СМ'а торчит аудит этих УЗ и "лишнего" там не то, чтобы много.
Так, чтобы кто-то из заказчиков выполнял профилирование пользователей и\или опирался на это профилирование при составлении ТЗ - ну... околонаучная фантастика. Реально у тебя будет выкопировка из того же APDEX в разделе "требования к эрогономике и технической эстетике" ну и вот "количество одновременно работающих пользователей", шт. Причем что это за "пользователь" такой - зооказчег тебе не скажет, "хоть дерись".
Я бы сказал - что проведенный тест вполне релевантен условиям задачи, как я их понимаю.
"Осталось апстрим уговорить", ага.
Но если что - в последнюю пару-тройку лет тесты показывают, что на postgresql (Наконец-то!) 1с стала работать быстрее, чем на mssql. "В среднем", конечно же - по тому же apdex'у.
"не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн"(C)
Это, в общем, изрядно режет эффективность оффлоада, усложняет логику и увеличивает пространство для возможных ошибок, поскольку в жизни у тебя цепочка может быть сильно развесистей - а ловятся такие редко всплывающие гонки ох, как хреново.
По личному опыту - вынос аналитики на слейв "да", разнесение обычных запросов на ro реплику - неа. Не стоит того.
Условно - увеличиваем количество позиций товара на 2 шт - делаем запрос на чтение того, что есть - RO запрос, идет на слейв, увеличиваем-записываем, ой - а слейв отстал! Что оказалось в базе?
не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн
Тут как бы это сказать? Нюансы. Если делать синхронную репликацию - то она весь выигрыш съест, если асинхронную - то в случае, когда на основании результата выборки данных производится запись - возможны нехорошие варианты.
Опять же, в оффлоад readonly-запросов на slave умеют не только лишь все...
Плохо, больно, неудобно. Человековменяемый способ разрешения конфликтов считай "отсутствует".
А какой NiFi взят за основу, и как собираетесь бежать за апстримом, если не секрет?
Да не то, чтобы - скорее, программистам она изначально и не нужна была. Таска в трекере, постановка в вики, код в git'е - и "Программировай!"
А вот координация работ в рамках крупного проекта, который ведет *цать участников - таки ой. Скорее всего почта окажется "общим знаменателем" - распределенная, fault-tolerant за счет этой самой "распределенности", дает минимальный уровень "неотказуемости" с практически нулевыми накладными, даже поиск больмень работает - в общем, если не пытаться превращать в "систему электронного документооборота" или прости осспыдя, "файлообменник" - то живее всех живых и альтернатив на горизонте того-этого... не вырисовывается.
Это была замечательная иллюстрация исходному комменту :)