[SPIP Zone] CFG, nouvelles fonctionnalités ?

[Fredo_d_o]

Bonjour à tous

Voilà, continuant à travailler un peu avec CFG,
je me rends compte que certaines fonctionnalités
pourraient apporter un petit plus, voici aux 2 ou 3
choses auxquelles j'ai pensé :

1. Cryptage

Je me suis apperçu que CFG mémorisait toutes les données
au format string "lisible", même lorsqu'on utilise
un champ de type "password", les données sont en clair
dans l'entrée "spip_meta" correspondante...

Il serait peut-être intéressant de pouvoir crypter
les données un peu sensibles ou confidentielles,
comme le coordonnées personnelles, N° carte crédit, etc.

Une méthode qu'on pourrait utiliser est d'implémenter
une nouvelle balise #REM de paramétrage de CFG, qui
listerait les champs à crypter, du genre :

[(#REM) crypt=nom,pass,carte_credit]

Du coup, CFG saurait quels sont les champts dont la valeur
doit être cryptée avant d'être sauvegardée dans le "spip_meta".

Bien-sûr, il faut pouvoir faire le décryptage au moment
de présenter les infos dans le formulaire, mais je pense
qu'une fois la méthode de crypate mise en place, le décryptage
ne devrait pas trop poser de problème... enfin, je suppose

2. Arborescence

Il serait utile, au moment du développement du moins,
de pouvoir visualiser l'arborescence des données mémorisées
dans l'entrée "spip_meta", histoire de bien vérifier si
tout fonctionne correctement...

Pour ma part, à la fin des formulaires, je fais un sauvage
et pas très sthètique :

[(#CONFIG{meta}|unserialize|print_r{true})]

Bon, ça marche, mais je me disais que CFG pourrait proposer
quelque chose par défaut, d'un peu plus évolué, comme des
listes dépliables par exemple...

Enfin, ceci n'est pas une fonctionnalité vraiment indispensable,
mais elle apporterai un peu de confort lors du développement.

3. Automatisation

Lorsqu'on souhaite configurer un certain nombre d'éléments
du même type, on mémorise autant de "casiers" ou "cfg_id"
qu'éléments à traiter... jusqu'à là tout est bon.

Mais, si on souahite par exemple appliquer un même changement,
ou carrément la même config à tous les éléments mémorisés
à l'intérieur d'un "casier", on doit le faire individuellement
pour chaque élément...

Je pensais que CFG pourrait proposer un mécanisme qui
permettrait d'appliquer une configuration, ou une modification,
de manière automatique à l'ensemble des configs mémorisées
dans un "casier", histoire de simplifier la gestion
de la configuration d'un grand nombre d'éléments...

Mais alors comment faire ? ... ça, j'en sais fichtre rien :-/

à+
Fredo

Voilô... pas mieux pour le moment

[19eb0d0ad6f2ebee089f]

FredoMkb a écrit :

Bonjour à tous

1. Cryptage

Une méthode qu'on pourrait utiliser est d'implémenter une nouvelle balise #REM de paramétrage de CFG, qui listerait les champs à crypter, du genre :

[(#REM) crypt=nom,pass,carte_credit]

Du coup, CFG saurait quels sont les champts dont la valeur doit être cryptée avant d'être sauvegardée dans le "spip_meta".

Bien-sûr, il faut pouvoir faire le décryptage au moment de présenter les infos dans le formulaire, mais je pense qu'une fois la méthode de crypate mise en place, le décryptage ne devrait pas trop poser de problème... enfin, je suppose

Justement, il est facile de crypter avec la méthose que tu proposes, mais le décryptage n'est pas possible car les fonctions de lecture de la table spip_meta, définies dans cfg_options.php ne chargent pas les fonds des formulaires ; et pour cause, une entrée de la table peut être modifiée par plusieurs fonds sans problème.

Il faudrait à ce moment là, ajouter un champ en plus pour chaque entrée tel que si on veut crypter 'pass', on ajoute une entrée 'pass_crypt'=true, testée à chaque fois lors de la lecture.

Ca me semble pas utile. Par contre, un mot de passe que tu peux décrypter, je vois pas l'intérêt... En md5, une fois que c'est crypté ; tu peux pas le décrypter... c'est tout l'intéret... Donc, on n'a peut être pas besoin de savoir qui est à décrypter ou non ?

Par ailleurs, je me demande si CFG est l'outil approprié pour enregistrer des mots de passes et ce genre de choses... Si c'est pour compléter des informations sur les auteurs, il y a un plugin 'inscription2' je crois ; sinon, il y a aussi form&table qui fait parait-il des choses formitables ; pardon, formidables...

MM.

[anon3638017]

heu, moi non plus je vois pas trop l'interret d'avoir un champ que
tout le monde sait decrypter, à ce moment là, c'est comme s'il n'etait
pas crypté...

Au mieux, il faudrait une fonction pour tester un champ "contre" un
champ crypté dans la conf et qu'il nous dise si c'est juste ou pas (un
peu comme SPIP le fait maintenant)...

Pierre

On 9/30/07, Matthieu Marcillaud <marcimat@free.fr> wrote:

FredoMkb a écrit :
> Bonjour à tous

> 1. Cryptage

> Une méthode qu'on pourrait utiliser est d'implémenter
> une nouvelle balise #REM de paramétrage de CFG, qui
> listerait les champs à crypter, du genre :
>
> [(#REM) crypt=nom,pass,carte_credit]
>
> Du coup, CFG saurait quels sont les champts dont la valeur
> doit être cryptée avant d'être sauvegardée dans le "spip_meta".
>
> Bien-sûr, il faut pouvoir faire le décryptage au moment
> de présenter les infos dans le formulaire, mais je pense
> qu'une fois la méthode de crypate mise en place, le décryptage
> ne devrait pas trop poser de problème... enfin, je suppose
>

Justement, il est facile de crypter avec la méthose que tu proposes,
mais le décryptage n'est pas possible car les fonctions de lecture de la
table spip_meta, définies dans cfg_options.php ne chargent pas les fonds
des formulaires ; et pour cause, une entrée de la table peut être
modifiée par plusieurs fonds sans problème.

Il faudrait à ce moment là, ajouter un champ en plus pour chaque entrée
tel que si on veut crypter 'pass', on ajoute une entrée
'pass_crypt'=true, testée à chaque fois lors de la lecture.

Ca me semble pas utile. Par contre, un mot de passe que tu peux
décrypter, je vois pas l'intérêt... En md5, une fois que c'est crypté ;
tu peux pas le décrypter... c'est tout l'intéret... Donc, on n'a peut
être pas besoin de savoir qui est à décrypter ou non ?

Par ailleurs, je me demande si CFG est l'outil approprié pour
enregistrer des mots de passes et ce genre de choses... Si c'est pour
compléter des informations sur les auteurs, il y a un plugin
'inscription2' je crois ; sinon, il y a aussi form&table qui fait
parait-il des choses formitables ; pardon, formidables...

MM.

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

--
Pierre Andrews
Ph.D. Student, The University of York
Ing.info.dipl. EPFL
pierre.andrews@a3.epfl.ch
http://www.cs.york.ac.uk/~pandrews

[Fredo_d_o]

Bonjour

Matthieu Marcillaud <marcimat@...> writes:

FredoMkb a écrit :
> 1. Cryptage

Justement, il est facile de crypter avec la méthose que tu proposes,
mais le décryptage n'est pas possible car les fonctions de lecture de la
table spip_meta, définies dans cfg_options.php ne chargent pas les fonds
des formulaires ; et pour cause, une entrée de la table peut être
modifiée par plusieurs fonds sans problème.

Il faudrait à ce moment là, ajouter un champ en plus pour chaque entrée
tel que si on veut crypter 'pass', on ajoute une entrée
'pass_crypt'=true, testée à chaque fois lors de la lecture.

Ca me semble pas utile. Par contre, un mot de passe que tu peux
décrypter, je vois pas l'intérêt... En md5, une fois que c'est crypté ;
tu peux pas le décrypter... c'est tout l'intéret... Donc, on n'a peut
être pas besoin de savoir qui est à décrypter ou non ?

En effet, décrypter un mot de passe est un peu bête, j'en conviens,
mais comment faire par exemple avec numéro de carte de crédit ?

Il faut bien pouvoir le décrypter à un moment ou à un autre pour
pouvoir l'utiliser... enfin, il me semble...

Par ailleurs, je me demande si CFG est l'outil approprié pour
enregistrer des mots de passes et ce genre de choses... Si c'est pour
compléter des informations sur les auteurs, il y a un plugin
'inscription2' je crois ; sinon, il y a aussi form&table qui fait
parait-il des choses formitables ; pardon, formidables...

Oui, tu as raison, CFG n'a pas vocation, a priori, d'être utilisé pour
mémoriser ce type d'informations, mais elle le permet quand-même,
à l'image du formulaire de test "cfg_testsimple.html" fourni avec le plugin,
il propose de mémoriser un mot de passe, seulement, dans le "spip_meta"
il est sauvegardé en clair, est c'est un peu contraire à l'usage même
d'un mot de passe.

Bref, si CFG n'est pas fait pour ça, il suffit alors, tout simplement,
qu'il ne propose pas ce type de possibilités, mais je ne pense pas
que ce soit la bonne solution, je crois plutôt que c'est une bonne chose
que CFG offre autant de fonctionnalités, ne serait-ce que pour
répondre aux besoins, toujours différents, des développeurs
et utilisateurs...

Seulement, et ce n'est pas une critique du plugin, que j'apprécie
tout particulièrement (vous l'aurez remarqué ), si CFG propose
de pouvoir mémoriser des informations sensibles et/ou confidentielles,
ce qui est le cas, nous devrions réfléchir à un moyen de ne pas
les laisser en clair dans la base, par simple mesure de prudence
(je n'ose pas utiliser le mot "sécurité", ça me fait trop penser
à un monde complètement parano... que les Dieux nous en présèrvent)...

Personnellement, je n'en ai pas besoin pour le moment, j'ai juste
remarqué cette "particularité" en faisant joujou avec les formulaires
de test de CFG... ça m'a un peu étonné... c'est pourquoi j'en ai parlé.

Sinon, la fonctionnalité qui serait vraiment utile pour moi, c'est plutôt
l'automatisation, ou la propagation (je ne sais pas quel terme utiliser),
d'une configuration ou modification à l'ensemble des configs
mémorisées dans le même "casier", ça oui, ce serait vraiment génial
pour le projet sur lequel je bosse en ce moment... mais bon,
je me doute que ça ne doit pas être si simple que ça à concevoir et
à mettre en place... donc, patience, en attendant qu'un dév puisse
se pencher sur cette question... moi, hélas, j'en suis incapable

Merci... à+
Fredo

[JLuc]

FredoMkb a écrit :

En effet, décrypter un mot de passe est un peu bête, j'en conviens, mais comment faire par exemple avec numéro de carte de crédit ?

pas une réponse mais une piste pour chercher avec google : cryptage à clé publique

Il faut bien pouvoir le décrypter à un moment ou à un autre pour pouvoir l'utiliser... enfin, il me semble...

pas forcément. t'as déjà eu une brève réponse d'ailleurs.
un mdp n'est pas intéressant en tant que tel.

ce qui est intéressant c'est de pouvoir vérifier ultérieurement
si l'internaute le connait -> c'est alors supposé être la même personne
que celui qui a déclaré le mdp.

si on a un cryptage même si il est indécryptable,
il suffit de lui appliquer une fois lors de la création du mot de passe,
de mémoriser le résultat (avec cfg par ex) qui bien entendu est illisible.

Quand on veut tester l'identité de l'internaute, ce dernier donne un mdp,
il suffit de lmui applique la MEME fonction de cryptage que lors de l'enregistrement du mdp,
et de voir si le résultat est le même.
On ne compare pas le mdp, mais sa version cryptée.

Ensuite ya aussi des questions critiques de transport du mdp en clair ou non,
etc, d'interception sniffage de réseau, slurping d'url, gloupigloupa de cookie etc,
pour lesquelles les devs spip sont devenus experts...

(je n'ose pas utiliser le mot "sécurité", ça me fait trop penser à un monde complètement parano... que les Dieux nous en présèrvent)...

Tiens, le XXIème devient polythéiste ?
Forcément, le Progrés dégouline...

Sinon, la fonctionnalité qui serait vraiment utile pour moi, c'est plutôt l'automatisation, ou la propagation (je ne sais pas quel terme utiliser), d'une configuration ou modification à l'ensemble des configs mémorisées dans le même "casier", ça oui, ce serait vraiment génial pour le projet sur lequel je bosse en ce moment... mais bon, je me doute que ça ne doit pas être si simple que ça à concevoir et à mettre en place... donc, patience, en attendant qu'un dév puisse se pencher sur cette question... moi, hélas, j'en suis incapable

Je comprend pas bien. Pour info : propagation de quoi quand ?

JL

[Fredo_d_o]

Re...

JLuc <jluc@...> writes:

un mdp n'est pas intéressant en tant que tel.

ce qui est intéressant c'est de pouvoir vérifier ultérieurement
si l'internaute le connait -> c'est alors supposé être la même personne
que celui qui a déclaré le mdp.

si on a un cryptage même si il est indécryptable,
il suffit de lui appliquer une fois lors de la création du mot de passe,
de mémoriser le résultat (avec cfg par ex) qui bien entendu est illisible.

Quand on veut tester l'identité de l'internaute, ce dernier donne un mdp,
il suffit de lmui applique la MEME fonction de cryptage que lors
de l'enregistrement du mdp, et de voir si le résultat est le même.
On ne compare pas le mdp, mais sa version cryptée.

Ok, je comprends... j'imagine donc qu'on utilise une méthode analogue
pour les autres types d'infos sensibles à protéger...

Ensuite ya aussi des questions critiques de transport du mdp en clair ou non,
etc, d'interception sniffage de réseau, slurping d'url, gloupigloupa
de cookie etc, pour lesquelles les devs spip sont devenus experts...

Oui, bon... d'accord, disons que le scryptage avec CFG, en l'occurrence,
serait plutôt pour préserver une certaine confidentialité des évetuelles
données personnelles dans le cadre d'une configuration personnalisée,
je ne pense pas qu'on soit obligé de sortir toute la grosse artillérie
"sécuritaire" pour un tel usage... enfin, j'espère...

> (je n'ose pas utiliser le mot "sécurité", ça me fait trop penser
> à un monde complètement parano... que les Dieux nous en présèrvent)...

Tiens, le XXIème devient polythéiste ?
Forcément, le Progrés dégouline...

À en croire Malraux : "Le XXI" siècle sera spirituel ou ne sera pas"...

Ceci-dit, ce n'est pas demain la veille que tout le monde croira au même Divin,
nous resterons donc encore un bon moment une espèce polythéiste...
et ce n'est pas plus mal après tout !

> Sinon, la fonctionnalité qui serait vraiment utile pour moi, c'est plutôt
> l'automatisation, ou la propagation (je ne sais pas quel terme utiliser),
> d'une configuration ou modification à l'ensemble des configs
> mémorisées dans le même "casier", ça oui, ce serait vraiment génial
> pour le projet sur lequel je bosse en ce moment... mais bon,
> je me doute que ça ne doit pas être si simple que ça à concevoir et
> à mettre en place... donc, patience, en attendant qu'un dév puisse
> se pencher sur cette question... moi, hélas, j'en suis incapable

Je comprend pas bien. Pour info : propagation de quoi quand ?

Exemple basique (pour ne pas dire bête), qui occupe une bonne partie
de mon temps libre en ce moment.

Admétons qu'on souahite mettre en place un système de configuration
d'un squelette, en proposant de personnaliser individuellement
l'apparence de chaque "bloc" important affiché dans le site...

Disons que nous proposons de configurer les options suivantes :
- Affichage du titre = oui/non
- Titre = "Mon joli titre"
- Style = "defaut"

Maintenant, admétons que nous avons une 20e de blocs à configurer,
qui sont mémorisés dans un "casier" nommé par ex. "blocs_nav".

Si jamais je souhaite changer, par exemple, le style du titre de tous les blocs
du "casier" "blocs_nav", pour leur donner un aspect différent des autres
titres affichés sur le site, je dois pour le moment éditer la config de chaque
bloc de ce "casier" afin de changer le style du titre, ce qui peut être
franchement long et fastidieux au bout d'un moment...

Je me disais donc, si on pouvait pas imaginer un mécanisme qui
permettrait d'appliquer une modification à l'ensemble des configs,
semblables donc, existantes dans un "casier"... c'est à ça que je pensais.

Pas vraiment facile à développer à mon avis... vos avis ?

Merci... à+
Fredo

[19eb0d0ad6f2ebee089f]

FredoMkb a écrit :

2. Arborescence

Il serait utile, au moment du développement du moins, de pouvoir visualiser l'arborescence des données mémorisées dans l'entrée "spip_meta", histoire de bien vérifier si tout fonctionne correctement...

Pour ma part, à la fin des formulaires, je fais un sauvage et pas très sthètique :

[(#CONFIG{meta}|unserialize|print_r{true})]

Bon, ça marche, mais je me disais que CFG pourrait proposer quelque chose par défaut, d'un peu plus évolué, comme des listes dépliables par exemple...

Enfin, ceci n'est pas une fonctionnalité vraiment indispensable, mais elle apporterai un peu de confort lors du développement.

Bon, ça c'est fait en version 1.0.10 du plugin CFG :
Une balise #CFG_ARBO permet de faire une liste dépliable dans la partie privée (ie. ?exec=cfg&cfg=...) : il suffit de l'ajouter à son fond.

Par défaut, elle affiche tout spip_meta.
On peut passer des paramètres comme pour #CONFIG : #CFG_ARBO{truc/muche}

Sur une page publique, ça va lister, mais les listes resteront dépliées car je n'ai incorporé le js que dans le head privé.

MM.

[anon3638017]

On 9/30/07, FredoMkb <fredomkbfr@yahoo.fr> wrote:

Oui, bon... d'accord, disons que le scryptage avec CFG, en l'occurrence,
serait plutôt pour préserver une certaine confidentialité des évetuelles
données personnelles dans le cadre d'une configuration personnalisée,
je ne pense pas qu'on soit obligé de sortir toute la grosse artillérie
"sécuritaire" pour un tel usage... enfin, j'espère...

je suppose que justement, CFG serait le bon endroit où centraliser ce
genre de chose, histoire de ne pas le laisser à chaque dev de plugin
(qui s'y connaisse plus ou moins) la gestion de la sécurité des mots
de passe. CFG pourrait voir qu'un champ est password et charger les
aleas et autres securisation js+cookie+php utilisées par SPIP...
enfin, je suis pas expert non plus

C'est vraie, que pour les infos comme les no de cartes, on pourrait
passer md5 dessus pour les "cacher" des autres... ainsi, ils ne
veraient pas directement que c'est un numeros de carte...
On pourrait imaginer un truc plus générique en fait donnant un filtre
à passer sur le champ avant de le stoquer (par exemple, passer une
chaine IP en long pour sauver la place, etc...).

Si jamais je souhaite changer, par exemple, le style du titre de tous les blocs
du "casier" "blocs_nav", pour leur donner un aspect différent des autres
titres affichés sur le site, je dois pour le moment éditer la config de chaque
bloc de ce "casier" afin de changer le style du titre, ce qui peut être
franchement long et fastidieux au bout d'un moment...

Je me disais donc, si on pouvait pas imaginer un mécanisme qui
permettrait d'appliquer une modification à l'ensemble des configs,
semblables donc, existantes dans un "casier"... c'est à ça que je pensais.

hum, ça ressemble bcp au noisetier ce que t'es en train de faire là...

Pierre

[19eb0d0ad6f2ebee089f]

FredoMkb a écrit :

Admétons qu'on souahite mettre en place un système de configuration d'un squelette, en proposant de personnaliser individuellement l'apparence de chaque "bloc" important affiché dans le site...

Disons que nous proposons de configurer les options suivantes :
- Affichage du titre = oui/non
- Titre = "Mon joli titre"
- Style = "defaut"

Maintenant, admétons que nous avons une 20e de blocs à configurer,
qui sont mémorisés dans un "casier" nommé par ex. "blocs_nav".

Tiens, ça me fait penser au projet Noisetier et aussi à kspip...
Il y a pas mal de squelettes aussi sur la zone qui permettent des personnalisations, il faudrait peut être regarder comment ils font...

cfg_id est peut être pas le plus adapté dans ce cas.

Là, tu as un casier dans lequel tu as un cfg_id ? Donc tu peux créer à la volée des blocs... mais je ne vois pas l'intéret avec un squelette, qui lui a des blocs aux noms bien défini. Si tu ajoutes un bloc dans cfg, comment le squelette le sait ? tu testes un #config{toto/casier/nom_du_bloc} ? Pourquoi alors ne pas tout regrouper sur une seule page de configuration, ce serait déjà plus facile pour changer 20 blocs (pas besoin de valider à chaque fois, mais une seule fois pour les 20 ?

Je me disais donc, si on pouvait pas imaginer un mécanisme qui permettrait d'appliquer une modification à l'ensemble des configs, semblables donc, existantes dans un "casier"... c'est à ça que je pensais.

Ce n'est pas un casier qui fait des configs semblables, mais un cfg_id il me semble... M'est avis que ça doit être possible... mais je me sens pas le faire

MM.

[Fredo_d_o]

Re...

Matthieu Marcillaud <marcimat@...> writes:

FredoMkb a écrit :

> Admétons qu'on souahite mettre en place un système de configuration
> d'un squelette, en proposant de personnaliser individuellement
> l'apparence de chaque "bloc" important affiché dans le site...
>
> Disons que nous proposons de configurer les options suivantes :
> - Affichage du titre = oui/non
> - Titre = "Mon joli titre"
> - Style = "defaut"
>
> Maintenant, admétons que nous avons une 20e de blocs à configurer,
> qui sont mémorisés dans un "casier" nommé par ex. "blocs_nav".

Tiens, ça me fait penser au projet Noisetier et aussi à kspip...

Ha... je connais pas ces projets... je vais faire une petite recherche
pour voir de quoi s'agit-il au juste... y'a de la doc ?

Il y a pas mal de squelettes aussi sur la zone qui permettent des
personnalisations, il faudrait peut être regarder comment ils font...

Oui, je n'ai pas encore tout regardé, mais comme j'ai déjà commencé
avec CFG, et que j'ai déjà passé pas mal d'heures dessus, je ne vaut pas
non plus tout remettre en question à ce stade du projet...

> Je me disais donc, si on pouvait pas imaginer un mécanisme qui
> permettrait d'appliquer une modification à l'ensemble des configs,
> semblables donc, existantes dans un "casier"... c'est à ça que je pensais.

Ce n'est pas un casier qui fait des configs semblables, mais un cfg_id
il me semble... M'est avis que ça doit être possible... mais je me sens
pas le faire

Oui, dans ce cas un "cfg_id" semble en effet le plus indiqué, mais
le problème consitant à appliquer une modif à l'ensemble des configs
mémorisées demeure exactement le même qu'avec "casier"...

Quant à te lancer dans un tel développement, je sais que ça ne doit pas
être évident, c'est toujours plus facile à dire qu'à faire, franchement,
ne le fais pas sur ma seule requette, en revanche, s'il y a d'autres
utilisateurs/développeurs qui en formule la même, je pense qu'il sreait
alors intéressant d'étudier la question plus en détail.

J'en profite pour te remercier d'avoir intégré l'affichage du "spip_meta",
ça va être plus "cool" maintenant de voir les données mémorisées !

Par ailleurs, je ne sais pas si les tickets que j'ai ouvert sur la zone
sont consultés, mais je crois que je fais une bêtise en me les assignant
à moi-même... c'est que je n'ai pas encore compris le rôle exact
de cette assignation... enfin, ça viendra

Merci... à+
Fredo

[JLuc]

FredoMkb a écrit :

Maintenant, admétons que nous avons une 20e de blocs à configurer,
qui sont mémorisés dans un "casier" nommé par ex. "blocs_nav".
Si jamais je souhaite changer, par exemple, le style du titre de tous les blocs
du "casier" "blocs_nav", pour leur donner un aspect différent des autres
titres affichés sur le site, je dois pour le moment éditer la config de chaque bloc de ce "casier" afin de changer le style du titre, ce qui peut être franchement long et fastidieux au bout d'un moment...
Je me disais donc, si on pouvait pas imaginer un mécanisme qui permettrait d'appliquer une modification à l'ensemble des configs, semblables donc, existantes dans un "casier"... c'est à ça que je pensais.
Pas vraiment facile à développer à mon avis... vos avis ?

il te suffit probablement de redéfinir le contenu de blocs_nav.css

JLuc

[Fredo_d_o]

JLuc <jluc@...> writes:

il te suffit probablement de redéfinir le contenu de blocs_nav.css

Bien vu, mais là n'est pas la question...

J'étais sûr que quelqu'un allait la tenter celle-là

Fredo