Bug: Mantenedores do PHP recomendam adiar o upgrade para a versão 5.3.7
Via Slashdot chega o alerta de que os mantenedores da linguagem PHP alertaram seus usuários sobre um bug sério nas funções de criptografia do PHP 5.3.7, lançada na semana passada e trazendo uma série de correções para vulnerabilidades de segurança. A falha na função crypt() é considerada séria e a recomendação é que os upgrades sejam adiados até que a situação seja resolvida. (via developers.slashdot.org)
• Publicado por Augusto Campos em
2011-08-23
Vi o pessoal comentando sobre isso no reddit. Aparentemente foi uma modificação feita pelo próprio Rasmus, criador da linguagem, e após esta modificação os testes unitários estavam apontando que a modificação tinha quebrado o código. O problema é que os testes não foram executados ou os erros apontados foram ignorados.
# yaourt -Sayu
:: Sincronizando a base de dados de pacotes...
core está atualizado
extra 495,8K 771,1K/s 00:00:01 [######################] 100%
community 450,5K 523,4K/s 00:00:01 [######################] 100%
multilib está atualizado
Pacotes externos: | 12 / 12
==> Atualização de software (nova versão) :
extra/php 5.3.7-3 -> 5.3.8-1
extra/php-apache 5.3.7-3 -> 5.3.8-1
@Bremm
Também percebi esa atualização em um servidor de desenvolvimento que tenho com o Arch em casa.
Aliás, o Arch virou meu novo xodó.
Migrei um desktop meu Ubuntu 11.04 com Unity para um Arch Linux com GNOME3 e GNOME Shell.
Impressionante a velocidade que foi ganha com o Arch.
Me senti no OpenBSD, só que com modo gráfico de última geração.
Experiência incrível, fora o fato dele ser muito estável e tranquilo, mesmo com toda a atualização de software dele.
@André Luis Pereira dos Santos
Migrei um desktop meu Ubuntu 11.04 com Unity para um Arch Linux com GNOME3 e GNOME Shell.
Foi o que eu fiz no meu desktop, que era o Xubuntu 11.04. A única coisa que ainda me incomoda um pouco é um bug no ulatencyd disponível no AUR (não uso o ulatencyd-git), que ao iniciar no rc.d com a opção “-d” consome 100% de CPU. Por ora tenho iniciado o daemon manualmente, após o início do sistema.
Uma coisa que fiz também foi me livrar do gdm em favor do qingy (no /etc/inittab pus os dois primeiros tty com ele ao invés do agetty — v86d com framebuffer em 1280×800-32bit).
Estou pensando em arriscar o btrfs em um HD de 279 GiB (300 GB) onde tenho umas VMs (para teste) instaladas. Atualmente uso xfs em tudo exceto no boot (ext2) e claro, no swap. Ah, tem uma partição jfs de 10 GiB que era meu /home anteriormente (é rápida, mas não tem desfragmentador online).
@Bremm
Eu também estou estudando as opções para me livrar do GDM. Projeto pessoal hehehehehe.
Sobre o FS, nesse Arch meu estou usando tudo sob o JFS. Fiz isso pois queria experimentar outras coisas e recebi ótimas referência do JFS na wiki do próprio Arch.
Até agora sem reclamações. Velocidade impecável do FS em escritas e leitura sob altos e baixos loads.
Gasta poucos ciclos de CPU e RAM mas realmente não desfragmenta em RT. Tem de ser manualmente.
Sobre o BTRFS ele é um dos FS mais legais que já utilizei. Só tem uma coisa que hoje, ainda, torna o uso dele perigoso e eu já tiver duas vezes a infelicidade de experimentar:
Como ele não possui um FSCK, qualquer queda de energia pode ser fatal para o FS. E no meu caso, ocorreu duas vezes com meu /home que era criptografado.
Ou seja: Nem montando ele como somente leitura eu podia fazer algo.
Estão trabalhando nisso ainda (FSCK). Recomendo para todo mundo o uso do BTRFS como uma bela experiência. Mas não recomendo para uso em produção.
Mas ele é sem dúvidas o mais avançado FS para Linux já construído. Assim que possuir um FSCK ou equivalente, será meu FS de produção. E eu já sei que será o FS de produção aqui da empresa também.
@André Luis Pereira dos Santos
O jfs achei interessantíssimo para substituir o reiserfs no /var e no /srv. Apesar de gostar muito do xfs, o desempenho dele é sofrível com arquivos pequenos.
Voltando ao tópico: notei uma sensível diferença na execução do vpsinfo.php aqui no desktop. Não sei se faz sentido, já que a correção no php é na parte de criptografia.