Et demain, ou dans 6 mois, ou dans 1 an, le plus grand hébergeur :
- changera ses offres et te demandera de migrer manu militari, à un moment pas forcément le plus adapté pour toi,
- décidera que cette offre n'est pas profitable et doit être arrêtée sous x mois,
- changera ses tarifs et plombera les tarifs de ton entreprise…
J'en ai plein des comme ça, et j'ai déjà vu la plupart sur des produits d'OVH (mais pas en tant que client)
L'ARM 32 bits certes, l'ARM 64 bits faudra voir ce que ça donnera en pratique mais ça pourrait bien poutrer… Mais trouvera-t-on des stations de travail ou des PCs ARM64 ?
TDF fait une suite bureautique, Mozilla édite Firefox, un des systèmes d'exploitation du 21ème siècle… Donc nécessairement, Mozilla a besoin de bien plus de budget.
Plus sérieusement, Mozilla a un côté R&D non négligeable autour des technologies du Web, de Rust… Il serait intéressant de connaître la ventilation du budget.
C'est hélas pas nouveau. J'ai souvenir d'un pote en 2010/2011 qui, devant prendre l'avion en hiver, a été obligé d'utiliser Facebook pour suivre l'état des pistes de l'aéroport bloqué pour cause de neige.
Pas de facebook signifiait pas d'infos…
Alors OVH ne fait pas de R&D réelle, les projets big data c'est de l'intégration.
Quant au Erlang dans les annonces, c'est juste parce que c'était à la mode, mais y'a aucun projet en Erlang en interne. C'est du Perl ou un pouillème de Go suite à du lobbying interne intense d'une poignée de personnes.
Pour Nexedi, ils sont à fond dans Zope 2 en Python… On aime ou on déteste.
«As maintainers we have a duty to balance what will provide the best experience for the majority of our Plasma users without leaving anyone with a broken system. Projects like this bring the interfaces we need to BSD and as it gets more stable we should be able to start distributing features.»
En tant que mainteneurs, nous avons le devoir d'arbritrer ce qui fournira la meilleure expérience pour la majorité des utilisateurs de Plasma sans laisser personne avec un système cassé. Des projets comme celui-ci [https://uglyman.kremlin.cc/gitweb/gitweb.cgi] implémentent les interfaces dont nous avons besoin sur les systèmes BSD, et leur stabilisation nous permettra de commencer à distribuer des fonctionnalités.
Ce n'est pas flou. Du tout. Plasma va dépendre des APIs DBus implémentées sous Linux par systemd pour certains services. Point. L'absence de ces APIs rendra les-dits services non utilisables. Ça s'arrête là. Comme à l'époque de HAL par exemple, les utilisateurs BSD auront un léger retard sur certaines fonctionnalités. C'est tout. Et c'est pas une dépendance à libsystemd.so ou équivalent, juste une dépendance à un service dbus…
En gros, seccomp-bpf est un framework pour réduire la surface d'attaque (ie désarmer l'attaquant) alors que capsicum implique de continuer à faire confiance au noyau pour qu'un appel ne soit pas "dangereux" (par ex. la faille sur vmsplice).
Having a nice, high level, access control semantics is appealing and, one may argue, necessary. When you're designing a sandbox for your application, you may want to say things such as:
I want this process to have access to this subset of the file system.
I want this process to be able to allocate or de-allocate memory.
I want this process to be able to interfere (debug, send signals) with this set of processes.
The capabilities-oriented framework Capsicum takes such an approach. This is very useful.
However, with such an approach it's difficult to assess the kernel's attack surface. When the whole kernel is in your trusted computing base "you're going to have a bad time", as a colleague recently put it.
Now, in that same dimension, at the other end of the spectrum, is the "attack surface reduction" oriented approach. The approach where you're close to the ugly guts of implementation details, the one taken by Seccomp-BPF.
Sauf que ce lien compare pas avec le sha512-crypt, qui fait un certain nombre d'opérations pour rendre encore plus complexe la récupération du mot de passe en cas de cassage de l'algo sha512.
Security departments in companies are trying to phase out all
uses of MD5. They demand a method which is officially sanctioned.
For US-based users this means tested by the NIST.
This rules out the use of another already implemented method with
limited spread: the use of the Blowfish encryption method. The choice
comes down to tested encryption (3DES, AES) or hash sums (the SHA
family).
Il semblerait que cela soit à cause de cpanel. La majorité des cas que l'on ait vu se sont produits après avoir contacté le support de CPanel. Il faut en les contactant donner le mot de passe root de la machine, et ils ont eu une faille de sécurité chez eux et les accès aux machines des clients se sont retrouvés dans la nature…
Suffit de regarder le travail effectué sur les pilotes libres Intel, sur Mesa (pas directement par Valve, ok, mais pour le pilote Intel ils ont collaborré)… C'est bénéfique au libre.
C'est un bug du routeur, quand il se déclenche (c'est assez rare) il se met à broadcaster… On corrige manuellement quand ça se déclenche (et qu'on est au courant), et on a signalé le bug au fabricant pour que ça soit corrigé pour de vrai…
Ça te rassure ? Au passage, ça a été corrigé manuellement sur le routeur auquel tu es connecté, tu confirmes que ça floode plus ?
Le taux que te prend paypal est variable et dépend de l'acheteur, j'ai déjà remarqué des différences allant jusqu'à 1% du prix… Au passage ils ont des formules plus compliquées selon le type de vendeur…
Et surtout… les CBs hors paypal, auprès de fournisseurs de solutions de paiement tiers, sont à des taux largement plus faibles que ceux de paypal. Je n'ai pas de taux en tête (et surtout c'est fait à la tronche du client), mais c'est vraiment moins.
De plus… si tu lis les conditions de vente paypal et tous les contrats immondes, tu te rends compte que c'est hyper risqué de vendre du bien immatériel via Paypal : leur système de gestion des litiges n'est pas fait pour ça, et le vendeur est juste au dépourvu face à l'acheteur en cas de litige, vu que paypal n'accepte comme preuve que des bons de livraisons d'expéditeurs tiers type UPS, fedex…
Bon, pour avoir du implémenter les paiements Paypal, je peux te répondre : c'est dans l'API, tu dis si tu souhaites accepter ou non les paiements sans compte Paypal…
Après le marchand peut décider d'activer ou non ces paiements en fonction de ton pays et des moyens de paiement qu'ils gèrent.
Exemple : si ils ont les CBs, ils vont t'interdire de passer par paypal sans compte parce que ça leur coûte beaucoup beaucoup plus cher…
C'est déjà implémenté dans systemd, et le scheduler du noyau a eu un patch qui a fait beaucoup de bruit y'a quelques mois (ou 1 an ou 2, je sais plus) pour ajouter une fonctionnalité similaire : ordonnancement plus équitable en fonction des sessions… C'est ce qui fait qu'un make -j 64 dans un shell va pas faire ramer ta vidéo…
Si je loue un dédié, je le prends sans OS et je l'installe tout seul, comme cela pas de problème de clefs SSH et autres accès non contrôlé. Sinon quel intérêt d'avoir un dédié ?
Après, faut se mettre à la place du support OVH qui doit se prendre plein de demandes de personnes qui prennent un dédié et ne savent pas le gérer correctement…
C'était super tentant, j'ai paniqué aussi…
Mais c'est qu'un bug d'OpenSSH.
J'ai pu reproduire le même message alors qu'aucune clé SSH dans mon authorized keys ne correspondait…
Dès qu'il y a un from sur une clé, si on tente de se connecter avec une clé, même hors de la liste, ça provoque ce message.
Standard ouvert, certes. Mais s'il faut taxer (cher, j'imagine) pour avoir sa clé et son certificat acceptés par la banque… Pas glop, pas glop… :-/
Tu as tout compris ! :/
Quand on est un particulier, on pleure devant les sites moisis de nos banques… Quand tu touches à des outils pros, tu découvres qu'il y a plein de clients qui marchent partout, mais il faut aligner un bon chèque pour avoir les accès…
À titre de comparaison, en Allemagne, les banques implémentent toutes (ou presque ?) le protocole HBCI, et ça semble suffisamment ouvert aux clients pour que des logiciels libres comme aqbanking soient utilisables par des particuliers.
Je suis tombé sur ce logiciel par hasard il y a deux jours, j'étais surpris de ne pas trouver de client EBICS libre, ça remplit un besoin réel.
Par contre, le non-site web et la mauvaise organisation du code donnent un côté brouillon au projet : le fichier ebics.jar de 9Mo contient à la fois le code source du projet, les fichiers compilés, les dépendances externes, un ensemble pour compiler en Makefile et en ant (pour pas faire de jaloux ?)… Heureusement, le dépôt SVN est plus propre (à l'exception des dépendances externes).
Après, je ne suis pas fan de Java outre mesure, mais c'est une première notable et cela peut servir de point de départ pour comprendre et implémenter la norme EBICS dans d'autres langages.
À noter également, dans la dépêche : «En fait EBICS est un standard Allemand, adopté en 2008, pour effectuer des transactions bancaire.»
Ce n'est pas tout à fait vrai : EBICS est un protocole de transmission de fichiers sécurisé avec la banque. Il permet d'envoyer des ordres de prélèvement ou de virement, mais aussi de demander des relevés de compte par exemple.
[^] # Re: dispo
Posté par Pinaraf . En réponse au journal L'informatique de papa. Évalué à 7.
Et demain, ou dans 6 mois, ou dans 1 an, le plus grand hébergeur :
- changera ses offres et te demandera de migrer manu militari, à un moment pas forcément le plus adapté pour toi,
- décidera que cette offre n'est pas profitable et doit être arrêtée sous x mois,
- changera ses tarifs et plombera les tarifs de ton entreprise…
J'en ai plein des comme ça, et j'ai déjà vu la plupart sur des produits d'OVH (mais pas en tant que client)
[^] # Re: BOF
Posté par Pinaraf . En réponse au journal Talos Secure Workstation, une station de travail sécurisée et compatible avec le libre ?. Évalué à 1.
L'ARM 32 bits certes, l'ARM 64 bits faudra voir ce que ça donnera en pratique mais ça pourrait bien poutrer… Mais trouvera-t-on des stations de travail ou des PCs ARM64 ?
# Comparons ce qui est comparable...
Posté par Pinaraf . En réponse au journal La fin de Firefox OS. Évalué à 7.
TDF fait une suite bureautique, Mozilla édite Firefox, un des systèmes d'exploitation du 21ème siècle… Donc nécessairement, Mozilla a besoin de bien plus de budget.
Plus sérieusement, Mozilla a un côté R&D non négligeable autour des technologies du Web, de Rust… Il serait intéressant de connaître la ventilation du budget.
[^] # Re: Contenu intéressant ?
Posté par Pinaraf . En réponse au journal Facebook, cookies, vie privée, toussa. Évalué à 3.
C'est hélas pas nouveau. J'ai souvenir d'un pote en 2010/2011 qui, devant prendre l'avion en hiver, a été obligé d'utiliser Facebook pour suivre l'état des pistes de l'aéroport bloqué pour cause de neige.
Pas de facebook signifiait pas d'infos…
# Ma solution
Posté par Pinaraf . En réponse au journal Facebook, cookies, vie privée, toussa. Évalué à 3.
Bon, avec un coup de noscript en plus, on commence à se sentir à l'aise…
# OVH et Nexedi...
Posté par Pinaraf . En réponse au journal Qui fait des trucs "cools" en France et en Europe?. Évalué à 9.
Alors OVH ne fait pas de R&D réelle, les projets big data c'est de l'intégration.
Quant au Erlang dans les annonces, c'est juste parce que c'était à la mode, mais y'a aucun projet en Erlang en interne. C'est du Perl ou un pouillème de Go suite à du lobbying interne intense d'une poignée de personnes.
Pour Nexedi, ils sont à fond dans Zope 2 en Python… On aime ou on déteste.
# Et la conclusion ?
Posté par Pinaraf . En réponse au journal KDE Plasma et systemd. Évalué à 10.
Il suffit de lire la conclusion…
«As maintainers we have a duty to balance what will provide the best experience for the majority of our Plasma users without leaving anyone with a broken system. Projects like this bring the interfaces we need to BSD and as it gets more stable we should be able to start distributing features.»
En tant que mainteneurs, nous avons le devoir d'arbritrer ce qui fournira la meilleure expérience pour la majorité des utilisateurs de Plasma sans laisser personne avec un système cassé. Des projets comme celui-ci [https://uglyman.kremlin.cc/gitweb/gitweb.cgi] implémentent les interfaces dont nous avons besoin sur les systèmes BSD, et leur stabilisation nous permettra de commencer à distribuer des fonctionnalités.
Ce n'est pas flou. Du tout. Plasma va dépendre des APIs DBus implémentées sous Linux par systemd pour certains services. Point. L'absence de ces APIs rendra les-dits services non utilisables. Ça s'arrête là. Comme à l'époque de HAL par exemple, les utilisateurs BSD auront un léger retard sur certaines fonctionnalités. C'est tout. Et c'est pas une dépendance à libsystemd.so ou équivalent, juste une dépendance à un service dbus…
[^] # Re: Et sinon il y a SELinux
Posté par Pinaraf . En réponse au journal Seccomp, une sandbox intégrée au noyau Linux…. Évalué à 4.
Le blog des développeurs de chrome est très intéressant à ce sujet : http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html
En gros, seccomp-bpf est un framework pour réduire la surface d'attaque (ie désarmer l'attaquant) alors que capsicum implique de continuer à faire confiance au noyau pour qu'un appel ne soit pas "dangereux" (par ex. la faille sur vmsplice).
[^] # Re: bcrypt
Posté par Pinaraf . En réponse au journal OVH sous le coup d'un acte de piraterie. Évalué à 3.
Sauf que ce lien compare pas avec le sha512-crypt, qui fait un certain nombre d'opérations pour rendre encore plus complexe la récupération du mot de passe en cas de cassage de l'algo sha512.
http://www.akkadia.org/drepper/SHA-crypt.txt
Security departments in companies are trying to phase out all
uses of MD5. They demand a method which is officially sanctioned.
For US-based users this means tested by the NIST.
This rules out the use of another already implemented method with
limited spread: the use of the Blowfish encryption method. The choice
comes down to tested encryption (3DES, AES) or hash sums (the SHA
family).
[^] # Re: bcrypt
Posté par Pinaraf . En réponse au journal OVH sous le coup d'un acte de piraterie. Évalué à 1.
Ça apporte quoi par rapport à ça ?
crypt ( "password", "$6$rounds=100000$" . random(16 caractères stp))
Sachant que crypt se contente pas de faire un sha512, ou une boucle de sha512, ça serait trop simple…
Si crypt dans ce mode là est «faillible», tu pètes toutes les distribs linux modernes quand même…
[^] # Re: CPanel soupçonné
Posté par Pinaraf . En réponse à la dépêche Infection par rootkit « SSHd Spam » sur des serveurs RHEL/CentOS. Évalué à 10.
Et merde, faut s'attendre à des millions de serveurs corrompus alors…
# CPanel soupçonné
Posté par Pinaraf . En réponse à la dépêche Infection par rootkit « SSHd Spam » sur des serveurs RHEL/CentOS. Évalué à 10.
Hello
Il semblerait que cela soit à cause de cpanel. La majorité des cas que l'on ait vu se sont produits après avoir contacté le support de CPanel. Il faut en les contactant donner le mot de passe root de la machine, et ils ont eu une faille de sécurité chez eux et les accès aux machines des clients se sont retrouvés dans la nature…
# Steam bénéficie déjà au libre...
Posté par Pinaraf . En réponse au journal Valve va (probablement) concevoir sa propre console de jeux avec "Linux". Évalué à 10.
Suffit de regarder le travail effectué sur les pilotes libres Intel, sur Mesa (pas directement par Valve, ok, mais pour le pilote Intel ils ont collaborré)… C'est bénéfique au libre.
[^] # Re: Infos supplémentaires
Posté par Pinaraf . En réponse au journal OVH multicast. Évalué à 5.
Voilà, j'ai les infos…
C'est un bug du routeur, quand il se déclenche (c'est assez rare) il se met à broadcaster… On corrige manuellement quand ça se déclenche (et qu'on est au courant), et on a signalé le bug au fabricant pour que ça soit corrigé pour de vrai…
Ça te rassure ? Au passage, ça a été corrigé manuellement sur le routeur auquel tu es connecté, tu confirmes que ça floode plus ?
# Infos supplémentaires
Posté par Pinaraf . En réponse au journal OVH multicast. Évalué à 9.
Tu pourrais m'envoyer des infos sur ta connexion ?
Genre ton nichandle OVH ou ton numéro de ligne (si t'as plusieurs lignes sur ton nichandle, précise laquelle aussi)…
Ça sera plus pratique pour moi chercher ce qu'il se passe exactement avec les collègues…
[^] # Re: API…
Posté par Pinaraf . En réponse au journal Paypal et la création de compte. Évalué à 3.
Ça dépend de plein de choses…
Le taux que te prend paypal est variable et dépend de l'acheteur, j'ai déjà remarqué des différences allant jusqu'à 1% du prix… Au passage ils ont des formules plus compliquées selon le type de vendeur…
Et surtout… les CBs hors paypal, auprès de fournisseurs de solutions de paiement tiers, sont à des taux largement plus faibles que ceux de paypal. Je n'ai pas de taux en tête (et surtout c'est fait à la tronche du client), mais c'est vraiment moins.
De plus… si tu lis les conditions de vente paypal et tous les contrats immondes, tu te rends compte que c'est hyper risqué de vendre du bien immatériel via Paypal : leur système de gestion des litiges n'est pas fait pour ça, et le vendeur est juste au dépourvu face à l'acheteur en cas de litige, vu que paypal n'accepte comme preuve que des bons de livraisons d'expéditeurs tiers type UPS, fedex…
# API…
Posté par Pinaraf . En réponse au journal Paypal et la création de compte. Évalué à 5.
Bon, pour avoir du implémenter les paiements Paypal, je peux te répondre : c'est dans l'API, tu dis si tu souhaites accepter ou non les paiements sans compte Paypal…
Après le marchand peut décider d'activer ou non ces paiements en fonction de ton pays et des moyens de paiement qu'ils gèrent.
Exemple : si ils ont les CBs, ils vont t'interdire de passer par paypal sans compte parce que ça leur coûte beaucoup beaucoup plus cher…
# À l'ouest rien de nouveau
Posté par Pinaraf . En réponse au journal Des control groups par défaut sur un système desktop ?. Évalué à 10.
C'est déjà implémenté dans systemd, et le scheduler du noyau a eu un patch qui a fait beaucoup de bruit y'a quelques mois (ou 1 an ou 2, je sais plus) pour ajouter une fonctionnalité similaire : ordonnancement plus équitable en fonction des sessions… C'est ce qui fait qu'un make -j 64 dans un shell va pas faire ramer ta vidéo…
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Pinaraf . En réponse au journal Compromission de clé SSH chez OVH. Évalué à 10.
Après, faut se mettre à la place du support OVH qui doit se prendre plein de demandes de personnes qui prennent un dédié et ne savent pas le gérer correctement…
[^] # Re: Nop, bug d'OpenSSH
Posté par Pinaraf . En réponse au journal Compromission de clé SSH chez OVH. Évalué à 4.
Le mieux serait que ça soit corrigé…
https://bugzilla.mindrot.org/show_bug.cgi?id=2027
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par Pinaraf . En réponse au journal Compromission de clé SSH chez OVH. Évalué à 5.
Sinon…
Tu fais comme moi : mode rescue et debootstrap pour avoir une debian aux petits oignons…
# Nop, bug d'OpenSSH
Posté par Pinaraf . En réponse au journal Compromission de clé SSH chez OVH. Évalué à 10.
Hé non…
C'était super tentant, j'ai paniqué aussi…
Mais c'est qu'un bug d'OpenSSH.
J'ai pu reproduire le même message alors qu'aucune clé SSH dans mon authorized keys ne correspondait…
Dès qu'il y a un from sur une clé, si on tente de se connecter avec une clé, même hors de la liste, ça provoque ce message.
# Bravo
Posté par Pinaraf . En réponse au journal Rétro ingénierie Epson. Évalué à 10.
Super journal…
[^] # Re: 3615 mavie
Posté par Pinaraf . En réponse à la dépêche Enfin, un client EBICS java libre. Évalué à 6.
Standard ouvert, certes. Mais s'il faut taxer (cher, j'imagine) pour avoir sa clé et son certificat acceptés par la banque… Pas glop, pas glop… :-/
Tu as tout compris ! :/
Quand on est un particulier, on pleure devant les sites moisis de nos banques… Quand tu touches à des outils pros, tu découvres qu'il y a plein de clients qui marchent partout, mais il faut aligner un bon chèque pour avoir les accès…
À titre de comparaison, en Allemagne, les banques implémentent toutes (ou presque ?) le protocole HBCI, et ça semble suffisamment ouvert aux clients pour que des logiciels libres comme aqbanking soient utilisables par des particuliers.
# À suivre...
Posté par Pinaraf . En réponse à la dépêche Enfin, un client EBICS java libre. Évalué à 5. Dernière modification le 14 mars 2012 à 00:32.
Je suis tombé sur ce logiciel par hasard il y a deux jours, j'étais surpris de ne pas trouver de client EBICS libre, ça remplit un besoin réel.
Par contre, le non-site web et la mauvaise organisation du code donnent un côté brouillon au projet : le fichier ebics.jar de 9Mo contient à la fois le code source du projet, les fichiers compilés, les dépendances externes, un ensemble pour compiler en Makefile et en ant (pour pas faire de jaloux ?)… Heureusement, le dépôt SVN est plus propre (à l'exception des dépendances externes).
Après, je ne suis pas fan de Java outre mesure, mais c'est une première notable et cela peut servir de point de départ pour comprendre et implémenter la norme EBICS dans d'autres langages.
À noter également, dans la dépêche : «En fait EBICS est un standard Allemand, adopté en 2008, pour effectuer des transactions bancaire.»
Ce n'est pas tout à fait vrai : EBICS est un protocole de transmission de fichiers sécurisé avec la banque. Il permet d'envoyer des ordres de prélèvement ou de virement, mais aussi de demander des relevés de compte par exemple.