Está permitindo que checkins automatizados de subversão sejam uma má idéia?

Question

Sou um administrador de sistemas que suporta uma equipe de desenvolvedores e nosso repositório de subversão é protegido pela autenticação básica de HTTP vinculada a uma solução de conexão única. Também compartilhamos nossa infraestrutura com algumas outras equipes e subs. Os desenvolvedores querem uma conta que possam usar para escrever automaticamente no SVN (por exemplo, verificando automaticamente alguns scripts gerados ou publicar automaticamente versões inteiras em um diretório), armazenando a senha da conta no script ou usando o SSH para login sem senha.

Um colega meu em TI acha que isso seria uma ideia muito ruim, e estou inclinado a concordar, parece haver um risco de segurança muito alto, tanto de intenção maliciosa ou apenas um roteiro mal escrito descontrolado e causando estragos no repositório. No entanto, mais pessoas e outras equipes e subs continuam pedindo, e quando eu tentei fazer algumas das minhas próprias pesquisas eu não consegui encontrar nenhum material de apoio para me ajudar a convencê-los, o que me faz pensar se eu estou errado e não é tão ruim quanto eu acho.

Estou certo sobre a possível ameaça à segurança que esses scripts automatizados representam para o nosso repositório? Existem alternativas ou medidas de proteção que estão faltando? Se não, alguém pode me apontar na direção de qualquer material de apoio que possa me ajudar a entender?

[Editar] Esqueci de mencionar que também usamos o Jenkins para integração contínua: link

    

Answer 1

Bem, o risco de segurança ao permitir esses tipos de commits é completamente dependente do nível de sensibilidade do seu repositório.

Como você está fazendo a integração contínua, os commits ruins podem com certeza queimar você ... embora obviamente existam mecanismos para reverter as mudanças ruins, tão rapidamente quanto o commit negativo pode ser revertido manualmente. Aceitar esse risco é uma decisão de negócios, no final.

Depende do que os scripts estão fazendo, mas há definitivamente alguma atenuação de riscos que você pode fazer;

• Certifique-se de que todas as confirmações automáticas sejam não concluídas com as contas normais dos desenvolvedores. Você não quer que as senhas sejam salvas.
• Se possível, você pode restringir os usuários de confirmação automática a se comprometer apenas com arquivos específicos ou árvores de diretórios?
• Novamente, se possível, considere um gancho de pré-consolidação que faz alguma verificação de sanidade nas confirmações vindas das tarefas automatizadas (bloquear a confirmação se alguma ação de exclusão ocorrer ou se mais de 50 linhas de código forem alteradas?) - isso pode potencialmente capturar e impedir a entrada no tipo de commit destrutivo com o qual você está preocupado.

Por outro lado, se seus desenvolvedores estão apenas tentando fazer isso, eles não precisam digitar svn commit e, na verdade, digitar uma mensagem de commit decente e, em seguida, descartá-los.