Bon, ça va résumer un peu certains commentaires précédents, et je vais ajouter un peu de mon côté au passage:
L’idée qui anime notre projet est de rehausser le niveau de sécurité des emails, POUR TOUS, c’est-à-dire pour le boulanger, l’employée du bureau, la dessinatrice de mode, mon grand-père, mes enfants, les profs...
C'est une vraie raison pour ne pas imposer de technique impliquant aux utilisateurs d'utiliser un système de clé privée/publique (l'utilisateur moyen ne comprendra pas qu'il faut se trimballer une clé et se souvenir d'une passphrase). En revanche, ce n'est pas une bonne raison pour bloquer cette possibilité.
Par rapport à l'envoi de mot de passe (je n'ai pas regardé les sources, je me base sur les commentaires précédents) via le net, l'alternative serait de déporter la mécanique de protection côté client, via du JS (je dis ça, alors qu'en général j'ai tendance à bloquer le JS... allez comprendre!).
Bon, je suis vraiment pas très bon en sécurité, alors je me plante peut-être, ce n'est peut-être pas faisable proprement.
Ce type d’offre manquait cruellement en France...
C'est vrai, l'existant est délicat à trouver, en général ce sont de petites associations. Mais il en existe. Ceci étant dit, une plus grosse structure, qui ait pour objectif de grossir et non de faire des boutures n'est pas une mauvaise chose.
à condition toutefois que leur contribution aille au-delà du sarcasme (du français dans le code ! quelle horreur... du français ! ;-)
Ce n'est pas uniquement sarcastique (mais il faut être habitué à linuxfr il est vrai, pour comprendre entre les lignes), c'est surtout que le code source pointé (chaine.c) révèle plusieurs problèmes:
le fait de réinventer la roue (string_ajout, au nom, je dirait que ça réimplémente strcat... p'tet strncat éventuellement, voire pire... std::string::operator+= ).
Et, oui, le fait que le code soit en français EST un problème dans le monde du libre. Du code franchouillard, c'est illisible pour un non-francophone, et difficile à lire pour un dev rôdé à coder en anglais... qui sont, amha, majoritaires dans le libre.
Enfin, pour en finir au sujet de ce fichier que j'ai lu très vite, et revenir à ma remarque sur std::string::operator+=, pourquoi utiliser le C si c'est pour réimplémenter CFront, limite? Autant utiliser C++ en interdisant les features qui vous gênent (ça se fait très bien à la compil, de virer les exceptions et la RTTI, et quand aux méthodes virtuelles et autres héritages, des règles de codages claires ainsi qu'un ou deux scripts hookés dans le .git peuvent empêcher l'introduction accidentelle. Le C++ n'est pas un langage objet, mais juste orienté objet... c'est un choix du dev qui l'utilise, et si on utilise pas, on paye pas.)
Enfin, je dirais que roundcube est... spartiate, dans le meilleur des cas. Peut-être avez-vous activé un module qui permets de gérer des règles de filtrage, car il semble que dans la version que j'utilise habituellement, ça n'existe pas, et c'est un manque des plus pénibles, quand on est abonné à une ou deux mailing lists.
[^] # Re: L'esprit de Mailden
Posté par freem . En réponse au journal Que penses-tu du service mail Mailden ?. Évalué à 5.
Bon, ça va résumer un peu certains commentaires précédents, et je vais ajouter un peu de mon côté au passage:
C'est une vraie raison pour ne pas imposer de technique impliquant aux utilisateurs d'utiliser un système de clé privée/publique (l'utilisateur moyen ne comprendra pas qu'il faut se trimballer une clé et se souvenir d'une passphrase). En revanche, ce n'est pas une bonne raison pour bloquer cette possibilité.
Par rapport à l'envoi de mot de passe (je n'ai pas regardé les sources, je me base sur les commentaires précédents) via le net, l'alternative serait de déporter la mécanique de protection côté client, via du JS (je dis ça, alors qu'en général j'ai tendance à bloquer le JS... allez comprendre!).
Bon, je suis vraiment pas très bon en sécurité, alors je me plante peut-être, ce n'est peut-être pas faisable proprement.
C'est vrai, l'existant est délicat à trouver, en général ce sont de petites associations. Mais il en existe. Ceci étant dit, une plus grosse structure, qui ait pour objectif de grossir et non de faire des boutures n'est pas une mauvaise chose.
Ce n'est pas uniquement sarcastique (mais il faut être habitué à linuxfr il est vrai, pour comprendre entre les lignes), c'est surtout que le code source pointé (chaine.c) révèle plusieurs problèmes:
Enfin, je dirais que roundcube est... spartiate, dans le meilleur des cas. Peut-être avez-vous activé un module qui permets de gérer des règles de filtrage, car il semble que dans la version que j'utilise habituellement, ça n'existe pas, et c'est un manque des plus pénibles, quand on est abonné à une ou deux mailing lists.
En tout cas, bonne chance et bonne continuation.