Journal les nouveautés de KDE 3.4

Posté par  (site web personnel) .
Étiquettes : aucune
0
3
déc.
2004
un petit article ( http://osdir.com/Article2722.phtml(...) ) qui liste quelques une des nouveautés de la prochaine release de KDE.

Deux questions pour ceux qui savent :

1) pourquoi la page est en .phtml ? c'est quoi ce truc ?

2) parmi les nouveautés y'a QCA - A complete cryptography architecture : quelqu'un a t'il des renseignements supplémentaires ? pourquoi ne pas utiliser l'API crypto du noyau qui doit être bien mieux testé ?

  • # bout de réponses

    Posté par  . Évalué à 5.

    Salut !

    alors juste pour répondre à ta 2eme question, QCA est une lib de crypto développée à l'origine par les ptits gars de Psi (le client jabber en Qt) et donc intégrée à psi. Ça doit bien faire un an qu'elle existe, et ça marche plutôt bien apparemment. Elle est développée avec Qt ce qui explique sans doute ce choix aussi.

    Voilà pour les ptites infos ;)

    • [^] # Re: bout de réponses

      Posté par  (site web personnel) . Évalué à 5.

      merci pour ta réponse.
      je m'y connais pas trop donc je voudrais pas dire de conneries mais ça me semble un peu louche ce projet QCA.
      Dans le monde de la crypto on essaye habituellement d'être le moins compliqué possible pour ne pas augmenter les risques d'erreurs ou de bugs ou de points faibles dans les protocoles...hors QCA ajoute toute une couche QT au dessus d'un noyau linux qui dispose déja d'une API crypto très très complète.
      je ne doute pas que QCA facilite le travail des devs KDE mais il me semble que dans le domaine spécifique de la crypto c'est dangereux.

      • [^] # Re: bout de réponses

        Posté par  . Évalué à 3.

        Oui mais Qt à ausi pout but (et y arrive très à ce qu'il me semble) d'être multi-plates formes. Alors avec la crypto du noyau, tu vas être bien sous windows ou MacOS.

      • [^] # Re: bout de réponses

        Posté par  . Évalué à 0.

        au dessus d'un noyau linux


        Euh, je ne savais pas qu'on pouvait acceder a l'API crypto de linux depuis l'userland. Tu aurais des pointeurs la dessus, ca m'interresse.

    • [^] # Re: bout de réponses

      Posté par  (site web personnel) . Évalué à 4.

      Je me permet aussi d'ajouter que QCA n'est qu'une facade devant des bibliothèques qui font effectivement de la crypto, par exemple libopenSSL ou libNSS.

      En outre j'aurai plutôt tendance à penser qu'il vaut mieux éviter de demander quelque-chose au noyau quand cela peut être fait en userland.

      Enfin, l'API crypto du noyau ne sait pas tout faire entre autre ASN.1, support X.509, pkcs#11, pkcs#12... (bon j'avoue je ne suis pas sûr de ma liste mais l'idée est là)

  • # Et pour 1!

    Posté par  (site web personnel) . Évalué à 1.

    Pourquoi pas phtml! En général c'est du php!

  • # 1/

    Posté par  . Évalué à 3.

    .phtml, c'est php.

    Mais juste pour info, sur le web les extensions de fichier ne veulent _absolument_ rien dire, ce sont les mimetypes qui comptent. Ne te bute donc pas trop là dessus (essaye de renommer un document html en .gif, tu verras le résultat)

    • [^] # Re: 1/

      Posté par  . Évalué à 6.

      J'ajouterais qu'à part sur des systèmes préhistoriques et mal foutus, les extensions ne veulent jamais rien dire.

      D'ailleurs, il serait temps que Linux propose quelquechose de plus complet à ce sujet (les applis "devinent" le type du fichier en le regardant). Il n'y a qu'à voir du coté de BeOS ou de MacOS ou le type MIME du fichier est stocké dans un attribut.

      BeOS le faisait il y a 20 ans !

  • # pourquoi ne pas utiliser l'API crypto du noyau ?

    Posté par  . Évalué à 7.

    Parceque KDE n'est pas l'interface graphique de Linux mais un bureau graphique qui fonctionne sous plusieurs systèmes (Linux, les BSD, sous X, sur un PDA, etc.)

    BeOS le faisait il y a 20 ans !

    • [^] # Re: pourquoi ne pas utiliser l'API crypto du noyau ?

      Posté par  (site web personnel) . Évalué à 2.

      grummbbll..........effectivement j'y avais pas pensé et ça explique le pourquoi du comment.
      N'empêche que je trouve ça lourdingue et dangereux. j'espère que c'est juste une sorte de wrapper en QT qui s'occupe de l'abstraction des diverses API noyaux sous-jacentes.

      Pour que je dorme sur mes deux oreilles je souhaite _vraiment_ qu'en dessous de toutes ces couches je retrouve l'API crypto de mon kernel.

      • [^] # Re: pourquoi ne pas utiliser l'API crypto du noyau ?

        Posté par  (site web personnel) . Évalué à 3.

        C'est quoi l'api crypto de linux ? Linux permet de generer des cles RSA ? De faire des verifications de signature RSA ? D'encrypters des donnes en triple DES et AES ?

        ==> NON !

        Je ne sais pas de quelle api crypto tu parles, mais clarement, linux ne suffit pas pour coder une application avec de la crypto. Il faut utiliser utiliser une lib qui code tous les algos. En general, on utilise openssl (www.openssl.org) mais rien n'empeche de le re-ecrire.

  • # Sinon pour les trolleurs:

    Posté par  (site web personnel) . Évalué à 1.

    Merging with Safari fixes continues, alone with new work and fixes by KDE developers.

    Sinon en vrac:
    - Usage of GCC 3.4 symbol visibility functionality for much improved application startup time.
    Il me semblait que c'etait gcc 4.0? (ou 3.4 patché)
    Mais bon n'empeche que c'est une bonne idée

    KDM theme support.
    Deja vu dans un journal précendent mais ca fait plaisir de le rapeller :)

    - Empty password support (password-less wallets) in KWallet.
    J'espere qu'on poura désactiver ca.....

    Support for setting the clock with NTP.
    Ca serait pas plutot au niveau de la distrib de faire ca?
    Enfin bon ca peut quand meme etre une bonne idée

    - Completely redesigned, more flexible trash system.
    Mmmmmm à voir, mais personnellement je prefererais qu'ils utilisent recycled4linux 'fin bref

    - Support for Apple's DNS based service discovery.
    OO? Je croyais que c'etait un zeroconf ?
    Remarque d'apres mes souvenirs c'est pas encore supporté par KDE donc c'est juste un nom différent.

    - Subversion support.
    Que dire à ce propos? :)

    • [^] # Re: Sinon pour les trolleurs:

      Posté par  (site web personnel) . Évalué à 1.

      Quand ils disent merging with safari je suppose qu'ils parlent de KHTML et de rien d'autre ?

      sinon pour ton appel au troll sur Subversion je ne trouve rien d'autre à dire que ARCH POWAAAAAA !!!!!

    • [^] # Re: Sinon pour les trolleurs:

      Posté par  (site web personnel) . Évalué à 5.

      - Empty password support (password-less wallets) in KWallet.
      J'espere qu'on poura désactiver ca.....

      En fait ça a été un souhait émis sur le bugzilla de KDE. Il a été codé contre la volonté des développeurs mais a été fait malgré tout face au nombre de votes.

      Support for setting the clock with NTP.
      Ca serait pas plutot au niveau de la distrib de faire ca?
      Enfin bon ca peut quand meme etre une bonne idée
      Gnome 2.8 le fait déjà. Après qu'on utilise ntpdate en service ou une appli graphique de la distrib ou de l'environnement de bureau, les droits root sont de toute façon nécessaires et c'est juste une couche visuelle.

      - Support for Apple's DNS based service discovery.
      OO? Je croyais que c'etait un zeroconf ?
      Zeroconf / DNS-SD / Apple mDNSResponder c'est trois noms pour la même chose en fait :) Genre Firewire, i-Link et IEEE 1394. Il est question d'ailleurs en ce moment même de déplacer kdnssd de kdenonbeta vers kdelibs.

      Sinon la liste des fonctionnalités devant normalement être ajoutées à KDE 3.4 se trouve ici :

      http://developer.kde.org/development-versions/kde-3.4-features.html(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.