Un nouveau logiciel libre : Lufi

58
6
oct.
2015
Internet

Après Lutim, qui permet d’héberger des images, je me suis dit « Pourquoi me limiter aux images ? ». Et puis, ça m’embêtait de chiffrer les images côté serveur. Bien sûr, pour pouvoir utiliser les images dans des balises <img>, il fallait que le chiffrement et le déchiffrement se fassent côté serveur. Mais, pour des fichiers, ça ne sert à rien.

J’ai donc pris exemple sur Zerobin, qui chiffre le texte côté client, en utilisant la bibliothèque Stanford Javascript Crypto et qui met la clé dans une ancre dans l’adresse URL.

Avec ça, j’ai repris le mode de fonctionnement de Lutim (qui lui‐même est fortement pompé sur mon logiciel Lstu), j’ai saupoudré de Bootstrap et de WebSocket et ça a donné Lufi !

Le logo de Lufi

Let’s Upload that FIle

Du temps, de la sueur, des larmes, un bon éditeur de texte, le meilleur cadriciel Web du monde et voilà Lufi !

Le principe est simple :

  • on dépose des fichiers dans la zone dédiée à cet effet ;
  • le JavaScript génère une clé de chiffrement (différente pour chaque fichier) ;
  • le fichier est découpé en morceaux ;
  • chaque morceau est chiffré et envoyé via WebSocket au serveur ;
  • vous récupérez deux liens : un lien de téléchargement et un lien de suppression.

Les bonus :

  • les informations sur les fichiers envoyés sont stockées en localStorage sur le navigateur et une interface permet de visualiser ces informations ;
  • on peut demander à ce que le fichier soit supprimé dès le premier téléchargement ;
  • on peut définir un délai d’expiration après lequel le fichier est supprimé.

Pour les administrateurs et les développeurs :

  • les instructions d’installation sont sur le wiki ;
  • on peut définir des paliers de tailles, forçant le délai de suppression. Exemple : les fichiers de moins de 10 Mio pourront rester 60 jours, ceux entre 10 Mio et 50 Mio, 30 jours et au‐delà de 50 Mio, 2 jours. Cela permet de limiter l’utilisation de l’espace disque ;
  • sous licence AGPL v3, le code est sur le GitLab de Framasoft avec un miroir sur GitHub ;
  • c’est codé en Perl avec le cadriciel Mojolicious, la bibliothèque Stanford Javascript Crypto, du Twitter bootstrap pour le CSS, des icônes piochées sur Fontello et la bibliothèque Moment.js. Tout le JavaScript est écrit en Vanilla JavaScript.

Pour le logo :

  • phonétiquement parlant, en français, Lufi sonne comme Luffy, le personnage principal du manga One Piece. Luffy est surnommé « Chapeau de paille », et comme Lutim avait déjà un chapeau pour logo… Un coup d’Inkscape, et hop ! (Lstu a d’ailleurs récemment gagné un chapeau comme logo).

Framadrop

Lufi sera le logiciel utilisé par Framasoft pour proposer le service Framadrop1 dans le cadre de l’opération Dégooglisons Internet.

Par ailleurs, la saison 2 de la campagne de dégooglisation a commencé aujourd’hui : n’hésitez pas à soutenir Framasoft pour qu’on puisse continuer !

Bon alors, c’est où qu’on clique ?

Contrairement à Lutim, je ne proposerai pas d’instance officielle, juste une instance de test : https://demo.lufi.io (hébergée par Framasoft, comme Erco, merci à eux :D).

En effet, il risque d’y avoir besoin de pas mal d’espace disque pour opérer un service comme celui‐ci. Je ne peux pas me permettre financièrement de prendre un serveur pour ça, ni demander à Framasoft de me prêter une machine virtuelle, alors qu’on proposera Framadrop à la fin de la semaine.

Nota Bene

Alors, non, c’est pas parce que Framasoft voulait sortir un tel service que j’ai codé Lufi, c’est plutôt parce que je voulais coder Lufi que Framasoft propose Framadrop. Framasoft ne fait toujours pas de code (excepté Framadate). J’ai codé Lufi en dehors de Framasoft, bien que j’en sois membre.

Lufi est encore jeune, donc si vous repérez des problèmes, n’hésitez pas à ouvrir un ticket !

Article initialement posté sur mon blog : https://fiat-tux.fr/2015/10/05/un-nouveau-logiciel-libre-lufi/.

Aller plus loin

  • # Questions d'un curieux

    Posté par  . Évalué à 10. Dernière modification le 06 octobre 2015 à 01:17.

    1/ Que ce soit d'un point de vue développement comme d'un point de vue UX, qu'apporte l'utilisation d'un websocket par rapport à un XMLhttpRequest plus classique comme le fait jirafeau ?

    2/La question qui revient sans cesse concernant le chiffrement au travers du web, c'est l'incapacité de s'assurer de l'identité du code JavaScript qui va prendre en charge ce chiffrement, en particulier en cas d'interception du flux de données entre le client et le serveur par des tiers. Si on fait confiance au serveur utilisé, comme cela est a priori le cas chez framasoft, ne vaut il mieux pas laisser celui-ci s'occuper du chiffrement en lui faisant confiance pour oublier la clé ? Question candide d'un béotien du chiffrement …

    3/ Pourquoi envoyer des méta données non chiffrées telles que le nom du fichier, sa taille et son mime type, plutôt que de stocker cela dans le LocalStorage, n'envoyer qu'un hash au serveur, et fournir ces informations via l'ancre de l'URL avec la clé pour les destinataires potentiels ?

    Merci pour cette nouvelle contribution !

    • [^] # Re: Questions d'un curieux

      Posté par  . Évalué à 3.

      1/ qu'apporte l'utilisation d'un websocket par rapport à un XMLhttpRequest plus classique comme le fait jirafeau ?

      websocket te permet de faire du push côté serveur : tu peux balancer un message depuis le serveur vers un client ou bien tous les clients connectés.

      • [^] # Re: Questions d'un curieux

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

        Sans compter que la connexion est établie, ce qui évite de réinitialiser une connexion pour chaque envoi de morceau de fichier.

        Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

        • [^] # Re: Questions d'un curieux

          Posté par  . Évalué à 6.

          Euh… Avec HTTP 1.1 tu réutilise la connexion (et c'est super vieux).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Questions d'un curieux

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

      1/ Que ce soit d'un point de vue développement comme d'un point de vue UX, qu'apporte l'utilisation d'un websocket par rapport à un XMLhttpRequest plus classique comme le fait jirafeau ?

      Voir ma réponse à @stopspam haut dessus. La connexion n'est jamais coupée, donc je renvoie plus rapidement puisque je ne réinitialise pas la connexion (je crois qu'il y a maintenant une réutilisation des connexions déjà utilisées pour pallier ce genre de problème, mais je n'ai pas creusé).

      Pour l'UX, bah, du coup ça doit faire gagner quelques pouhièmes de seconde.

      Sinon, le développement côté serveur a été vraiment très simple grâce à l'utilisation des Websockets (même si ça n'aurait pas été dur de faire ça pour de l'Ajax classique). J'ai bien aimé :-)

      2/La question qui revient sans cesse concernant le chiffrement au travers du web, c'est l'incapacité de s'assurer de l'identité du code JavaScript qui va prendre en charge ce chiffrement, en particulier en cas d'interception du flux de données entre le client et le serveur par des tiers. Si on fait confiance au serveur utilisé, comme cela est a priori le cas chez framasoft, ne vaut il mieux pas laisser celui-ci s'occuper du chiffrement en lui faisant confiance pour oublier la clé ? Question candide d'un béotien du chiffrement…

      Quand j'ai fait Lutim avec chiffrement côté serveur, on m'a fait la remarque inverse :p Tu fais confiance à Framasoft, soit, Mais si le serveur se fait poutrer, celui qui est sur le serveur a les clés. Là, même si le serveur est compromis, ce n'est pas grave, les fichiers restent illisibles.

      Si le code javascript est compromis, il y a quand même plus de chances que quelqu'un s'en aperçoive que si c'est le serveur qui est compromis, puisque le javascript est lisible par chaque utilisateur. Côté serveur, il n'y a que les admins qui peuvent s'en rendre compte.

      3/ Pourquoi envoyer des méta données non chiffrées telles que le nom du fichier, sa taille et son mime type, plutôt que de stocker cela dans le LocalStorage, n'envoyer qu'un hash au serveur, et fournir ces informations via l'ancre de l'URL avec la clé pour les destinataires potentiels ?

      • Taille : le serveur en a besoin pour savoir :
        • si la taille ne dépasse pas la taille autorisée
        • s'il y a suffisamment de place sur le serveur pour accueillir le fichier
        • quel limitation de délai appliquer
      • Nom du fichier et mimetype : le javascript de récupération en a besoin pour reconstruire un fichier avec un nom compréhensible et un mimetype correct. Alors oui, éventuellement, je pourrais chiffrer ça dans l'ancre. Faudrait voir comment faire ça proprement.

      Merci pour cette nouvelle contribution !

      Je t'en prie :-)

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: Questions d'un curieux

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

        La connexion n'est jamais coupée, donc je renvoie plus rapidement puisque je ne réinitialise pas la connexion

        J'ai un moment travaillé dans un pays ou la connexion était TRES faible. Bref, atteindre le kb/s était bien et souvent, il y avait plusieurs micro coupure par heure. A l'époque, j'avais utilisé 'mosh' pour me connecter sur nos serveurs car même 'ssh' n'était pas utilisable. De même XMPP était ultra pratique pour échanger. Je pense qu'avoir des protocoles très résistant aux coupures est aussi un point important pour nombre de personne sur Terre.

        Comment se comporte les websockets dans ce genre de cas ?

        • [^] # Re: Questions d'un curieux

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

          Mmh, je ne pense pas qu'elles soient plus résistantes que de l'ajax. Quand je dis que la connexion n'est jamais coupée, je veux dire qu'il y a création d'une connexion entre le client et le serveur et qu'elle est maintenue ad vitam, donc pas besoin de la récréer à chaque envoi comme pour de l'ajax, mais ça s'arrête là.

          Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

          • [^] # Re: Questions d'un curieux

            Posté par  . Évalué à 2.

            Je couple ma connexion websocket avec un SetInterval(function(), 2000). function() va me vérifier le statut de mon websocket toutes les 2s. En cas de coupure, il retente une connexion websocket.

            Ça me permet de gérer, sur mobile surtout, les cas ou le téléphone passe en veille. Au réveil, le polling relance websocket automatiquement sans devoir faire un refresh.

            • [^] # Re: Questions d'un curieux

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

              Si la connexion coupe en cours de transfer, c'est une erreur, et c'est géré, si elle se ferme proprement alors que j'en ai besoin, j'en rouvre une. C'est kif kif comme toi en fait ;-)

              Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Nom + Logo

    Posté par  . Évalué à 2.

    Je ne suis pas spécialiste du droit d'auteur mais grand fan de One Piece.

    Reprendre une partie du logo de ce manga très connu est-il autorisé ?

    • [^] # Re: Nom + Logo

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

      Bof, si tu regardes le logo original, je ne reprends qu'une toute petite partie (le chapeau) et c'est pas du tout la même vue. Le rapport avec logo original est très ténu.

      Donc je pense que ça ira (ils n'ont pas le monopole des chapeaux de paille quand même), surtout que j'ai fait le mien de mes blanches mains avec Inkscape (si un modo pouvait corriger le « Onkscape » dans la dépèche d'ailleurs, ce sera sympa).

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: Nom + Logo

        Posté par  . Évalué à 5.

        ils n'ont pas le monopole des chapeaux
        Non, c'est Valve qui a ce monopole :-D

      • [^] # Re: Nom + Logo

        Posté par  . Évalué à 4.

        Non mais couplé avec le nom de ton soft ça peut porter a confusion. Le chapeau a aussi le ruban rouge caractéristique de la série, tout ces éléments fait qu'il sont en droit de t'embêter. Après le domaine étant totalement différent tu peux toujours te défendre.

        • [^] # Re: Nom + Logo

          Posté par  . Évalué à 5.

          Mouais, j'ai d'amers souvenirs avec Mobilix…

          • [^] # Re: Nom + Logo

            Posté par  . Évalué à 1.

            Tu parles de quoi?

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Nom + Logo

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

              Ah les petits jeunes…
              (non, "ne pas tout savoir" n'est pas une excuse, LinuxFr ayant aussi parlé de ça)

              Problème de marque déposée : Obelix contre MobiliX

              • [^] # Re: Nom + Logo

                Posté par  . Évalué à 1.

                J’ai cherché l’information sur un moteur de recherche et je n’ai trouvé que des informations sur le projet de modifications des transports en communs d’Angoulême. Et j’avais complètement oublié cette dépêche.

                Mais merci de présumer mon ancienneté sur le site (ou de mon âge). :)

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Nom + Logo

                  Posté par  . Évalué à 3.

                  Ben techniquement, ton compte existe depuis 2012. Donc du point de vue de LinuxFR, oui, t'es une « jeune », indépendamment de ton âge réel, ou du nombre d'années que tu as consacrées à ce site avant de créer un compte. :-)

                  • [^] # Re: Nom + Logo

                    Posté par  . Évalué à 1.

                    Ah oui j’avais pas vu la date de publication. Ça m’étonne que ça soit si vieux parce que je croyais l’avoir lu dans mes flux RSS, c’est pour ça que je ne comprenais pas la réflexion sur l’âge. Disons que j’aurais pu suivre le site depuis super longtemps . Une autre personne a dû en reparler et mettre un lien (parce que c’est un peu crétin de parler d’un truc assez vieux sans mettre un lien vers ledit contenu).

                    Écrit en Bépo selon l’orthographe de 1990

                    • [^] # Re: Nom + Logo

                      Posté par  . Évalué à 2.

                      Ben, mon attitude crétine est due au fait qu'une bonne partie de la population de LinuxFR (et en tout cas, une bonne partie des gens qui participent) est constituée d'habitués de longue date, qui ont ont eu vent de l'affaire Mobilix, qui elle-même avait été largement discutée ici (en fait c'est ici que j'en ai entendu parler pour la première fois à l'époque).

                      De plus, j'avoue qu'avec les histoires de Mandrake/Mandriva, c'était quand même l'une des affaires de marque déposée et droit d'auteur les plus marquantes parmi les gens qui voulaient faire du pognon avec le libre. Dans le cas de Mandrake, la mauvaise fois était évidente, et même si je trouve que c'était un peu abusé de les poursuivre1, les avocats qui défendaient la « marque » Mandrake ne faisaient que leur boulot (le pengouin avec une baguette magique et le nom, c'était difficile d'expliquer que ça n'avait rien à voir avec le personnage magicien du même nom), alors que dans le cas de Mobilix, la bonne fois était (selon moi) évidente, et complètement cohérente avec les autres noms dérivés de UNIX et Linux par divers acteurs.


                      1. Mais je ne me souviens pas s'il y avait eu une tentative de conciliation, donc ça se trouve, le procès aurait pu être évité. 

                      • [^] # Re: Nom + Logo

                        Posté par  . Évalué à 1.

                        Ben, mon attitude crétine est due au fait qu'une bonne partie de la population de LinuxFR (et en tout cas, une bonne partie des gens qui participent) est constituée d'habitués de longue date, qui ont ont eu vent de l'affaire Mobilix, qui elle-même avait été largement discutée ici (en fait c'est ici que j'en ai entendu parler pour la première fois à l'époque).

                        Bah je trouve ça un peu dommage d’exclure d’entrée les autres personnes que les habitués quoi.

                        Écrit en Bépo selon l’orthographe de 1990

                        • [^] # Re: Nom + Logo

                          Posté par  . Évalué à 3. Dernière modification le 09 octobre 2015 à 23:13.

                          Ben je vois pas ce qu'il y a de dommage.

                          De deux choses l'une : soit tu connais déjà l'affaire donc je causais, et dans ce cas, tu n'as pas besoin que je te file un lien. Soit tu ne connais pas, et là, deux autres choix s'offrent à toi : tu peux chercher sur google directement1, ou bien, si comme moi tu es plutôt flemmarde, et que t'es déjà sur LinuxFR, là, maintenant, tout de suite, tu peux répondre au commentaire, et demander un éclaircissement.

                          Dont acte : tu as posé la question à propos de Mobilix, quelqu'un t'a répondu avec le lien kivabien™ (avant moi, car quand on a 6h de différence avec la France, c'est parfois un peu compliqué de répondre en temps et en heure).

                          De plus, j'ai écrit un « one liner » à la base, il est donc fort possible que j'ai répondu depuis mon téléphone portable, ou bien que j'aie répondu « juste en passant », parce que j'avais autre chose à faire, et que j'allais sans doute oublier de mentionner cette histoire sinon. Je passe suffisamment de temps à détailler mes réponses en général2 pour que ça m'agace un brin quand on qualifie mon attitude de « crétine » tout ça parce que je t'ai pas sorti toutes les réponses sur un plateau.


                          1. Je serai cependant le premier à reconnaître que même si tu passes par Google France, tu risques d'avoir des problèmes à trouver le bon lien si tu utilises seulement « mobilix ». Malgré tout, rajouter « droit d'auteur » (qui est quand même l'objet du premier commentaire de ce fil de discussion), « logiciel libre » ou « linux » retire toute ambiguïté. 

                          2. Dont celle-ci, mais c'est relativement inutile, j'avoue. 

        • [^] # Re: Nom + Logo

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

          Et ben s'ils aiment pas les hommages, je changerai de logo (mais pas de nom : ça reste un acronyme cohérent avec les noms de mes softs créés depuis 2 ans). Autant poche/pocket, y avait beaucoup trop de trucs qui allaient pas (nom traduit, logo et but du logiciel), autant là :

          • un nom qui vient d'autre part (acronyme, dans la lignée de deux autres softs, cohérence des noms sur 2 ans)
          • un nom qui ne s'écrit pas pareil
          • un logo fait de mes blanches mains, pas en partant du logo du manga
          • un but qui n'a rien à voir avec le manga (même pas avec le piratage : plus c'est gros, moins ça reste, en partie pour éviter de se retrouver à héberger les séries et autres films tipiakés)

          Je pense que s'ils veulent m'emmerder, ça sera pas très grave.

          Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Lufi + Lstu

    Posté par  . Évalué à 1.

    Bonsoir,

    d'abord bravo pour le soft, ça fait un moment que je l'attendais ;)

    Est-ce qu'il est prévu de pouvoir associer Lufi à Lstu, histoire de pouvoir diffuser des URLs courtes ?

    • [^] # Re: Lufi + Lstu

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

      Non, par contre j'ai un add-on Firefox dans les cartons ainsi qu'un bookmarklet. Par contre, ça ne te servira peut-être pas : pas moyen de choisir un texte custom avec l'addon et le bookmarklet.

      Mais est-ce que ce serait vraiment utile ?

      1. tu retrouves toutes tes URLS et fichiers sur https://demo.lufi.io/files
      2. pour le Lufi de démo, ainsi que Framadrop, les fichiers expirent nécessairement alors que les URLs de Lstu n'expirent jamais (pour éviter que qq'un clique sur une ancienne adresse Lstu et se retouve sur un site qui n'est pas le bon, pire, qu'il se retrouve sur un fichier Lufi confidentiel :p
      3. transformer sur un service l'URL d'un lien Lufi, c'est donner la clé au service de réduction d'URL… Moyen top la confidentialité :p

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Merci

    Posté par  . Évalué à 3.

    En tant qu'utilisateur quasi quotidiens de lutim, j'aimerais te remercier pour ton travail.
    Je trouve que l'on a jamais fait plus simple/rapide/libre comme site de partage d'image.

    Lufi me sera aussi très utile.

    Merci.

    • [^] # Re: Merci

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

      j'aimerais te remercier pour ton travail.

      Je t'en prie ;-)

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

Suivre le flux des commentaires

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