tem que ser assim pois muitos não tem tempo para atualizar o sistema sempre, se ficar divulgando tambem piora pois mostra para quem deseja fazer o mal o erro e como o sistema é fechado ficar mais dificil passar detalhes, mesmo sistemas abertos tambem tem problemas dificies de entender e resolver para quem não tem conhecimentos veja o bug shellshock que tinha 25 anos aos olhos de milhares de programadores e somente agora resolvido, sem fala no openssl, cada um tem sua forma de trabalhar, eu por experiencia acho melhor assim...
Não precisa dar detalhes, Pedro. É apenas economizar o tempo do usuário que deixa de procurar falhas em sua implementação ao invés de resolver logo com uma atualização, ou mesmo saber que o erro veio junto com uma atualização. O nome disso é regressão.
Se alguém quiser fazer o mal https://www.debian.org/security/ tem muito mais informação relevante do que você poderia colocar num changelog.
Pedro Filho disse:
tem que ser assim pois muitos não tem tempo para atualizar o sistema sempre, se ficar divulgando tambem piora pois mostra para quem deseja fazer o mal o erro e como o sistema é fechado ficar mais dificil passar detalhes, mesmo sistemas abertos tambem tem problemas dificies de entender e resolver para quem não tem conhecimentos veja o bug shellshock que tinha 25 anos aos olhos de milhares de programadores e somente agora resolvido, sem fala no openssl, cada um tem sua forma de trabalhar, eu por experiencia acho melhor assim...
Então pedro, não precisa de changelog de bugs de segurança, mas pelo menos de recursos acrescidos e removidos. Olhando no changelog atual não dá pra saber lá de uma versão mais antiga 4.8x pra atual o que vai estar diferente. Fora que cada compilação deveria ter um número. 4.99.0001 4.99.0002 ..... etc. Baixo a iso hoje e amanhã pode ser outra e com o mesmo número de versão.
Se alguém relata algum problema, não tem como você saber qual a versão exata que a pessoa tem em mãos, o que não te ajuda a achar uma mudança no código que identifique algum problema, por exemplo.
Trabalhar com uma versão STABLE e outra BETA também é interessante para um sistema em que se mexe tão dinamicamente nos recursos. Quem não tem tempo de ficar arriscando as últimas atualizações pega a última STABLE e não fica reclamando.
Eu faço faço o meu próprio controle de versão. Eu anoto o dia da atualização e coloco como comentário na minha máquina virtual. Fica algo como: 4.99.20150717. Não é tão complicado assim e ajuda a localizar qual mudança causou qual problema. O ótimo seria ter essa informação na tela do MK-AUTH.
znadmin disse:
Então pedro, não precisa de changelog de bugs de segurança, mas pelo menos de recursos acrescidos e removidos. Olhando no changelog atual não dá pra saber lá de uma versão mais antiga 4.8x pra atual o que vai estar diferente. Fora que cada compilação deveria ter um número. 4.99.0001 4.99.0002 ..... etc. Baixo a iso hoje e amanhã pode ser outra e com o mesmo número de versão.
Se alguém relata algum problema, não tem como você saber qual a versão exata que a pessoa tem em mãos, o que não te ajuda a achar uma mudança no código que identifique algum problema, por exemplo.
Trabalhar com uma versão STABLE e outra BETA também é interessante para um sistema em que se mexe tão dinamicamente nos recursos. Quem não tem tempo de ficar arriscando as últimas atualizações pega a última STABLE e não fica reclamando.
Então, pois é, não é complicado e resolve. Há de se ter disponibilidade de olhar todo dia versão nova, fórum.... não é para todo mundo. Deveria ter no próprio mk-auth pra ajudar a todos.
Marco de Freitas disse:
Eu faço faço o meu próprio controle de versão. Eu anoto o dia da atualização e coloco como comentário na minha máquina virtual. Fica algo como: 4.99.20150717. Não é tão complicado assim e ajuda a localizar qual mudança causou qual problema. O ótimo seria ter essa informação na tela do MK-AUTH
Essa é a abordagem correta. Tanto que é implementada em muitos softwares.
znadmin disse:
Então, pois é, não é complicado e resolve. Há de se ter disponibilidade de olhar todo dia versão nova, fórum.... não é para todo mundo. Deveria ter no próprio mk-auth pra ajudar a todos.
Cheguei aqui por agora. Diferente da maioria eu não tenho ou trabalho em um provedor de internet (já trabalhei em 2016). Hoje me interesso pelo Mk-Auth por que sou cliente de um provedor que usa ele.
Fiquei feliz em ver que, agora o Pedro está incluindo as CVE's no changelog. Quando um provedor percebe que a atualização contém atualizações de segurança ele pode dar mais atenção àquela atualização específica.
Como disse, não tenho um provedor, mas trabalho com pesquisas de segurança buscando vulnerabilidades em aplicações. E, como sou afetado pelo desempenho na segurança do Mk-Auth, tirei um tempo para analisar o quão seguro ele é.
Encontrei diversas vulnerabilidades críticas que estarei enviando para o Pedro. Da ultima vez que enviei uma vulnerabilidade ele prontamente a resolveu. Isso é um bom sinal por que mostra um comprometimento crescente com a segurança do sistema.
O objetivo de eu estar escrevendo esse comentário é sugerir que quem estiver usando o Mk-Auth fique atento às atualizações e mantenham seus sistemas atualizados. Além de elogiar o Pedro pela postura e comprometimento com o sistema que é tão largamente utilizado.
Respostas
http://mk-auth.ning.com/page/changelog-1
algumas mudanças não são colocadas por questões comerciais e outras são correções de bug's que tb não são informados por razões de segurança ....
Segurança por obscuridade não é segurança, Pedro.
tem que ser assim pois muitos não tem tempo para atualizar o sistema sempre, se ficar divulgando tambem piora pois mostra para quem deseja fazer o mal o erro e como o sistema é fechado ficar mais dificil passar detalhes, mesmo sistemas abertos tambem tem problemas dificies de entender e resolver para quem não tem conhecimentos veja o bug shellshock que tinha 25 anos aos olhos de milhares de programadores e somente agora resolvido, sem fala no openssl, cada um tem sua forma de trabalhar, eu por experiencia acho melhor assim...
Marco de Freitas disse:
Não precisa dar detalhes, Pedro. É apenas economizar o tempo do usuário que deixa de procurar falhas em sua implementação ao invés de resolver logo com uma atualização, ou mesmo saber que o erro veio junto com uma atualização. O nome disso é regressão.
Se alguém quiser fazer o mal https://www.debian.org/security/ tem muito mais informação relevante do que você poderia colocar num changelog.
Pedro Filho disse:
Então pedro, não precisa de changelog de bugs de segurança, mas pelo menos de recursos acrescidos e removidos. Olhando no changelog atual não dá pra saber lá de uma versão mais antiga 4.8x pra atual o que vai estar diferente. Fora que cada compilação deveria ter um número. 4.99.0001 4.99.0002 ..... etc. Baixo a iso hoje e amanhã pode ser outra e com o mesmo número de versão.
Se alguém relata algum problema, não tem como você saber qual a versão exata que a pessoa tem em mãos, o que não te ajuda a achar uma mudança no código que identifique algum problema, por exemplo.
Trabalhar com uma versão STABLE e outra BETA também é interessante para um sistema em que se mexe tão dinamicamente nos recursos. Quem não tem tempo de ficar arriscando as últimas atualizações pega a última STABLE e não fica reclamando.
Abraços
Eu faço faço o meu próprio controle de versão. Eu anoto o dia da atualização e coloco como comentário na minha máquina virtual. Fica algo como: 4.99.20150717. Não é tão complicado assim e ajuda a localizar qual mudança causou qual problema. O ótimo seria ter essa informação na tela do MK-AUTH.
znadmin disse:
Então, pois é, não é complicado e resolve. Há de se ter disponibilidade de olhar todo dia versão nova, fórum.... não é para todo mundo. Deveria ter no próprio mk-auth pra ajudar a todos.
Marco de Freitas disse:
Essa é a abordagem correta. Tanto que é implementada em muitos softwares.
znadmin disse:
Boa tarde pessoal,
Cheguei aqui por agora. Diferente da maioria eu não tenho ou trabalho em um provedor de internet (já trabalhei em 2016). Hoje me interesso pelo Mk-Auth por que sou cliente de um provedor que usa ele.
Fiquei feliz em ver que, agora o Pedro está incluindo as CVE's no changelog. Quando um provedor percebe que a atualização contém atualizações de segurança ele pode dar mais atenção àquela atualização específica.
Como disse, não tenho um provedor, mas trabalho com pesquisas de segurança buscando vulnerabilidades em aplicações. E, como sou afetado pelo desempenho na segurança do Mk-Auth, tirei um tempo para analisar o quão seguro ele é.
Encontrei diversas vulnerabilidades críticas que estarei enviando para o Pedro. Da ultima vez que enviei uma vulnerabilidade ele prontamente a resolveu. Isso é um bom sinal por que mostra um comprometimento crescente com a segurança do sistema.
O objetivo de eu estar escrevendo esse comentário é sugerir que quem estiver usando o Mk-Auth fique atento às atualizações e mantenham seus sistemas atualizados. Além de elogiar o Pedro pela postura e comprometimento com o sistema que é tão largamente utilizado.
Atenciosamente,