Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Montez en 1 clic un lien http(s) ou votre espace 1fichier !

Zakhar

Effectivement, si on utilise enfs, ça oblige à relire avec le PC.

Après, sur un téléphone, tâcher de chiffrer alors que c'est Android qui tourne... vu comment les gens sont tracés sur cet O.S. c'est un peu illusoire, mais bon !

Pour encfs, voici mon script de montage pour hubic, c'est fort simple en réalité !

#! /bin/sh
if ! mount | grep -q hubicfuse; then
    [ -d /tmp/hub ] || mkdir /tmp/hub
    hubicfuse /tmp/hub  -o noauto_cache,sync_read
fi
if ! mount | grep -q encfs; then
    [ -d /tmp/secure ] || mkdir /tmp/secure
    ENCFS6_CONFIG=~/Images/.encfs6.xml encfs /tmp/hub/default/Documents/ /tmp/secure/
fi

Le premier bloc monte hubicfuse
Le deuxième bloc monte encfs par dessus. Bien sûr le fichier de chiffrement de encfs reste local... sinon c'est un peu trop faciliter l'attaque !

Le script peut s'adapter à tout premier montage... enfin du moment que ce n'est pas du read-only ! 😛

Arbiel

Bonjour

Zakhar a écrit Après, sur un téléphone, tâcher de chiffrer alors que c'est Android qui tourne... vu comment les gens sont tracés sur cet O.S. c'est un peu illusoire, mais bon !

Cela veut-il dire que les informations mémorisées sur un téléphone ne sont absolument pas protégées et qu'il n'est donc pas recommandé, par exemple, d'utiliser la fonction de mémorisation de mots de passe proposée par firefox ? Peux-tu être un peu plus explicite sur ces risques, ou donner la référence à un site qui les analyse ?

D'avance, je t'en remercie

Arbiel

Zakhar

C'est une autre discussion !

Je ne fais pas confiance du tout au "closed source", or, même si le noyau d'android est bien Open Source, le "blob" Google qui est de plus en plus gros ne l'est pas. Tout cela Google le fait "gratuitement", or comme disent nos amis anglais : "there is no free lunch"... il faut bien que le modèle économique soit quelque part ne penses-tu pas ?

Les mots de passe dans Firefox c'est autre chose. Firefox est bien libre et Open Source, par contre c'est effectivement un risque en cas de compromission de la machine. Risque à évaluer en fonction de la confidentialité des données qu'on protège eu égard la commodité de la chose. Donc il y a pas mal de site où je mémorise effectivement dans Firefox... et pour certains je ne le fais pas (banque, etc...)
Du reste quand les sites sont bien codés, le navigateur ne va pas te proposer de mémoriser le mot de passe si c'est trop sensible.

Cela dit, là où je te rejoins, c'est que mon développement ne nécessite que "fuse". C'est bien dommage que le noyau Linux des android soit compilé sans le support de "fuse", sinon pouvoir disposer de ton cloud 1fichier, uptobox, etc... de façon "transparente" sur un mobile Android serait bien pratique (partant que les données étant déjà dans le Cloud, elle ne sont pas confidentielles sinon l'utilisateur les aurait chiffrées !).
La seule "limite" à cette commodité est évidemment la bande passante ridicule accordée par certains opérateurs qui limiterait vite l'usage de la chose !

Je vais revérifier si le non-support de fuse est toujours dans les noyaux récents Android.

Zakhar

[Annonce] A partir de la version 0.7.5, c'est complètement fonctionnel avec 1fichier, y compris sous-répertoires.

Mais surtout, pour ceux qui ne veulent pas ou ne savent pas compiler... vous avez désormais un ppa avec le package (0.7.7-1) tout prêt pour Xenial (16.04LTS) !

Voir instructions dans le premier post.

Note : le test de la version 32bits est dans les /Todo... donc si c'est votre cas (version 32 bits) et que ça bug complètement... désolé. Dans ce cas laissez un mot que je priorise ce test.

Roschan

Je n'ai pas tout lu, n'ayant pas trop l'utilité de ce genre de chose, mais un détail me saute aux yeux, et me les arrache :

Ce fichier doit contenir 2 lignes, de la sorte:

id='your_id'
passwd='your_password'

Il faut stocker un mot de passe en clair ??

Zakhar

Non, tu peux modifier le script pour qu'il te demande le mot de passe si tu veux. 😛

En réalité, si tu as une partition /home chiffrée, c'est pas trop dramatique de faire ainsi, et c'est effectivement toujours un équilibre personnel sécurité/praticité.

Mais tu as totalement raison, pour les gens "security-aware", je vais mettre l'option de demander le mot de passe dans la /TODO list !

[Edit] la suggestion est maintenant inscrite dans la /todo, merci Roschan

Zakhar

Version 1.1 du script 1fichier:
Selon la suggestion de Roschan, si le mot de passe n'est pas présent dans le fichier de configuration, il sera demandé à l'utilisateur.

La demande est faite soit sur le terminal si le script est lancé en ligne de commande, soit via zenity si ce n'est pas le cas.

Il en est de même pour l'identifiant, ou si le fichier de configuration n'existe pas, les 2 éléments seront demandés.

Une variable "options" peut être spécifiée. Ce seront alors des options globales qui seront rajoutées à la ligne de commande. Un exemple d'utilisation est par exemple d'augmenter la verbosité en spécifiant : options="-l6"

Zakhar

Version 1.2 du script 1fichier:
- Gère la mise en cache. Si vous avez beaucoup de fichiers sur votre stockage et que le montage est long, vous pouvez paramétrer pendant combien de temps on réutilise la même commande et où on la stocke. Il suffit de supprimer le fichier stocké pour nettoyer la cache.

Version 0.8.0 (packagée) de astreamfs:
- Gère désormais les "paths" de façon complète (y compris chemins relatifs)

Zakhar

Le code a été migré sur GitLab, comme tous mes autres codes libres.

Les liens sur la première page sont corrigés et pointent sur mon nouveau dépôt GitLab.

Brunod

Un seul mot : Merci ! pour la communauté 🙂

Zakhar

Merci pour quoi ? Le migration vers GitLab ?

C'est tout naturel non ? 😃

Le jour où M$ reconsidérera sa politique de racket quand on achète un PC, et donc passera par exemple à un modèle économique paiement du "service" (l'O.S. et son support) sur base d'abonnement facultatif... je reconsidérerai ma position quant à l'utilisation de ce qui touche de près ou de loin à ces mafieux.

Et ce jour là, je crains, on va voir arriver chez le pingouin des hordes de gens qui n'auront pas envie de payer leur "impôt" mensuel à M$... fini la tranquillité !..

Quand à astreamfs, il reste une grosse amélioration dans le tuyau pour le cas de connexion "pas trop rapide" comme un ADSL standard, c'est : "la bufferisation/readahead".
En effet, je peux utiliser le logiciel sans problème pour les cas d'usage "visionnage de mes films de vacances" chez moi où j'ai la fibre de Free (une vraie tuerie à 1Gbps !), mais sur une ligne ADSL "standard" (~20Mbps), même si le débit théorique est suffisant pour le cas d'usage, le fait que l'on fasse de la lecture "just in time" avec le seul buffer readahead du kernel à 128K n'est pas suffisant pour avoir une lecture "fluide"... même en montant le buffer de lecture de VLC (qui n'a pas l'air de gérer terriblement bien son buffer de lecture anticipée en réalité !).

Mais je traîne un peu à faire cette modification, car elle implique une refonte totale du "moteur" de lecture... et :
- je suis occupé à refaire mes "tweaks" sur la 18.04.... surtout maintenant que la pile réseau a encore changé... (netplan...)
- je n'en ai pas besoin chez moi (la fibre de Free !)

.... mais ça viendra, et on aura une encore meilleure version de astreamfs avec buffers et avec moins de "locks" (la refonte supprimera les locks sur le reader d'arrière plan, le sémaphore existant suffira à régler ça).

Zakhar

1fichier a changé les liens de 10 caractères à 20.
Anciennement :
https://1fichier.com/?0123456789
Désormais :
https://1fichier.com/?01234567890123456789

C'est corrigé dans le script de montage qui regardait 10 caractères 'en dur'. Le pattern est désormais plus souple et ne tient pas compte d'un nombre de caractères 'en dur' du lien.

Zakhar

Version 0.8.1

Changelog :
Support de l'authentification basic user:password

Les .deb sont à disposition dans mon ppa pour la 16.04 (Xenial) et pour la 18.04 (Bionic)

Prochainement :
1fichier ayant développé des API, je vais créer une adaptation de astreamfs avec les APIs de 1fichier pour lire les répertoires.
Cela évitera d'avoir à utiliser le script en conjonction de astreamfs.
Ainsi le montage de son espace 1fichier se fera de façon super simple ainsi:

1fichierfs --api-key 'abcd1234' ~/1fichier

A terme, on aura une meilleure performance, le driver ne lisant que les répertoires que l'utilisateur accède, et une mise à jour possible du montage sans avoir à démonter/remonter quand on rajoute des choses sur son cloud.

L'API 1fichier est pour l'instant "en test", donc il vous faudra leur demander pour y accéder.

Lorsque l'adaptation sera faite, je ferai un post séparé pour l'annonce.

Demande d'aide :
Je regarde aussi comment adapter sur Mac... mais sans Mac ce n'est pas facile !
Donc si ça intéresse quelqu'un qui n'a pas trop peur de la ligne de commande et sait se débrouiller avec son Mac, l'aide est bienvenue.

Fuse est rendu sur Mac par ça https://osxfuse.github.io/
Le "portage" est donc sans doute assez trivial à partir du moment où on sait installer les bonnes libraires et headers de compilation.

Zakhar

Spécialisation pour 1fichier, via les API est en ligne.

https://forum.ubuntu-fr.org/viewtopic.php?id=2034345

« Page précédente