> Rah la la tu m'a l'air particulièrement stressé.
Oui mais rien à voir avec linuxfr. Je suis sur un programme salement compliqué depuis des semaines et tout est en chantier. Je m'arrache les cheveux par poignés. M'enfin, le bout du tunnel n'est pas loins.
> Pour tout t'avouer, j'ai pas pigé grand chose de ton histoire de signature de paquet qui du coup permet des miroirs
Voilà le problème. Imaginons qu'Adobe ne signe pas ses paquets ;
- Adobe met un paquet flash à disposition sur un serveur https super sécurisé.
- Adobe autorise que les mirroirs à copier le paquet flash afin de soulager son serveur super sécurisé.
- Un mirroir peu sécurisé à le paquet flash.
- Un cracker profite du fait que le mirroir est peu sécuriser pour cracker le paquet flash (le remplacer avec un qui a un trou de sécurité par exemple).
- Je downloade le paquet flash cracké sur le mirroir.
- Je suis baisé (et je ne sais pas par qui)
Par contre, si le paquet est signé, je ne suis pas baisé. Mais imaginons que je sois baisé (le paquet a un virus), je sais par qui (Adobe). Donc je peux lui casser la gueule (ou seulement faire un procès). C'est très très important une signature gpg ! C'est comme une signature sur un chèque mais en moins violable.
Le paquet adobe-release.rpm contient la signature Adobe et le fichier de configuration yum.
Le fichier de configuration yum : [adobe-linux]
name=Adobe Systems Incorporated
baseurl=http://linuxdownload.adobe.com/linux/$basearch/
enabled=1 gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
Une clée n'ait importé dans la base rpm qu'avec confirmation de l'utilisateur. C'est évidemment à l'utilisateur de dire si telle ou telle clée (ou fournisseur (de paquet ici)) est de confiance. C'est de sa seule responsabilité.
Imaginons que le paquet sur free.fr a été cracké. Lorsque je fais "yum update", yum va voir qu'il y a un nouveau paquet flash (sur mirroir.free.fr). Yum va donc le downloader et tenter l'installation. Mais l'installation va échouer car le paquet n'a pas la bonne signature (donc il n'a pas été fait par Adobe).
> Mais ça à l'air vachement bien pour les fedora/red hat
Ça me semble assez facile à réaliser pour les autres distributions.
> Mais arrêter de rebaver les mêmes conneries. C'est du xml DONC tout le monde peut lire...
Tu n'as pas compris. Un fichier xml est lu par un parser xml. S'il y a un champ supplémentaire inconnu, l'appli peut l'ignorer (c'est ce que fait Firefox etc).
> Ce serait un .ini on saurait pas ?
Il n'y a pas qu'un parser de fichier .ini. Ajoute un champ à un fichier .ini, et tout peu exploser. C'est au cas par cas.
> Ce serait un binaire avec une explication de comment il marche on saurait pas ?
Ça serait un truc qui fait comme xml pour les fonctionnalités qu'on demande à xml, ça le ferait. Évidemment. Il n'y a rien d'incoutournable.
> Ce serait un fichier text quelconque on saurait pas ?
Un fichier xml est un fichier text (sauf quelques exceptions). Son intérêt est qu'il n'est pas un fichier text quelconque. Mais un fichier dont les données sont structurés et accessibles. Pas de code spécifique à faire (à la fichier .ini), il suffit d'avoir un parser xml (qui répond à des spec très précises). Il y a aussi des outils pour faire des requêtes dans les fichiers xml, etc...
Évidemment, ça n'empêche qu'un fichier xml (qui a un format) soit rigoureusement documenté. C'est la même chose pour un fichier ini, etc...
Tu peux mettre tes données dans un fichier text quelconque. Mais essai avec un base de donnée. Tu verras, c'est plus cool.
> Tu peux faire un fichier xml illisible.
Tu peux faire un fichier .ini ou text quelconque illisible. Je ne vois pas où tu veux en venir. Tu n'as pas besoin d'xml pour ça.
Et illisible n'est pas le bon terme. Le fichier est forcément lisible. C'est ininterprétable le bon terme.
Fichier xml ou fichier texte quelconque, il faut une doc qui dit ce que signifie le contenu. C'est comme ça pour tout contenu. "Vin" signifie : "c'est un liquide, pas trop nocif, et qui fait rire". "Vin" a une signification, car on lui a donné une signification. C'est idem pour un fichier text quelconque ou pour un fichier xml.
> Oui, il y a des avantages au xml, mais pas ceux là. Merci donc de ne pas les citer comme une conséquence logique.
Documente toi, et prend un peu de recul.
> Et a mon sens c'est une mauvaise chose
Je trouve que c'est une bonne chose.
> maintenant ça c'est subjectif.
Idem pour moi.
> Donc qu'ils soient ou non dans yum je vois pas exactement le rapport.
Le format des dépôts yum n'a pas été fait pour être spécifique à rpm/yum.
Dès l'origine il a été pris en compte que le format de dépots yum supporte les paquets .deb. Des développeurs debian ont participés aux discussions initiales sur le format de dépôt yum mais ça n'a pas abouti de façon concrête.
Notons que le format apt marche pour rpm et deb. On trouvait beaucoup de dépot au format apt pour Red Hat/Fedora il y a quelques années. Maintenant on trouve rarement du apt pour les dépôt Red Hat/Fedora.
> Si ton cracker pose son code directement dans flash sans que le dev le vois, tu l'as dans l'os.
Ben non.
> Dans tous les cas quand tu accepte un code sans l'avoir entierement compris (et même comme ça) tu t'expose à un danger potentiel.
Tu veux me faire croire que tu comprends tout le code de ton OS ?
Un peu de sérieux...
[^] # Re: Et sous Debian, y'en a encore moins à faire
Posté par IsNotGood . En réponse au journal Flash tar.gz rpm yum. Évalué à 1.
Oui mais rien à voir avec linuxfr. Je suis sur un programme salement compliqué depuis des semaines et tout est en chantier. Je m'arrache les cheveux par poignés. M'enfin, le bout du tunnel n'est pas loins.
> Pour tout t'avouer, j'ai pas pigé grand chose de ton histoire de signature de paquet qui du coup permet des miroirs
Voilà le problème. Imaginons qu'Adobe ne signe pas ses paquets ;
- Adobe met un paquet flash à disposition sur un serveur https super sécurisé.
- Adobe autorise que les mirroirs à copier le paquet flash afin de soulager son serveur super sécurisé.
- Un mirroir peu sécurisé à le paquet flash.
- Un cracker profite du fait que le mirroir est peu sécuriser pour cracker le paquet flash (le remplacer avec un qui a un trou de sécurité par exemple).
- Je downloade le paquet flash cracké sur le mirroir.
- Je suis baisé (et je ne sais pas par qui)
Par contre, si le paquet est signé, je ne suis pas baisé. Mais imaginons que je sois baisé (le paquet a un virus), je sais par qui (Adobe). Donc je peux lui casser la gueule (ou seulement faire un procès). C'est très très important une signature gpg ! C'est comme une signature sur un chèque mais en moins violable.
Le paquet adobe-release.rpm contient la signature Adobe et le fichier de configuration yum.
Le fichier de configuration yum :
[adobe-linux]
name=Adobe Systems Incorporated
baseurl=http://linuxdownload.adobe.com/linux/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
Une clée n'ait importé dans la base rpm qu'avec confirmation de l'utilisateur. C'est évidemment à l'utilisateur de dire si telle ou telle clée (ou fournisseur (de paquet ici)) est de confiance. C'est de sa seule responsabilité.
Si dans mon fichier de configuration yum j'ai :
baseurl=http://mirroir.free.fr/linux/Adobe/$basearch/
Imaginons que le paquet sur free.fr a été cracké. Lorsque je fais "yum update", yum va voir qu'il y a un nouveau paquet flash (sur mirroir.free.fr). Yum va donc le downloader et tenter l'installation. Mais l'installation va échouer car le paquet n'a pas la bonne signature (donc il n'a pas été fait par Adobe).
> Mais ça à l'air vachement bien pour les fedora/red hat
Ça me semble assez facile à réaliser pour les autres distributions.
> Mais arrêter de rebaver les mêmes conneries. C'est du xml DONC tout le monde peut lire...
Tu n'as pas compris. Un fichier xml est lu par un parser xml. S'il y a un champ supplémentaire inconnu, l'appli peut l'ignorer (c'est ce que fait Firefox etc).
> Ce serait un .ini on saurait pas ?
Il n'y a pas qu'un parser de fichier .ini. Ajoute un champ à un fichier .ini, et tout peu exploser. C'est au cas par cas.
> Ce serait un binaire avec une explication de comment il marche on saurait pas ?
Ça serait un truc qui fait comme xml pour les fonctionnalités qu'on demande à xml, ça le ferait. Évidemment. Il n'y a rien d'incoutournable.
> Ce serait un fichier text quelconque on saurait pas ?
Un fichier xml est un fichier text (sauf quelques exceptions). Son intérêt est qu'il n'est pas un fichier text quelconque. Mais un fichier dont les données sont structurés et accessibles. Pas de code spécifique à faire (à la fichier .ini), il suffit d'avoir un parser xml (qui répond à des spec très précises). Il y a aussi des outils pour faire des requêtes dans les fichiers xml, etc...
Évidemment, ça n'empêche qu'un fichier xml (qui a un format) soit rigoureusement documenté. C'est la même chose pour un fichier ini, etc...
Tu peux mettre tes données dans un fichier text quelconque. Mais essai avec un base de donnée. Tu verras, c'est plus cool.
> Tu peux faire un fichier xml illisible.
Tu peux faire un fichier .ini ou text quelconque illisible. Je ne vois pas où tu veux en venir. Tu n'as pas besoin d'xml pour ça.
Et illisible n'est pas le bon terme. Le fichier est forcément lisible. C'est ininterprétable le bon terme.
Fichier xml ou fichier texte quelconque, il faut une doc qui dit ce que signifie le contenu. C'est comme ça pour tout contenu. "Vin" signifie : "c'est un liquide, pas trop nocif, et qui fait rire". "Vin" a une signification, car on lui a donné une signification. C'est idem pour un fichier text quelconque ou pour un fichier xml.
> Oui, il y a des avantages au xml, mais pas ceux là. Merci donc de ne pas les citer comme une conséquence logique.
Documente toi, et prend un peu de recul.
> Et a mon sens c'est une mauvaise chose
Je trouve que c'est une bonne chose.
> maintenant ça c'est subjectif.
Idem pour moi.
> Donc qu'ils soient ou non dans yum je vois pas exactement le rapport.
Le format des dépôts yum n'a pas été fait pour être spécifique à rpm/yum.
Dès l'origine il a été pris en compte que le format de dépots yum supporte les paquets .deb. Des développeurs debian ont participés aux discussions initiales sur le format de dépôt yum mais ça n'a pas abouti de façon concrête.
Notons que le format apt marche pour rpm et deb. On trouvait beaucoup de dépot au format apt pour Red Hat/Fedora il y a quelques années. Maintenant on trouve rarement du apt pour les dépôt Red Hat/Fedora.
> Si ton cracker pose son code directement dans flash sans que le dev le vois, tu l'as dans l'os.
Ben non.
> Dans tous les cas quand tu accepte un code sans l'avoir entierement compris (et même comme ça) tu t'expose à un danger potentiel.
Tu veux me faire croire que tu comprends tout le code de ton OS ?
Un peu de sérieux...