Я системный администратор, поддерживающий группу разработчиков, и наш репозиторий Subversion защищен базовой аутентификацией HTTP, привязанной к решению единой регистрации. Мы также разделяем нашу инфраструктуру с некоторыми другими командами и заменами. Разработчикам нужна учетная запись, которую они могут использовать для автоматической записи в SVN (например, автоматически проверять некоторые сгенерированные сценарии или автоматически публиковать целые выпуски в каталоге), либо сохраняя пароль учетной записи в сценарии, либо используя SSH для входа без пароля.
Мой коллега из ИТ-отдела считает, что это было бы очень плохой идеей, и я склонен согласиться, что, похоже, существует очень высокий риск для безопасности как из-за злого умысла, так и из-за того, что плохо написанный скрипт вышел из строя и нанес ущерб репозиторий. Тем не менее, все больше людей, другие команды и субподрядчики продолжают просить об этом, и когда я попытался провести какое-то собственное исследование, я не смог найти никаких вспомогательных материалов, которые помогли бы мне убедить их, что заставляет меня задаться вопросом, могу ли я Я ошибаюсь, и это не так плохо, как я думаю.
Прав ли я насчет потенциальной угрозы безопасности, которую эти автоматические скрипты представляют для нашего репозитория? Есть ли какие-то альтернативы или защитные меры, которых мне не хватает? Если нет, может ли кто-нибудь указать мне на какой-либо вспомогательный материал, который мог бы помочь мне донести мысль?
[Edit] Я забыл упомянуть, что мы также используем Jenkins для непрерывной интеграции: http://en.wikipedia.org/wiki/Jenkins_%28software%29
Что ж, риск безопасности при разрешении таких коммитов полностью зависит от уровня чувствительности вашего репозитория.
Поскольку вы выполняете непрерывную интеграцию, плохие фиксации, безусловно, могут вас обжечь ... хотя, очевидно, существуют механизмы для отката плохих изменений, так же быстро, как плохой фиксации можно откатить вручную. В конце концов, принятие этого риска - это бизнес-решение.
Это зависит от того, что делают сценарии, но вы определенно можете снизить риск;
С другой стороны, если ваши разработчики просто пытаются это сделать, им не нужно вводить svn commit и на самом деле введите приличное сообщение о фиксации, а затем полностью уничтожьте их.