barmic 🦦 a écrit 6003 commentaires

J'ai rien compris au paragraphe que j'ai cité plus haut du coup.

Accepter qu'il y ait un risque ne veut pas dire courir comme un poulet sans tête en espérant ne pas taper un mur. Si chacun sur son projet est un peu plus conscient des enjeux, ça améliore de beaucoup la résilience de l'ensemble.

Tu as toujours et tu aura toujours des gens qui font n'importe quoi. C'est pas lié à l'informatique ni à aujourd'hui. La médiatisation de faille comme log4shell et la responsabilisation légale en cas d'incident vont dans ce sens.

Que tout ne soit pas parfait je suis d'accord. Affirmer que rien est fait me semble verser dans l'émotion du moment.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais pour chaque composant utilisé, il faut être sûr du code existant, sûr de l'équipe et sûr du futur du composant et que l'équipe ne sera jamais gangrénée (on a vu quelques attaques côté npm, où quelqu'un qui paraissait de bonne volonté a repris la maintenance d'un composant largement utilisé pour finalement y inclure une faille volontairement bien après), d'autant qu'on met de plus en plus les composants à jour automatiquement (Dependabot, Renovate).

Non 1000 fois non ! Jamais ! Tu appel de tes veux à la construction d'une cathédrale, mais ce n'est pas comme ça que ça fonctionne. Ça n'a jamais fonctionner comme ça et ça ne peut pas fonctionner ainsi. Ce que tu souhaite "s'assurer que toutes nouvelles fonctionnalités n'ai aucune faille de sécurité", même allégée parce qu'il est impossible de garantir l'absence de faille, ce serait quoi ? 3 à 5 fois plus d'effort ? Et qui peut le faire les 20 à 30% des développeurs les plus connaisseurs en sécurité ?

Il faut apprendre à vivre avec le fait que ton code, ta toolchain, ton matériel et les gens qui utilisent ton logiciel sont peut être tes ennemis. Le travail c'est de savoir quel est l'enjeu (qu'est-ce que ça implique ?) et d'avoir des contremesures pour (qui auront elles-même des problèmes potentielles, mais qui modifient les probabilités de problèmes ou leur impact).

Il y a pleins de choses qui sont faites, la CI est quelque chose qui s'est extrêmement démocratisé et qui permet la prise en compte rapide, les bug bounty prolifèrent, les systèmes et plateformes se durcissent avec le temps (c'est le cas de java entre autre)…

Ce que tu cherche est délirant :

• parce que ça demande un effort qui est exponentiel avec le temps
• parce que si tu veux une garantie, il faut que tu face confiance à celui qui te donne une garanti, mais comment tu garanti que cette entité ?
• je ne retrouve plus la source mais je suis sûr d'avoir déjà lu un papier expliquant que pour tout système informatique il existe un code malveillant capable de l'attaquer

Il faut faire le deuil de tout cela et accepter que l'informatique n'est pas une science capable de fournir ce niveau de garanti.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Un point qui me chagrine est que chaque fois qu'il y a une faille, on dirige plein d'argent et plein de recherche sur le projet qui a posé souci et on perd de vue que c'est un problème général. Tous les jours, on utilise du code Open Source dont on a absolument aucune idée du contenu (le problème est le même pour le code proprio mais on l'utilise moins facilement). On espère que les gens qui le développent savent ce qu'ils font et sont sérieux et honnêtes. Ben pour l'instant, on a eu globalement du bol. Est-ce que ça va durer ?

Je ne suis pas d'accord. Après heartbleed il y a des choses qui ont était faites de manière plus général (il y a FOSSA dont je parlais plus haut, mais la linux fondation aussi avait fais des choses). La question c'est quel projets n'est pas critique pour la sécurité ? Il faut faire des choix.

Par contre ça montre je trouve que des politiques de sécurité drastiques (règle réseau, droits au niveau du système) peuvent être mises en place et peuvent annihiler la dangerosité de nombreuses attaques.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tout à fait d'accord. Un autre élément qui montre que le lookup bien que très surprenant doit avoir des usages, c'est que la principale alternative à log4j : logback, le faisait aussi (bon ça n'est pas accessible depuis le logging).

https://logback.qos.ch/news.html

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça n'est pas aussi simple que ça. La Chine est dans l'organisation mondiale du commerce. Et la Chine aussi a besoin que sa propriété intellectuelle ne soit pas bafouée.

Je ne sais pas sur quoi ça va aboutir, mais je ne serais pas si catégorique.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne suis pas certains que les failles suivantes auraient été trouvées si vite avec du code non lisible. Et des initiatives comme FOSSA sont bien plus compliquées à mettre en place avec du code fermé. Après on est pas à l'abri de commits hypocrites.

Je ne sais pas si les 2 se valent mais je ne dirais pas que c'est identique.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Concernant le CI , oui un mvn audit serait bien, encore
faudrait il que eles serveurs maven suivent (il n'y a pas
uniquement maven central )

Et il faut avoir l'infrastucture et les procédures pour gérer des failles. C'est amusant de comparer ça avec npm (qui a la fonction, mais aussi des gens pour s'en occuper, d'autant plus depuis le rachat par github et par microsoft), ou avec pypi (qui n'a personne pour faire le taf, ou du moins, qui n'avait personne à temps plein sur la maintenance du logiciel avant, et sans doute des volontaires sur le reste).

Ça existe :

https://jeremylong.github.io/DependencyCheck/dependency-check-maven/

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Non mais je sais comment on perd de la connaissance, mais comment vous decretez que c'est le cas ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

D'où tu sort que ça signifie qu'ils ne savent pas reconstruire leur logiciel ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le danger premier de log4shell c'est qu'il est un moyen d'entrée et qu'il est possible de lancer l'attaque de manière générique à l'heure actuel probablement tous les serveurs derrière une IPv4 ont dû prendre une tentative. Quand tu as déjà quelqu'un qui s'est introduit physiquement dans la centrale pour prendre le contrôle d'un serveur, c'est tout à fait possible, mais ce n'est plus à la porté du script kiddy. On commence à entrer dans une séquence de défaillance et plus une seule. Ils ont d'autres contre mesures qui vont encore rendre plus compliqué l'exploitation comme le fait que toutes les connexions doivent avoir étaient autorisée au préalable. Je ne sais pas, mais je doute qu'ils utilisent des jars signés ou de la sécurité type java2.

On est sur des niveaux d'attaques qui sont sans commune mesures avec ce dont on parle pour simplement log4shell.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tout le monde ne peux pas avoir ce genre de fonctionnement. J'ai des amis qui font des logiciels en centrales nucléaires. Leurs installations ne sont pas reliées à internet, les mises à jour ne se font pas via une CI/CD et sans aller jusqu'à ce genre d'extrémum c'est le cas de pas mal de choses en industrie. Parce qu'ils séparent leurs réseaux. Stuxnet n'a pas besoin de log4shell pour te pourrir la vie.

Et sans accès possible distant, log4shell perds beaucoup de sa dangerosité.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

À coté, Go a eu sa propre lib, Rust a RusTLS, et les autres sans doute pareil, pour éviter de se servir d'OpenSSL.

Je ne sais pas ce qu'il en ai des autres, mais rustls a démarré son développement 2 ans après heartbleed et je ne crois qu'il y ai le moindre lien. rust est simplement très adapté à ce genre d'utilisation. Ce serait dommage de s'en priver.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

à moyen terme, verrons nous plus d'entreprises contribué à l'open source, ou cesser l'utilisation de l'open source ?
Verrons nous une moindre utilisation de java ? la fin des libraires partagées ?

Rien du tout. C'est une tempête dans un verre d'eau. shellshock n'a pas tué linux et heartbleed n'a pas tué OpenSSL. C'est fou cette capacité à oublier que c'est quelque chose de régulier et non pas la fin du monde.

L'open source en question ?

Comme à chaque fois on redécouvre qu'on a laissé 1 à 5 développeurs la charge d'un truc dont beaucoup de monde dépend.

Maven en question ?

C'est pas maven en particulier qui a le moindre problème, c'est la gestion de dépendance. On reproche à maven de ne pas virer les versions incriminer aujourd'hui, on reprochait à npm de permettre de virer des paquets il y a 5 ans. On se détend un peu.

Déjà mettre à jour la bibliothèque n'est pas la seule façon de mitiger la faille. Certains projets pour des raisons qui leurs sont propre ne peuvent pas mettre à jour le code aussi facilement, dans ce cas mettre en place d'autres contremesure (ou avoir toujours eu ses contremesures) fais le taff. Ça n'empêche pas de mettre à jour la bibliothèque, mais pas besoin de le faire dans l'urgence.

Bref je trouve que ça a excité beaucoup de monde qui dans la tempête n'arrive plus à faire la différence entre des éléments de fond et des éléments qui sont justes classiques. Courage à tout ceux qui subissent la tempête.

Pour moi ça questionne plus notre manière de communiquer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Arg j'ai réveillé le Z… Tu utilise des mots dont tu ne connaît apparemment pas le sens (enfin j'imagine que tu les tords jusqu'à ce qu'il correspondent à ton besoin). M'enfin…

Oulalala que tu es empathique ! Que je me suis fourvoyé ! Oulala ! Quelle illumination ! Tout ce que tu dis à tellement de sens ! Maintenant que tu l'a répété une 256ème fois c'est devenu limpide ! Un vrai appel à la paix et devrais corriger tous les problèmes de vaccination !

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je me permet de pointer sur le wiktionnaire pour mieux expliquer ce que je voulais dire.

C'est pire encore tu pense qu'ils tuent volontairement des gens. On est encore plus loin de l'empathie que je ne le croyais.

Soyons clair je ne suis pas antivaxx, je suis vacciné 3 doses et je recommande à toutes personnes qui n'ont pas de contre indication médicales à le faire.

Mais la peur, la crainte ou autre envers les vaccins ne s'inscrit probablement pas dans une volonté de tuer autrui !

Par exemple il semble que les enjeux de collectivité par rapport aux besoins personnel soit quelque chose d'absolument incompréhensible pour une partie de la population. Mais en quelle part c'est leur faute et en quelle part le fait qu'on présente toujours que des individualités (dans tout : en politique, dans le sport, dans la pop culture,…) ?

C'est un exemple, mais vraiment ta manière de présenter les choses n'amène qu'à une chose : leur stigmatisation ne les poussera pas à se faire vacciner. Ça pousse à les discriminer potentiellement violemment.

Je ne vois aucune forme d'empathie là dedans (et non je n'amalgame pas empathie et bienveillance), mais une dérive très problématique.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et dans sa forme on voit bien que RMS et la FSF ont voulu un truc juridiquement carré …et avec l'effet miroir « gauche de copie »
Avant sa reconnaissance par la jurisprudence française, on avait une adaptation tout aussi longue (v2.1)

Les poursuites entreprises par la FSF n'auraient pas pu se faire avec la MITL ou la WTFL¹ …Les GPL sont donc bien mieux d'un point de vue protection juridique.

Bref c'est pas la taille qui compte.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis triste de voir des projets libres se prendre du FUD (ton commentaire initial c'est "pas j'ai l'impression qu'il est moins rapide", mais "Mozilla délaisse la performance de Firefox") sans plus d'éléments factuels.

Sincèrement je ne comprends pas comment Firefox peut se prendre autant dans la tête par rapport aux autres et dès que gratte un peu les arguments c'est :

• non mais moi je suis convaincu, c'est "les gens" qu'il faut convaincre
• non mais c'est une impression, c'est pas flagrant (=> j'ai rien qui appuie ça mais pourquoi ne pas baver dessus)
• mais j'ai lu le titre d'un article putaclick il y a 3 ans sans avoir lu l'article ou sans aucun recul dessus donc maintenant j'affirme que Mozilla fait n'importe quoi
• firefox 4 c'était vraiment nul

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je pense que comparer netflix où tu es uniquement consommateur et d'autres comme instagram ne relève pas du tout des même usages et donc de même conditions d'utilisation. Je n'ai d'ailleurs aucune idées de ce qu'est les conditions d'utilisation de Microsoft Windows ? Azure ? Office 365 ? Leur boite mail ?

La GPLlv3 est probablement la plus longues des licences libres que je connaisse (et de beaucoup) est-ce que ça en fait la pire ?

Il me semble que simplifier le sujet à une seule métrique n'informe pas tant que ça.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Hum l'article propose ça:

// function
func buildCompleteList(process func(opts *github.ListOptions)(*github.Response, error)) (*github.Response, error) {
    var response *github.Response
    var err error
    ops := &github.ListOptions{}
    for {
        response, err = process(opts)
        if err != nil || response.NextPage == 0 {
            break
        }
        opts.Page = response.NextPage
    }
    return response, err
}

// slot d'appel
var teams []*github.Team
resp, err := buildCompleteList(func(opts *github.ListOptions) (*github.Response, error) {
    newTeams, response, err := client.Organizations.ListTeams(org, opts)
    teams = append(teams, newTeams...)
    return response, err
})

et à vu de nez la version générique serait ça:

// function
func buildCompleteList[T](build func(opts *github.ListOptions)(*T, *github.Response, error)) ([]*T, error) {
    var list []*T
    var err error
    ops := &github.ListOptions{}
    for {
        items, response, e := process(opts)
        if e != nil || response.NextPage == 0 {
            err = e
            break
        }
        list = append(list, items...)
        opts.Page = response.NextPage
    }
    return list, err
}

// slot d'appel
teams, err := buildCompleteList(func(opts *github.ListOptions) (*github.Response, error) {
    return client.Organizations.ListTeams(org, opts)
})

Et du coup je dirais :

• la version closure fait le append avec ou sans l'erreur pas sûr que ce soit toujours une bonne idée
• le slot d'appel est bien plus simple en générique (je ne serait pas surpris qu'il existe du sucre syntaxique pour ce genre de chose), la complexité ajouté dans la méthode générique ne me semble pas insurmontable
• tu as moins de bruit avec la première variable retournée par la méthode non générique dont on ne sait pas trop quoi faire. La méthode générique a un usage plus courant avec un retour de la forme (réponse attendue, erreur)

Après ça n'est qu'une manière de faire, tu peux préférer avoir un itérateur qui va te permettre de t'arrêter là où tu souhaite (ou de commencer à faire des choses avant de tout charger et utiliser une coroutine pour ça va poser des questions de backpressure).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je pense que @kantien et moi avions compris que tu utilisais des méthodes anonymes :

// mon algo
for c in range cellules {
    c()
}

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne vois pas de fermeture dans l'exemple que tu donnes par contre ?

type MyFloat float64

func (f MyFloat) Abs() float64 {
    if f < 0 {
        return float64(-f)
    }
    return float64(f)
}

type Vertex struct {
    X, Y float64
}

func (v *Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

Dans la première méthode Asb() f est capturé et v dans la seconde. C'est comme ça que le l'ai compris, même si je ne suis pas certains qu'on puisse parler de capture pour une référence qui est passée de cette façon à la méthode (comme le self de python).

L'intérêt des fermetures est de faire en sorte que l'algo central ne dépende d'aucun type particulier, même pas un type générique mais de la plus petite interface possible, par exemple func(i, j int) bool. Le code dépendant du type est dans la fonction avec fermeture et propre à chaque utilisation et donc en dehors de la lib.

Ça n'est pas clair pour moi. Tu semble parlait indistinctement de fermeture et d'interface.

// une interface 
type Rendu interface {
    Rendu(i, j int) bool
}

// une lambda
var rendu func(i, j int) bool

Les 2 manières peuvent faire de la capture pour calculer leur rendu comme tu le souhaite.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

soit n'ont pas besoin de ça

Ça fait un peu « dis moi ce dont tu as besoin, je te dirais comment t'en passer ».

Non c'est l'inverse, quand tu écris un programme pour ton besoin, tu ne cherche pas à résoudre la quadrature du cercle. Tu te place dans un prisme limité qui n'a pas vocation à généraliser autant que possible toute problématique.

Même le tri en place du tableau, je doute que ce soit possible (génériquement) en golang avec seulement des interfaces (pour la bonne raison qu'une fonction d'ordre est un opérateur binaire, ce qui n'est pas gérer par les interfaces de base).

C'est juste pas vérifié par le système de type. Ça n'est pas équivalent en terme de vérification, mais beaucoup de code fonctionnent comme ça. Et un certain nombre sont bien plus utilisé et apportent bien plus à leurs utilisateurs que tout ce que j'ai pu écrire donc je ne me permettrai pas de les juger.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis pas certain que ne pas être utilisable avec vi ou emacs limite l'adoption. Les utilisateurs de ces 2 là (ou de leur fork/reimplementation) veulent généralement être bare metal amha et n'ont pas particulièrement envi de voir le web s'inviter.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Sinon ce que tu décris c'est tout simplement le fonctionnement des interfaces jusqu'alors : une interface c'est juste un dictionnaire de fermetures. D'ailleurs pourquoi passer par des fermetures à sa sauce quand le langage fournit nativement un tel mécanisme ?

Je ne sais pas.

Un cas d'exemple simple et générique impossible à rendre, au niveau des types, avec les interfaces (ou fermetures) : le tri d'un tableau. Quand on a un tableau sur un type ordonné (que le type soit ordonné cela s'exprime par le fait qu'il satisfait une certaine interface), alors on peut trier (par ordre croissant ou décroissant) ce tableau : le type de sortie dépend du type de l'entrée, en sortie on a un tableau sur le même type de données qu'en entrée.

Ceux qui passent par cette solution (ça m'est arrivé par exemple parce qu'avec du typage nominal tu n'a pas toujours la possibilité de décrire le type qui te convient) :

• soit n'ont pas besoin de ça
• soit tu te crée que des méthodes et pas des fonctions. Tu modifie les paramètres que l'on te donne plutôt que de retourner quelque chose

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Merci pour ta réponse.

Je comprends surtout si c'est aussi peu de code pour nn_lib.

Pour markdown je ne suis pas sûr de comprendre, la traduction markdown → html est faite dans gmic et pas dans une étape de construction ?

On pouvait s'attendre à cette question :)

Ce n'est pas du tout une critique, c'est simplement pour comprendre. Je n'ai pas d'usage de gmic (parce que je ne fais presque aucun traitement d'image à part du recadrage trivial de temps en temps), donc c'est forcément plus sur l'aspect code que je regarde le projet.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll