Samba vient d'avoir la doc de MS pour SMB.
Évidemment, non que MS soit devenu loyal envers ses concurrents, c'est seulement la conséquence du procès entre MS et l'Europe. Bref, il n'y a que les muscles pour négocier avec MS.
La nouvelle sur linuxtoday (on y trouvera tous les liens pertinants) :
http://www.linuxtoday.com/infrastructure/2007122002526NWMSLL
Avant de partir en troll et regretter que la décision de la commission n'annule pas les brevets (elle ne les valide pas non plus :-)), il faut avoir à l'esprit que ce n'est pas dans un procès qu'on va annuler les brevets. Ça doit être une décision politique (parlement et toussa).
C'est la PFIF (Protocol Freedom Information Foundation) qui a acheté la licence auprès de MS. C'est une organisation créée par la SFLC (lié à la FSF).
En Europe puisque les brevets ne sont pas valides, Samba sera utilisable sans soucis. Ailleurs, ben lisez ceci :
- "The agreement also clarifies the exact patent numbers concerned so there is no possibility of misunderstandings around this issue."
On sait au moins de quoi il en retourne et MS ne pourra pas fuder.
Journal Un grand jour pour Samba
20
déc.
2007
# Re:
Posté par IsNotGood . Évalué à 2.
http://samba.org/samba/PFIF/
[^] # Re: Re:
Posté par patrick_g (site web personnel) . Évalué à 2.
Et après y'a encore des gens qui gueulent contre l'union européenne.
Quelle aurait était la probabilité que Microsoft s'écrase devant la France toute seule et soit contrainte de livrer sa doc ?
[^] # Re: Re:
Posté par Frédéric COIFFIER . Évalué à 2.
http://www.lemonde.fr/web/depeches/0,14-0,39-33685455%407-37(...)
[^] # Re: Re:
Posté par farib . Évalué à 2.
http://www.lemonde.fr/web/article/0,1-0@2-651865,36-992287@5(...)
Microsoft conclut un accord avec Samba, éditeur de logiciel libre
# question
Posté par fabien . Évalué à 1.
du style, "le code que samba a produit est basé sur la doc dont une partie est soumis a brevet" ? je sais qu'en europe ca ne marche pas comme celà (normalement, et jusqu'a present)
mais est-ce que samba ne risque pas d'être retirer de certaines distro en vue d'eviter un risque de proces dans un des autre pay ou les brevet logiciels sont reconnu ?
c'est une vrai question? si c'est n'importe quoi dis moi le (ca me rassurerai!)
Merci.
[^] # Re: question
Posté par IsNotGood . Évalué à 1.
Ben non, car les brevets sont maintenant connues.
> "le code que samba a produit est basé sur la doc dont une partie est soumis a brevet"
Samba ayant l'information, ils ne vont pas être bête au point d'utiliser ces brevets.
> mais est-ce que samba ne risque pas d'être retirer de certaines distro en vue d'eviter un risque de proces dans un des autre pay ou les brevet logiciels sont reconnu ?
Les principaux développeurs Samba (dont Jeremy Allisson) bossent pour Red Hat (depuis que Novell a fait un accord avec MS, ça les a fait fuire chez Red Hat :-)). Red Hat est basé aux USA, fait toujours très attention aux brevets, n'a pas d'accord avec MS. Samba est passé sous GPL v3 ce qui protège de tout accord (improbable) entre MS et Red Hat.
Donc sauf boulette, il ne devrait pas y avoir de problème.
Pour info, Red Hat et Fedora font très attention aux brevets. Par exemple certaines fonctionnalités de Freetype ne sont pas compilées sous Fedora/RHEL car elles ont des brevets. Par contre beaucoup d'autres distributions les activent ...
[^] # Re: question
Posté par IsNotGood . Évalué à 1.
L'accord ne couvre pas l'utilisation des brevets MS. Donc Samba ne va pas à priori utiliser les brevets.
Néanmoins, si les brevets sont implémentés, il y aura très très certainement une options pour activer/désactiver l'utilisation des brevets à la compilation.
L'accord ou seulement la présence de la doc, n'augmente pas les risques. C'est l'inverse puisque maintenant les brevets utilisés par SMB sont clairement identifiés.
Il est actuellement difficilement envisagable que Red Hat fasse un accord avec MS alors que Red Hat s'y est toujours clairement opposé. De plus, Samba étant sous GPL v3, très très probablement MS refusera tout accord (ou alors à des conditions délirantes).
[^] # Re: question
Posté par Marc Poiroud (site web personnel) . Évalué à 1.
Pour ma culture personnel, as tu un lien ou une explication un peu plus précise sur cette phrase ?
merci d'avance.
[^] # Re: question
Posté par Mjules (site web personnel) . Évalué à 1.
http://freetype.sourceforge.net/patents.html
à noter que Mandriva ne l'active pas non plus par défaut (mais il est disponible dans des paquets non officiels sur le PLF).
# heuu
Posté par Snarky . Évalué à 3.
Faut pas s'étonner si les geeks postilionnent ensuite...
# La documentation c'est bien joli, mais...
Posté par MrLapinot (site web personnel) . Évalué à 2.
Après, c'est peut-être différent pour SMB, mais je ne vois pas vraiment de raison. Même si Microsoft joue le jeu, honnêtement, et fourni les documents qu'elle possède, il n'est pas évident que ça suffise (à la limite, il faudrait pouvoir examiner le code, mais ça n'est clairement pas possible).
Si quelqu'un a des infos plus précises...
[^] # Re: La documentation c'est bien joli, mais...
Posté par briaeros007 . Évalué à 2.
Euh alors
A°) la spécif est mal suivi/ le cahier des charges mal bouclé/ le projet mal géré
B°) Le dvp est fait suivant la méthode de LA RACHE
C°) c'est pas de la crypto, c'est un algo propriétaire qui s'approche d'une norme X.
Parce que bon, si tu es pas capable de montrer un tant soit peu que ton algo suit bien la norme (et une norme en crypto, style RSA c'est très précis !) ben il vaut rien ton algo.
[^] # Re: La documentation c'est bien joli, mais...
Posté par MrLapinot (site web personnel) . Évalué à 2.
Un exemple de protocole crypto : http://fr.wikipedia.org/wiki/Needham-Schroeder
Il date de 78, et contient une faille découverte en 95. Juste pour te montrer la non-trivialité des problèmes dans le domaine.
Mais comme tu as l'air d'aimer casser du sucre sur le dos de Microsoft, voici une info exclusive pour toi : les chercheurs qui bossent dessus ont bien fait leur boulot, ils ont trouvé des failles (avec des méthodes formelles et tout et tout), mais ils ne les ont pas divulguées. Du moins pas avant quelques mois, le temps que les clients migrent à la version suivante. Ouais, c'est moche de garder ses découvertes pour soi quand on est chercheur, mais parfois, c'est aussi les impératifs industriels.
[^] # Re: La documentation c'est bien joli, mais...
Posté par briaeros007 . Évalué à 2.
Donc tu implémente bien un algorithme.
Un protocole c'est pas juste "le troisième bit à gauche à 1", il peut y avoir des algorithmes. Et pour éviter le rejeux, c'est pas avec juste une bonne structure de donnée, mais avec les algorithmes sous jacents.
Enfin tout ça pour dire que c'est un sujet très compliqué
J'ai dit que c'était simple ?
Juste pour te montrer la non-trivialité des problèmes dans le domaine.
J'ai dit que c'était trivial ?
Mais comme tu as l'air d'aimer casser du sucre sur le dos de Microsoft,
A parce que oser faire remarquer que si le produit a rien à voir avec la specifs, ben on peut difficilement apporter une preuve quelconque par rapport à la specifs, vu qu'ils sont différents, c'est donc casser du sucre sur le dos de ms ?
Alors oui je casse du sucre sur le dos de ms, et de motorola, et d'ibm, et de ...
Sans rire, faut arrêter deux secondes que parce qu'on ose dire un truc avec ms en COD, alors on est forcément un anti ms primaire!
Désolé si tu estime qu'un programme qui a rien a voir avec les spécifs est un bon programme, surtout si c'est de la crypto, alors tes programmes vont pas êtres très solides.
je te cite :
Or la spécification n'est suivie qu'au tout début, ensuite l'implémentation diverge petit à petit (on patche, on rajoute des fonctionnalités, etc.) et la spécification n'est pas mise à jour.
"On suit pas la spécifs ... mais je vous assure mon truc c'est trop de la balle".
"On suit pas la norme RSA, mais je vous assure, mon truc est encore plus secure. Comment ? Ah ca pas besoin de vérifier contre la specif (ni de vérifier la specif), vu que c'est moi qui vous le dis. Non ca vous convient pas? bizarre"
[^] # Re: La documentation c'est bien joli, mais...
Posté par MrLapinot (site web personnel) . Évalué à 2.
Excuse-moi mais ce que tu racontes n'a (dans le contexte de cette discussion du moins) absolument aucun sens.
Selon Wikipédia : "Dans les réseaux informatiques et les télécommunications, un protocole de communication est une spécification de plusieurs règles pour un type de communication particulier." Par opposition à (même source) : "un algorithme est un énoncé dans un langage bien défini d’une suite d’opérations permettant de résoudre par calcul un problème."
Bref, un algorithme permet de résoudre un problème. Un protocole, c'est une convention pour la communication entre plusieurs personnes, qui apporte certaines garanties sur le déroulement des échanges.
Quant à la question du rejeu, il s'agit d'éviter qu'un message intercepté puisse être renvoyé plus tard, comme si c'était un message neuf (pense à un ordre de virement : même si le protocole est parfaitement sécurisé, si ton message est intercepté et renvoyé 10 fois par l'attaquant, bah tu risques d'avoir moins d'argent que prévu sur ton compte).
Il peut s'agir d'un bon programme, simplement on va avoir du mal à le prouver. Je bosser actuellement sur un précompilateur C pour programmes coopératifs qui est une vraie tuerie en matières de performances ; c'est un excellent programme. Mais on n'a pas encore prouvé que son fonctionnement est correct. D'un côté on la qualité, de l'autre la preuve de cette qualité.
Il faut quand même savoir que presque aucun logiciel de crypto n'est prouvé formellement - les algorithmes et protocoles sous-jacents peuvent éventuellement l'être (et encore pas toujours), mais le logiciel en lui-même, c'est quelque chose de très nouveau et exceptionnel. Cela n'a pas empêché d'avoir des logiciels de qualité jusqu'ici (comme ssh par exemple).
Là encore, tu confonds. Norme et spécification sont deux choses très différentes. D'un côté, tu as des standards adoptés et reconnus par la communauté (industrielle, scientifique, etc.). De l'autre, tu as des choix de conception interne. Maintenir l'adéquation entre le programme et la spécification, c'est comme entre le programme et la documentation : c'est un boulot énorme, et rarement mené à bien.
Naturellement, ce serait mieux que les deux aillent ensemble. Et c'était précisément le sens de mon premier message.
Mais merci de ne pas tout déformer. A priori (je n'ai aucune information là-dessus), quand MS dit "on utilise RSA à cet endroit", ils utilisent RSA conformément au standard. Et ils ne créent pas leurs algorithmes de cryptographie dans leur coin, juste pour se marrer.
Par contre, en ce qui concerne les protocoles (tu noteras la différence), ils ont à faire face à de nouveaux besoins, pour lesquels il n'y a ni norme, ni standard : ils sont donc logiquement amenés à créer de nouveaux protocoles, selon des spécifications internes, et parfois, ça évolue.
J'espère avoir été plus clair cette fois-ci.
[^] # Re: La documentation c'est bien joli, mais...
Posté par briaeros007 . Évalué à 2.
Et en quoi un protocole ne peut pas se baser sur un ou plusieurs algorithmes ?
...
Tiens question conne, les protocoles de routages, ils reposent ou pas sur des algorithmes de routages ?
Les protocoles censé d'assurer l'intégrité d'une communication, ils reposent ou pas sur des algorithmes de détection et de correction d'erreur ?
Les protocoles de chiffrements (ssl par exemple), ils reposent ou pas sur des algorithmes de chiffrements?
Quant à la question du rejeu, il s'agit d'éviter qu'un message intercepté puisse être renvoyé plus tard, comme si c'était un message neuf (pense à un ordre de virement : même si le protocole est parfaitement sécurisé, si ton message est intercepté et renvoyé 10 fois par l'attaquant, bah tu risques d'avoir moins d'argent que prévu sur ton compte).
Merci de la précision, ce que je savais déjà, mais je ne vois pas en quoi ca infirme ce que je disais. Ca confirme meme plutot vu que tu repose sur un système pour éviter le rejeu. Ce système reposant forcément (en partie) sur un algorithme quelconque (ca peut être une simple signature d'un timestamp, ce qui est déja constituf d'un algorithme).
Maintenir l'adéquation entre le programme et la spécification, c'est comme entre le programme et la documentation : c'est un boulot énorme, et rarement mené à bien.
Je n'ai jamais dis le contraire d'ailleurs. Cf ma remarque sur IBM & co.
Simplement si tu n'arrive déjà pas a avoir une spécif à jour, alors savoir si ton code correspond encore à la norme ou pas, sachant que la norme est censé être à un niveau encore supérieur à la specif, t'es pas sortie de l'auberge.
quand MS dit "on utilise RSA à cet endroit", ils utilisent RSA conformément au standard. Et ils ne créent pas leurs algorithmes de cryptographie dans leur coin, juste pour se marrer.
Je m'en doute bien.
Pour avoir du implémenter le systeme de signature de RSA (projet de fin d'année), c'est un truc très guidé, mais aussi assez compliqué (ah les joies du PSS. A ce propos, la norme pkcs#1 décrit à la fois l'algorithme de chiffrement , et le protocole pour chiffrer les données ;) ). où il y a des conversions entre chaines de caractères qu'il faut lire comme des chaines de caractères, puis comme un nombre entier,
Avec pour ma part des modulos qui se trimballent un peu partout pour vérifier que l'on reste bien sur les même données lors des conversions.
Si tu ne suis pas parfaitement bien la norme (ou la spécif initiale), alors ca peut marcher, mais tu peux avoir un effet de bord que tu ne vois pas dans la norme (qui elle a été vérifiée) et qui peut conduire à une perte de sécurité : Tu obtient un algorithme à la sécurité "propriétaire" : il est différent de la norme, et bien souvent il n'a pas été vérifié.
Les spécifications permettant justement de faire le lien entre ce qui a été (ou voulu être) fait, et la norme que l'on doit suivre.
Si elles ne sont pas a jour, comment peut tu vérifier que ce que tu as bien fait ce que tu as voulu faire ;)
Et ils ne créent pas leurs algorithmes de cryptographie dans leur coin, juste pour se marrer.
MS a pas besoin , ils sont potes avec la NSA (NSA_KEY ;))
:P
Par contre, en ce qui concerne les protocoles (tu noteras la différence), ils ont à faire face à de nouveaux besoins, pour lesquels il n'y a ni norme, ni standard : ils sont donc logiquement amenés à créer de nouveaux protocoles, selon des spécifications internes, et parfois, ça évolue.
Le manque de spécification nuit tout autant à la prouvabilité et donc à la sécuritée.
Encore une fois je n'ai JAMAIS dis que c'était facile (ni de prouver, ni de créer,ni de maintenir les specs, etc...).
De plus, comme tu le fais remarquer : ils ont en face des besoins nouveaux. Leur réponse est donc nouvelle, et avec une grande chance, pas décortiqué par la communauté internationale des cryptographes.
Enfin, quant tu fais évoluer quelquechose, tu peux rajouter des bugs sans trop de difficulté. Si les specs sont pas à jour, les tests sans doute pas, et le process de Q&A ne doit pas être super efficient (manque de specs, de test, ...).
J'espère avoir été plus clair cette fois-ci.
Oui, et je t'en remercie ;)
[^] # Re: La documentation c'est bien joli, mais...
Posté par MrLapinot (site web personnel) . Évalué à 2.
Il peut tout à fait.
Je connais moins bien ce domaine, mais je dirais oui. Tu as un algorithme (pour trouver la route optimale), et un protocole qui décrit les messages que les routeurs s'échangent pour mener à bien cet algorithme - mais à un même algo peuvent correspondre plusieurs protocoles, éventuellement.
Pas forcément, mais ceux qui sont efficaces le font (exemple de protocole con qui n'utilise aucun algorithme de détection d'erreur : renvoyer en écho tout ce qu'on reçoit pour confirmation).
Oui. Plus précisément, tu as (par exemple) des protocoles d'échanges de clefs qui reposent sur des algorithmes de chiffrements. En général, quand on étudie un protocole en crypto, on suppose à la base que les schémas de chiffrement sous-jacents sont parfaits (éventuellement avec une certaines probabilité d'être cassés).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.