Journal [ubuntu inside] Quickly superbe ... et annonce : freetp et autowifi

Posté par (page perso) .
Tags : aucun
13
8
fév.
2010
Juste un journal, pour dire que j'ai testé et approuvé l'excellent quickly ( https://launchpad.net/quickly ). Qui permet, en gros, de faire du RAD (rapid application deployment ;-). C'est "un peu" un assistance (à la manière django/ror) en ligne de commande, qui permet de créer un template d'application, avec tout qui va bien.
Le codeur a alors juste besoin de coder, et quickly s'occupe de tout le reste jusqu'à la publication du deb signé dans un repository (ppa/launchpad). C'est fichtrement efficace.
Difficile de faire plus pratique, pour développer une application pygtk sous ubuntu. (mais quickly sait et devrait pouvoir gérer d'autres templates, ce n'est pas fermer)

Pour tester la chose, je me suis lancer dans le développement/déploiement de 2 petits outils gpl, en pygtk. (en fait 2 outils maison que je n'avais jamais pris le temps de releaser, et c'est là : où quickly apporte vraiment un plus).

* FreeTP : http://www.manatlan.com/page/freetp
Frontend gtk qui permet d'uploader simplement des fichiers sur le système de partage de fichiers de free : dl.free.fr

* AutoWifi : http://www.manatlan.com/page/autowifi
Application gtk (en systray), qui surveille les SSID wifi, et tente de réaliser l'autologin sur les hotspots libres qui demandent une authentification par formulaire web. Pour l'instant, ça ne gère que les hotspots freewifi et fon (et ça marche !)/ Mais rajouter une gestion de hotspot est simple (système de plugin)

tout ça est dispo dans mon ppa : https://launchpad.net/~manatlan/+archive/ppa

Bon évidemment, pour le coup, c'est assez lié à ubuntu (debian). Mais quickly upload les versions sources, et par conséquent, ça ne devrait pas être trop complexe de packager ça pour d'autres distribs.

Bref, tout ça pour dire, que quickly est vraiment un concept intéressant, et qui facilite réellement les choses.
  • # FreeWIFI : sécurité ?

    Posté par (page perso) . Évalué à 10.

    Bonne nouvelle, je testerai dès que j'aurai un moment.

    Concernant le login automatique sur le formulaire https FreeWIFI, tu vérifies le certificat https pour être sur de ne pas être sur un faux hotspot avant d'envoyer le login/pass ?
    • [^] # Re: FreeWIFI : sécurité ?

      Posté par (page perso) . Évalué à 8.

      non ... mais c'est une idée à cogiter (je le note dans ma todo list)
      • [^] # Re: FreeWIFI : sécurité ?

        Posté par (page perso) . Évalué à 4.

        j'ai un peu regardé entre midi et deux ... j'ai déjà apporté un patch pour vérifier qu'on est bien en https (je mettrai a jour la release ce soir). Mais faudrait également vérifier que le site en question fournisse bel et bien le certificat de free, et appremment c'est possible avec python-twill qui utilise l'excellent mechanize.py ! Donc ça reste jouable, mais ça sera pas pour ce soir
    • [^] # Re: FreeWIFI : sécurité ?

      Posté par (page perso) . Évalué à 1.

      D'ailleurs, si qqu'un a une idée ... comment en python (twill/mechanize) il est possible de valider le certificat (le fingerprint au moins), je suis preneur.
      • [^] # Re: FreeWIFI : sécurité ?

        Posté par . Évalué à 1.

        Il faut faire du plus bas niveau: http://docs.python.org/library/ssl.html

        Il faut que tu t'arranges pour que twill/mechanize accepte une librairie de socket modifié (ou alors tu monkeypatch urllib2).
        • [^] # Re: FreeWIFI : sécurité ?

          Posté par (page perso) . Évalué à 3.

          Puré, j'ai pas mal chercher hier ... sur des solutions m2crypto/pycurl/openssl ...
          Mais je n'avais pas vu cette nouveauté 2.6 ... et il y a apparemment tout ce dont j'aurai besoin.

          Pour résumer : il suffirait que :
          - je récupère le certif (au format PEM) avec ssl.get_server_certificate( ("wifi.free.fr",443) )
          - et que je le compare avec une version embedded
          s'ils sont identiques : je suis assuré d'être au bon endroit
          s'ils sont différents, c'est soit un portail captif, soit free qui a changé de certif

          est-ce suffisant ?
          • [^] # Re: FreeWIFI : sécurité ?

            Posté par (page perso) . Évalué à 2.

            euh ... personne pour me dire si c'est suffisant ou non ?
            le code est fait (avec verif certif fon/freewifi et fonctionne) suis prêt à releaser ...
            suis pas à l'aise avec le ssl, mais je suppute que je récupère, avec ssl.get_server_certificate( ("wifi.free.fr",443) ), le certificat plublic de l'autorité de certif ... un hacker qui mettrait en place une page https, aurait peu de chance de se faire certifier par cette même autorité ... c'est ça ? ... alors est-ce suffisant ?
            • [^] # Re: FreeWIFI : sécurité ?

              Posté par . Évalué à 2.

              Si tu lis la doc de ssl.get_server_certificate, tu verras que tu peux fournir une liste contenant les certificats racines, la fonction se chargera de valider (ou non) ton certificat.
              • [^] # Re: FreeWIFI : sécurité ?

                Posté par (page perso) . Évalué à 2.

                oui, j'ai bien vu ...
                mais je sais pas où trouver le certif racine ...
                du coup, je demandais juste si ma technique (tel que décrite plus haut) est valable et suffisante
                • [^] # Re: FreeWIFI : sécurité ?

                  Posté par . Évalué à 2.

                  Auprès des autorités de certifications, pour verisign/GeoTrust/Thawte c'est par là :
                  https://www.verisign.com/support/roots.html
                  Ils sont également fournis avec la plupart des navigateurs, pour Firefox, c'est dans une base sqlite3 chiffré cert8.db. Tu peux manipuler la base avec les nss-tools ou les bindings python pour nss.

                  > du coup, je demandais juste si ma technique (tel que décrite plus haut) est valable et suffisante
                  Si tu as déjà le certificat racine, pourquoi coder à la main une fonction qui existe déjà ? À moins d'être un spécialiste de la sécurité, je ne me risquerais pas à un tel exercice à ta place.
                  • [^] # Re: FreeWIFI : sécurité ?

                    Posté par (page perso) . Évalué à 2.

                    Ok ...

                    donc si je comprends bien .... pour valider "wifi.free.fr"
                    je prends le CA racine de l'autorité de certif qui a signé le site wifi.free.fr ...
                    (il est là : https://www.geotrust.com/resources/root_certificates/certifi(...) )

                    et j'appel :
                    ssl.get_server_certificate( ("wifi.free.fr",443) , ca_certs = "Equifax_Secure_Global_eBusiness_CA-1.cer" )

                    si ça ne lance pas d'exception (validation failed) : je peux considérer que le serveur est OK ...

                    note : ça me retourne un certif ... qui est le même que si j'appel cette méthode sans l'argument "ca_certs" renseigné ... ça me perturbe un peu ... mais why not

                    tu confirmes ?
                    • [^] # Re: FreeWIFI : sécurité ?

                      Posté par . Évalué à 2.

                      Yup, c'est ça, la différence c'est que si ton certificat n'est pas validé, tu as une exception qui est lancée.
                      • [^] # Re: FreeWIFI : sécurité ?

                        Posté par (page perso) . Évalué à 2.

                        ok, merci à toi d'avoir pris qques instants pour m'expliquer tout ça

                        Je mettrai en place ces validations de certifs freewifi et fon ce soir
                • [^] # Re: FreeWIFI : sécurité ?

                  Posté par (page perso) . Évalué à 2.

                  Le paquet ca-certificates, et tu lis le fichier /etc/ssl/certs/ca-certificates.crt qui contient tous les certificats racines (y compris ceux de cacert.org).

                  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                  • [^] # Re: FreeWIFI : sécurité ?

                    Posté par (page perso) . Évalué à 2.

                    Donc ... là tu me dis, qu'il existe un fichier crt (dans un paquet ca-certificates) qui pourrait être utilisé directement avec cette méthode python ... c'est ça ?

                    Si je comprends toujours bien, ce fichier contient l'ensemble des certificats racine des authorités de certifications.
                    Mais en fournissant cet ensemble de certificat, n'ai je pas plus de chance de tomber sur un gars qui aurait monté son "portail captif fake" en se faisant signer par une de ces autorités (genre cacert.org) ...
                    Et qui du coup, serait valider par la méthode python ...

                    car si je ne fourni qu'un fichier contenant l'unique certificat de l'autorité racine à laquelle je m'attends : j'aurai tendance à trouver ça plus secure .. non ?
                    • [^] # Re: FreeWIFI : sécurité ?

                      Posté par (page perso) . Évalué à 2.

                      Tu as les certificats racines officielles (VeriSign et co) et d'autres comme ca-cert.org. C'est un paquet Debian (je supposes qu'il est présent sur Ubuntu) et c'est le projet Debian qui décide d'inclure ou non un CA.

                      Ensuite je supposes que ton application est prévue pour fonctionner de manière générique. Donc faire confiance aux certificats que ta distribution à choisi d'avoir confiance c'est le meilleur moyen (en laissant la possibilité de changer ça pour l'utilisateur).

                      Finalement tu as aussi tous les certificats séparé dans ce même répertoire. Donc à toi de décider. Mais perso j'aimes bien qu'une application utilise ce que mon système au lieu de réinventer un Xème système. Surtout que l'utilisateur peut librement ajouter ou supprimer des certificats avec dpkg-reconfigure ca-certificates.

                      Mais si ça marche avec ta fonction, j'en sais rien. Mais je supposes qu'elle le fait.

                      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                      • [^] # Re: FreeWIFI : sécurité ?

                        Posté par (page perso) . Évalué à 2.

                        Ok ...

                        "ma fonction" (celle de ssl) et ce fichier CRT, devrait simuler globalement ce que fait un navigateur ... si j'ai bien tout compris.

                        Par conséquent, si un hacker fabrique un "portail captif fake" (pour s'amuser à récuperer les comptes freewifi), et qu'il a réussi à ce faire signer par un des certificats de ce paquet.
                        Je ne le verrai pas ...

                        En potassant wikipedia, sur la notion SSL, et clé privé / clé public. Si je veux être sure de garantir la véracité du portail authentifieur. J'utilise ce qui est dit précédemment, et je récupère les infos du certificats (qui qqpart, est la "clé public" en qqsorte)... et je vais contrôler que le certificat appartient bien à "free.fr" ... et là, si j'ai tout compris, la boucle et bouclé, et je suis certain de l'identité portail ... j'ai tout bon ?
                        • [^] # Re: FreeWIFI : sécurité ?

                          Posté par (page perso) . Évalué à 3.

                          Ok un hacker il va rien faire, parce que les hackers sont gentils. C'est un mauvais usage du mot.

                          Sinon si un méchant arrive à flouter VeriSign, ... ou même cacert.org, tu peux rien faire. Il y a donc X.509 qui définit tous ces trucs avec CA, certificats et tous ça ... Donc soit tu t'en tiens et tu fais confiance aux autorités, soit tu fais ton propre truc. Mais bon je sais pas si tu es le plus qualifié pour décider qui est autorité de certification et qui ne l'est pas. Laisses ça à Debian/Ubuntu/Mozilla/... et contentes-toi de faire une bonne vérification.

                          Ensuite tu dois aussi vérifier les CRL, ta fonction elle le fait ?

                          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                          • [^] # Re: FreeWIFI : sécurité ?

                            Posté par (page perso) . Évalué à 2.

                            > Ensuite tu dois aussi vérifier les CRL, ta fonction elle le fait ?

                            je ne pense pas ...
                            mais je comprends bien qu'il faudrait le faire pour être exhaustif.

                            Je crois que je vais m'en tenir à ma première méthode.

                            Dans un reseau de confiance, je recupere le "certificat serveur" du vrai site https ... (celui signé par l'autorité de certif)

                            et dans autowifi, je vais juste comparer ce certif récupéré tantôt, avec le certificat serveur actuel du site https authentifieur.
                            • [^] # Re: FreeWIFI : sécurité ?

                              Posté par (page perso) . Évalué à 2.

                              je ne pense pas ...
                              mais je comprends bien qu'il faudrait le faire pour être exhaustif.


                              Si tu ne vérifies pas la CRL, ça sert à rien de faire la moindre vérification (à part consommer du temps processeur).

                              Sinon c'est pour le reste, si j'ai bien compris :
                              - Tu prends le certificat du site disons example.com
                              - Quand tu trouves un réseau wifi tu te connectes et tu récupères le certificat du serveur
                              - Tu compares les deux certificats.

                              Si c'est ça, autant rien faire. Le principe de X.509 c'est une autorité qui signe des certificats. Tu dois vérifier si le certificat est signé par une autorité (et en fait toute la chaîne jusqu'au certificat racine (parce qu'un autorité peut avoir signé une autorité qui elle signe une autre autorité qui elle signe un certificat) et si le nom donné par le certificat correspond au nom du serveur.
                              Ensuite tu vérifies la CRL de l'autorité (parce que si le type est un méchant qui a obtenu un certificat qui a ensuite été révoqué, c'est bien de le savoir).
                              Il faut aussi vérifier les contraintes du certificat.

                              Si le but est de vérifier un truc (bidon) pour dire qu'on a vérifié un truc, c'est inutile, autant ne rien vérifier.

                              Regardes la page 15 à 20 pour te rendre compte de toutes les astuces qu'il existe pour attaquer SSL : http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/B(...)

                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                              • [^] # Re: FreeWIFI : sécurité ?

                                Posté par (page perso) . Évalué à 2.

                                > Regardes la page 15 à 20 ...

                                oui, ça fait peur ...
                                mais je ne peux pas non plus me permettre de vérifier toute la chaine, et la CRL aussi ...

                                Je veux bien utiliser les "certif racine des authorités" (du paquet debian) pour faire mon micmac (que tu as bien décris). Ca ajoute la couche "vérification du certif par les authorités". Et s'il venait a être révoqué, le racine dispaitrait du paquet debian (non ?), du coup c'est un peu comme testé la CRL, le côté live en moins.
                                • [^] # Re: FreeWIFI : sécurité ?

                                  Posté par (page perso) . Évalué à 2.

                                  Ok non.

                                  le CA va recevoir des requêtes pour signature (CSR). Un fois ces requêtes signées, cela fait des certificats utilisables pour les fonctions prévues (les contraintes). La différence entre un CA et un certificat c'est le champs CA:FALSE ou CA:TRUE. Un CA c'est un certificat X.509 comme un certificat X.509 serveur, comme un certificat X.509 client, ...
                                  La CRL c'est une liste qui contient les certificats révoqués par le l'autorité de certification, donc le CA. Celle-ci est signée par le CA et va contenir, grosso-modo, ça :

                                  Certificat_avec_ID_1: revoqué: date: ...
                                  Certificat_avec_ID_2: revoqué: date: ...
                                  Certificat_avec_ID_3: revoqué: date: ...

                                  Donc toi tu prends cette CRL, tu contrôle la signature (et la chaîne entière, en vérifiant tout (y compris CRL)).
                                  Et un la revoquation d'un CA c'est un peu différent, si je ne me trompe pas :
                                  Tu signes le nouveau CA avec le CA que tu va révoquer, tu créés une CRL signée avec le nouveau CA contenant l'ancien CA. Mais ça je suis pas sûr.

                                  Donc c'est relativement lourd comme procédure, en effet, mais ne pas la mettre en place, c'est utilisé du SSL pour dire qu'on fait du SSL, mais c'est du SSL sans sécurité.
                                  Tu peux regarder si un outil existe et fait ce travail ou une librairie (qui existe certainement).

                                  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                  • [^] # Re: FreeWIFI : sécurité ?

                                    Posté par (page perso) . Évalué à 2.

                                    En tout cas, merci, car cette discussion m'a apporté énormément d'éclairage sur un sujet qui m'était un peu opaque !!!
                                    Tu as l'air de maîtriser le sujet.

                                    Bon, j'ai releasé un 0.20 infinimment plus secure que les précédentes ! Mais qui ne l'est pas totallement non plus. Mais comme vu dans tes slides : ça ne semble quasiment pas possible de sécuriser tout ça de bout en bout.

                                    elle contrôle :
                                    - qu'on soit bien sur la page https du formulaire d'authent
                                    - que le certificat server soit bien valide avec les certificats racines publiques des authorités de certification (via le package de certificat)
                                    - et récupère ce dernier, pour le comparer bit à bit avec un original embedded.

                                    Il n'y a pas de contrôle dans la CRL. Cependant, je me dis que si le certif de "fon" venait à être révoqué ... très vite fon remettrait un certificat ok (et il faudrait que je release une version dans la foulée, pour refonctionner (a cause du embedded)). Donc, pas la peine (pour mon cas) de mettre toute cette mécanique en place.
                                    Après tout, ce n'est que pour protéger un login/motdepasse, que l'utilisateur peut révoquer à chaque instant (chez freewifi en tout cas), et qu'il faut changer régulièrement pour être sécure.
                                    • [^] # Re: FreeWIFI : sécurité ?

                                      Posté par (page perso) . Évalué à 2.

                                      Je pensais, tu devrais peut-être utiliser un truc comme stunnel ou la librairie cURL ...

                                      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                      • [^] # Re: FreeWIFI : sécurité ?

                                        Posté par (page perso) . Évalué à 2.

                                        j'avais regardé du côté de pycurl ... il y avait moyen de faire peu ou prou la même chose (je ne sais si pycurl sait vérifier la CRL)

                                        mais dans mes recherches, j'ai bien compris que SSL ne garantissait qu'une seule chose : l'échange crypté ... et que les authorités de certifications c'était une vaste fumisterie, qui consistait à vendre du vent, car n'importe quel navigateur ou bout de code est capable d'accepter les certif "self-signed", et par conséquent le MITM a encore de beau jours devant lui. ( http://it.slashdot.org/article.pl?sid=08/06/24/2345223 )
                                        et qques infos pythons pertinentes : http://www.heikkitoivonen.net/blog/2008/10/14/ssl-in-python-(...)
                                        • [^] # Re: FreeWIFI : sécurité ?

                                          Posté par . Évalué à 3.

                                          mais dans mes recherches, j'ai bien compris que SSL ne garantissait qu'une seule chose : l'échange crypté ...
                                          Non, bien plus que ca.
                                          Il garantit aussi la non alteration des donnees en cours de route.
                                          Et il permet aussi d'identifier de facon sure les pairs de la communication (bien que le ssl client soit tres peu repandu, il est tout a fait possible).

                                          et que les authorités de certifications c'était une vaste fumisterie, qui consistait à vendre du vent, car n'importe quel navigateur ou bout de code est capable d'accepter les certif "self-signed"
                                          Un navigateur, ou n'importe quel applicatif qui accepte sans moufter un certif auto signe merite d'aller droit au bucher.
                                          Apres, que l'utlisateur clique sur oui, oui, amenes moi au site de pr0n quand meme, c'est un autre probleme.
                                          Les navigateurs maintenant sont vachement plus integristes sur les certifs signes par une autorite inconnue.

                                          Ensuite, dire que Verisign et autres vendent du vent...
                                          Oui et non.
                                          Oui, parce que dans le fond, ils vendent pas grand chose (quoique...), ils vendent la signature d'un certif, c'est effectivement cher paye pour une serie de bits. Et encore, si tu savais combien on vendait une cle triple des generee aleatoirement dans mon ancienne boite, ca faisait sourire.
                                          Non, parce qu'ils vendent une certaine confiance.
                                          ClampinCA.org, maintenu par jean rene et guy sur leur temps libre, j'aurais un certain doute sur le fait que leur cle prive soit toujours privee.
                                          Quand c'est verisign ou autre, ben le fait qu'aucun certificats delivres par ces gars la n'a pu etre spoofe, donc c'est que ca marche pas si mal que ca.
                                          Mais ca reste une confiance qu'ils vendent, t'as parfaitement le droit de ne pas leur faire confiance, quand l'essentiel de l'industrie se repose sur les qq roots CA, ben on peut se dire que bon, doivent pas etre si clampins au final.
                                          Apres, tu peux ne pas leur faire confiance, SSL marche toujours aussi bien, c'est ca qu'est beau.

                                          , et par conséquent le MITM a encore de beau jours devant lui. ( http://it.slashdot.org/article.pl?sid=08/06/24/2345223 )
                                          et qques infos pythons pertinentes : http://www.heikkitoivonen.net/blog/2008/10/14/ssl-in-python-(...)

                                          Moui, alors du man in the middle synchrone sans faire hurler le soft client qui etablit la connexion, va falloir se lever tot quand meme...
                                          On en revient au meme: si le client clique oui oui quand son soft lui dit que le site a qui il parle n'est pas forcement celui qu'il pretend etre, le probleme n'est pas trop dans le protocole.
                                          Plutot dans l'utilisateur, ou dans le soft qui a une mauvaise facon de presenter le warning.
                                        • [^] # Re: FreeWIFI : sécurité ?

                                          Posté par (page perso) . Évalué à 2.

                                          Oui et non. L'autorité de certification est uniquement la pour garantir que "X" est bien "X". Par exemple, aujourd'hui même, j'ai rencontré mon premier "assureur" pour cacert.org. En gros je lui ai donné un papier avec mon nom, mon prénom, mon adresse email et ma date de naissance, je lui ai montré deux documents (au moins 1 officiel) avec ma photo, mon nom mon prénom et ma date de naissance. On a signé tous les deux ce papier. Il doit conserver ce document et il se porte garant auprès de cacert.org que je suis bien qui j'ai annoncé être.

                                          C'est ça le travail de l'autorité de certification, de garantir que X est bien X. Donc tu as une confiance qui est établie comme ça. Ce n'est pas un réseau de confiance comme GPG, mais bien une hiérarchie de confiance. Il y a ceux au sommet qui font le travail pour garantir l'identité et après il signe le certificat. C'est comme ça que ta banque est reconnu comme ta banque et que personne peut venir s'interposer. Sinon ton navigateur met un message d'avertissement si le certificat n'est pas reconnu (par une autorité).

                                          Ensuite pour mon site perso, l'authentification se fait à travers un certificat à moi que c'est moi qui est généré parce que je me fais confiance, le flux est crypté et c'est ça qui m'intéresse (et j'ajoute mon propre CA dans mon navigateur comme ça je suis avertit si mon certificat a été changé (donc si on m'a piraté)). Au travail on utilise aussi des CA "self-signed" (bien que j'aimerais passer à cacert.org, justement).

                                          C'est donc pas "une vaste fumisterie" car le jour où ta banque produit une erreur, je te déconseille fortement de continuer, le système est perfectible (perso je suis pour qu'on puisse obtenir un CA signé par notre pays d'origine (gratuitement) et uniquement les pays soient au sommet de la hiérarchie. Quand tu reçois ton CA, il contient ton nom, prénom et un id. Ensuite tu peux générer tes certificats, ta banque peut t'authentifier par certificat, ... mon rêve quoi :-)


                                          Sinon pour pycurl, je penses qu'il est intéressant d'utiliser ça. Peu importe s'il fait toutes les vérifications "aujourd'hui", demain il les fera peut-être. Vaut mieux se baser sur une librairie qui va forcément évoluer (ou pas de bol c'est celle qui disparaît :-).

                                          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                          • [^] # Re: FreeWIFI : sécurité ?

                                            Posté par (page perso) . Évalué à 2.

                                            Quand tu reçois ton CA, il contient ton nom, prénom et un id. Ensuite tu peux générer tes certificats, ta banque peut t'authentifier par certificat, ... mon rêve quoi :-)

                                            La Belgique tend vers cela avec la carte d'identité électronique qui peut servir à signer des documents ou se connecter sur le site des impôts. Il existe même des lecteurs de carte compatible Linux. Pense à déménager pour réaliser ton rêve :-)

                                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                            • [^] # Re: FreeWIFI : sécurité ?

                                              Posté par (page perso) . Évalué à 2.

                                              Oui je sais, il y a eu un article dans un Linux mag sur le sujet. C'est presque exactement ce que je souhaite, c'est pas encore un CA, mais c'est déjà excellent.
                                              Comme quoi supprimer le gouvernement de temps à autre, ça a du bon.

                                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                              • [^] # Re: FreeWIFI : sécurité ?

                                                Posté par (page perso) . Évalué à 2.

                                                C'est dans le linux mag de ce mois-ci?

                                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                                • [^] # Re: FreeWIFI : sécurité ?

                                                  Posté par (page perso) . Évalué à 2.

                                                  Non un vieux de 2009 je crois. Je peux fouiller chez moi et je te redis si tu veux.

                                                  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                                  • [^] # Re: FreeWIFI : sécurité ?

                                                    Posté par (page perso) . Évalué à 2.

                                                    Non, c'est bon. Si c'était l'actuel je l'aurais acheté mais là ça va être difficile.

                                                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Centré, c'est le mot !

    Posté par . Évalué à 2.

    Jusqu'à être Canonical/Ubuntu only. Le côté upstream devient accessoire, on a la bonté d'uploader un tarball de sources... navrant.
    • [^] # Re: Centré, c'est le mot !

      Posté par (page perso) . Évalué à 7.

      Je pense que rien ne s'oppose à envoyer un patch à quickly pour qu'il supporte également le fait de faire des paquets rpm ou autres.

      Ce qui est navrant, c'est que de belles innovations soient critiquées uniquement car elles sont faites sur Ubuntu par des utilisateurs d'Ubuntu.
      • [^] # Re: Centré, c'est le mot !

        Posté par . Évalué à 3.

        Non la critique est bien sur la réalisation, rien d'autre. On réalise désormais une application ubuntu.
        Si tu souhaites pouvoir l'utiliser hors d'ubuntu, tu dois patcher/forker.

        DistUtilsExtra.auto.setup(name='quickly',
        version="'%s'" % VERSION,
        description='build new Ubuntu apps quickly',
        long_description='Quickly enables for prospective programmer a way to easily build new ' \
        'apps for Ubuntu based on templates and other systems for helping them ' \
        'write their code in a guided manner. This also includes packaging and ' \
        'deploying code.',
        url='https://launchpad.net/quickly',
        license="GPL v3",
        author='Quickly Developer Team',
        author_email='quickly@lists.launchpad.net',
        cmdclass={'install': InstallAndUpdateDataDirectory}
        )
        • [^] # Re: Centré, c'est le mot !

          Posté par . Évalué à 9.

          C'est vrai que c'est inadmissible les gens qui font une application qui répond à leurs besoins sans penser aux tiens.

          Quand je pense à toutes ces ignobles qui développent des tas d'applications qui ne m'intéressent pas alors qu'ils pourraient utiliser plus judicieusement leur temps à développer les applications que j'utilise !

          BeOS le faisait il y a 15 ans !

      • [^] # Re: Centré, c'est le mot !

        Posté par . Évalué à 8.

        > Ce qui est navrant, c'est que de belles innovations soient critiquées uniquement car elles sont faites sur Ubuntu par des utilisateurs d'Ubuntu.

        Le mainteneur de quickly, Rick Spencer travaille pour Canonical, d'ailleurs le copyright de quickly est assigné à Canonical. Même si quickly est réutilisable autre part, ça reste un projet très ubuntu-centric, fortement couplé à bazaar et Launchpad. À l'heure actuelle, quickly n'est pas architecturé pour être utilisable dans un autre contexte, pas de support de plugins, rien que l'intégration d'un autre VCS demanderait de réécrire une bonne partie de quickly.

        Un des problèmes récurrents pour les packagers sont les applications exclusivement développés *pour* Ubuntu. Ça va du projet aux dépendances farfelues, du projet sans VCS, sans tarball juste des deb ("parce qu'il n'y a que des fichiers python", super pratique pour les autres !), au projet qui te dit carrément merde (chez XBMC, c'est limite un préalable à toute contribution)
        Au bout d'un moment, il est normal que ça agace beaucoup de personnes.



        Reste que quickly part d'une bonne idée : un générateur de templates d'applications desktop comme on peut en retrouver pour les applications web, avec une couche d'abstraction pour faciliter les choses pour les non programmeurs. Je le verrais bien en remplaçant de RAD type Visual Basic, et il couvrerait un réel besoin.
        Une application sympathique développé par Jono Bacon à l'aide quickly :
        https://wiki.ubuntu.com/Lernid
        Le résultat est appréciable quand on sait que quickly n'existe que depuis près de 6 mois.
    • [^] # Re: Centré, c'est le mot !

      Posté par (page perso) . Évalué à 2.

      pour info ... tu n'upload pas le paquet, mais uniquement les sources/changelog ...
      et c'est leur ferme de serveur qui s'occupe de packager les paquets correctement pour la cible. c'est assez bien golé.
    • [^] # Re: Centré, c'est le mot !

      Posté par . Évalué à 1.

      Sors ton IDE favori et développe les patches pour adapter l'outil à d'autres environnements !

      BeOS le faisait il y a 15 ans !

      • [^] # Re: Centré, c'est le mot !

        Posté par . Évalué à 2.

        Super l'évolution, l'upstream neutre est mort. Je ne parle même pas de la duplication du travail...
        • [^] # Re: Centré, c'est le mot !

          Posté par . Évalué à 1.

          Et bien ne l'utilise pas s'il ne te plait pas !

          Vas-tu t'insurger à chaque évolution de Qt parce qu'il ne permet que de faire des applications Qt alors que tu préfères les applications Java/GTK/Gnustep ?

          BeOS le faisait il y a 15 ans !

          • [^] # Re: Centré, c'est le mot !

            Posté par . Évalué à 2.

            Ton exemple est ridicule. Le RAD n'est pas un centre d'intérêt spécifique.
            • [^] # Re: Centré, c'est le mot !

              Posté par (page perso) . Évalué à -2.

              oui, mais tu avoueras ... que développer "un quickly" qui prenne en compte l'ensemble des distribs linux, l'ensemble des languages , l'ensemble des GUI, et l'ensemble des VSC ... est quasi impossible quand on est qu'un seul type ...
              et il faudrait que ce type ait également une vaste culture générale (de l'ordre de l'impossible)

              ne rien faire non plus, car la tâche est énorme, n'est pas la solution. ça ne fait rien avancer !

              alors, oui, ... il y a bien un gars, tout seul, qui a initié qqchose, tout en étant sponsorisé par canonical ... lui : il fait avancer "le bousin", quand même.
              il est un peu normal, qu'il s'occupe principalement d'ubuntu qqpart.
              il va pas coder quickly pour redhat tout en étant payé par canonical. C'est un non sens !

              c'est terrible cette discrimination systématique envers ubuntu/canonical ...(qui contrairement à ce que tu dois certainement pensé : fait bien plus avancé linux / le libre que qui que ce soit d'autres ... en le rendant populaire (cercle vertueux))

              si tu veux vraiment te plaindre ... plaind toi qu'il n'y a aucun développeur réellement libre, qui sur son temps libre, développe gratuitement/bénévolement un quickly ultra généraliste multi distribrutions, multi languages, multi gui, multi vcs ...avec la ferme de serveur qui va derrière pour réaliser les builds en realtime.

              alors soit tu inities ce projet titanesque, soit tu aides le gars et apportent des patchs (voir en essayant de te faire sponsoriser par mandrake, redhat, ...)
              sinon, je ne peux que te conseiler de passer à ubu ;-) ... ce n'est qu'une debian (la distrib mère par excellence) revampée après tout.
              • [^] # Re: Centré, c'est le mot !

                Posté par . Évalué à 5.

                il va pas coder quickly pour redhat tout en étant payé par canonical. C'est un non sens !

                Pourtant, en un sens, Red Hat paye des développeurs pour coder pour Canonical, au travers du noyau Linux, de la libc, de GCC, de GNOME, etc

                Est-ce que Canonical renvoie du code upstream dont Red Hat pourrait profiter ? Ben non, tout le dev d'Ubuntu est sur Launchpad.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Centré, c'est le mot !

                  Posté par . Évalué à 2.

                  Tout a fait. On peut aussi citer pulseaudio (quoiqu'on en pense par ailleurs) : développement assuré principalement par Redhat mais exécuté de façon à être multi-plateforme et neutre.
                  • [^] # Re: Centré, c'est le mot !

                    Posté par . Évalué à 6.

                    Et on peut demander des dommages et intérêts?
                    • [^] # Re: Centré, c'est le mot !

                      Posté par . Évalué à 6.

                      Des dommages, les utilisateurs d'Ubuntu en ont de nombreux avec PulseAudio.

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Centré, c'est le mot !

                Posté par (page perso) . Évalué à 2.

                Bah entre développer un truc qui ne répond qu'à ton besoin et développer un truc en visant d'en être le seul utilisateur (un peu comme si je faisait un « traitement de texte permettant à Moi™ d'écrire des documents ») il y a une marge.

                Je ne suis pas convaincu pas l'argument populiste, ça fait peut être avancer les parts de marché de linux, bien moins que ce que ne va faire google avec android/chromeOS, mais je suis nettement moins convaincu de l'impact pour le libre.

                Combien d'utilisateur de firefox/vlc se fichent éperdument du libre et les fouetteront à la poubelle aussi tôt qu'une alternative privatrice offrira une avancée technique ?

                Évidemment, c'est mieux si tout le monde utilise du libre, car cela aurait sans doute effectivement un impact positif sur la politique des revendeurs matériel, malheureusement la politique d'ubuntu si favorable à l'intégration de (micro)logiciels privateurs en annihile tout l'intérêt.

                Bien sûr c'est une opinion très subjective, je ne prétend pas que cette politique ne peut aucunement conduire à de bonnes choses pour le libre, je n'en sais rien, mais j'en doute.
  • # RAD

    Posté par (page perso) . Évalué à 1.

    veut dire rapid application development
    • [^] # Re: RAD

      Posté par . Évalué à 3.

      et non pas ";-)"
    • [^] # Re: RAD

      Posté par (page perso) . Évalué à 3.

      > rad veut dire rapid application development

      je sais bien ;-), c'était pour la joke ...
  • # Contournement du vrai problème

    Posté par . Évalué à -1.

    Si un magasin (ta lib) exige que je lui écrive une lettre de motivation identique (ton code généré) à chaque fois que je veux entrer dans le magasin (écrire un programme avec la lib), toi tu photocopies la lettre plutôt que de la réécrire à chaque fois, et bien je vais dans un autre magasin !

    blague mise à part, je trouve ça ridicule qu'on en soit réduit à "générer" du code template, pourquoi il a-t-il à le faire si il est toujours le même ? Le code prêt-à-coller, c'est une immense connerie. Je vais troller : c'est pour les devs J2EE qui savent juste faire clic-clic dans eclipse (voilà qui va plaire à ploum).

Suivre le flux des commentaires

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