Ah ? Moi je n'en ai vu aucune qui soit flexible (utilisable avec un
nombre qeulconque de chaines) et qui n'impose pas de limite statique à
la taille du résultat.
Le faire planter oui, le contraindre à exécuter du code arbitraire,
beaucoup plus difficilement, vu que le débordement ne se fait pas sur
la piule, on ne peut pas écraser l'addresse de retour de la fonction
Et tu verras si tu les lis, ces standrads, que PATH_MAX est
_optionnel_, un système POSIX n'est PAS obligé de définir PATH_MAX. Ce
que dit POSIX c'est "si le système définit PATH_MAX, alors aucun
chemin ne peut dépasser PATH_MAX", mais certains systèmes POSIX (comme
GNU/Hurd) n'ont pas de limite.
Un 3ème point est qu'accumuler des allocations mémoires pour obtenir une
"meilleure" "sécurité" ne fait qu'aggraver les performances de ton
programmes. Et oui, la présence de malloc() tout le long de l'exécution
n'est pas signe de performance.
Mauvaise libc, changer libc ? ;)
malloc est peu coûteux, plus coûteux que rien c'est sur, mais pas tant
que ça non plus, c'est très rarement le facteur limitant.
Le problème du buffer overflow n'est pas que le buffer soit fixe, c'est
savoir comment utiliser judicieusement le buffer qu'on a prévu (par
exemple buffer de taille PATH_MAX fixe) en tenant compte des paramètres
du système (PATH_MAX par exemple).
C'est aussi qu'il est sur la pile, et donc beaucoup plus dangereux
(car si on déborde, on tape sur la sauvegarde de EIP ou
équivalent).
Ah ? Moi je n'en ai vu aucune qui soit flexible (utilisable avec un
nombre qeulconque de chaines) et qui n'impose pas de limite statique à
la taille du résultat.
Le faire planter oui, le contraindre à exécuter du code arbitraire,
beaucoup plus difficilement, vu que le débordement ne se fait pas sur
la piule, on ne peut pas écraser l'addresse de retour de la fonction
Et tu verras si tu les lis, ces standrads, que PATH_MAX est
_optionnel_, un système POSIX n'est PAS obligé de définir PATH_MAX. Ce
que dit POSIX c'est "si le système définit PATH_MAX, alors aucun
chemin ne peut dépasser PATH_MAX", mais certains systèmes POSIX (comme
GNU/Hurd) n'ont pas de limite.
Un 3ème point est qu'accumuler des allocations mémoires pour obtenir une
"meilleure" "sécurité" ne fait qu'aggraver les performances de ton
programmes. Et oui, la présence de malloc() tout le long de l'exécution
n'est pas signe de performance.
Mauvaise libc, changer libc ? ;)
malloc est peu coûteux, plus coûteux que rien c'est sur, mais pas tant
que ça non plus, c'est très rarement le facteur limitant.
Le problème du buffer overflow n'est pas que le buffer soit fixe, c'est
savoir comment utiliser judicieusement le buffer qu'on a prévu (par
exemple buffer de taille PATH_MAX fixe) en tenant compte des paramètres
du système (PATH_MAX par exemple).
C'est aussi qu'il est sur la pile, et donc beaucoup plus dangereux
(car si on déborde, on tape sur la sauvegarde de EIP ou
équivalent).
Ah ? Moi je n'en ai vu aucune qui soit flexible (utilisable avec un
nombre qeulconque de chaines) et qui n'impose pas de limite statique à
la taille du résultat.
Le faire planter oui, le contraindre à exécuter du code arbitraire,
beaucoup plus difficilement, vu que le débordement ne se fait pas sur
la piule, on ne peut pas écraser l'addresse de retour de la fonction
Et tu verras si tu les lis, ces standrads, que PATH_MAX est
_optionnel_, un système POSIX n'est PAS obligé de définir PATH_MAX. Ce
que dit POSIX c'est "si le système définit PATH_MAX, alors aucun
chemin ne peut dépasser PATH_MAX", mais certains systèmes POSIX (comme
GNU/Hurd) n'ont pas de limite.
Un 3ème point est qu'accumuler des allocations mémoires pour obtenir une
"meilleure" "sécurité" ne fait qu'aggraver les performances de ton
programmes. Et oui, la présence de malloc() tout le long de l'exécution
n'est pas signe de performance.
Mauvaise libc, changer libc ? ;)
malloc est peu coûteux, plus coûteux que rien c'est sur, mais pas tant
que ça non plus, c'est très rarement le facteur limitant.
Le problème du buffer overflow n'est pas que le buffer soit fixe, c'est
savoir comment utiliser judicieusement le buffer qu'on a prévu (par
exemple buffer de taille PATH_MAX fixe) en tenant compte des paramètres
du système (PATH_MAX par exemple).
C'est aussi qu'il est sur la pile, et donc beaucoup plus dangereux
(car si on déborde, on tape sur la sauvegarde de EIP ou
équivalent).
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdarg.h>
char *concat(char *s,...)
{
char *p;
va_list ap;
va_start(ap,s);
while ((p=va_arg(ap,char*))!=0) strcat(s,p);
va_end(ap);
return s;
}
int main()
{
char *s = malloc(100);
*s=0;
concat(s,"|Hel","lo, ","world","!|",0);
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdarg.h>
char *concat(char *s,...)
{
char *p;
va_list ap;
va_start(ap,s);
while ((p=va_arg(ap,char*))!=0) strcat(s,p);
va_end(ap);
return s;
}
int main()
{
char *s = malloc(100);
*s=0;
concat(s,"|Hel","lo, ","world","!|",0);
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdarg.h>
char *concat(char *s,...)
{
char *p;
va_list ap;
va_start(ap,s);
while ((p=va_arg(ap,char*))!=0) strcat(s,p);
va_end(ap);
return s;
}
int main()
{
char *s = malloc(100);
*s=0;
concat(s,"|Hel","lo, ","world","!|",0);
Ah ? Moi je n'en ai vu aucune qui soit flexible (utilisable avec un
nombre qeulconque de chaines) et qui n'impose pas de limite statique à
la taille du résultat.
La solution de Horst Kraemer résolvait le problème en l'adaptant un
petit peu.
Par contre, l'utilisation initiale ne demandait peut-être pas un nombre
quelconque de chaînes de caractères ou une taille illimitée. Qui sait ?
Le faire planter oui, le contraindre à exécuter du code arbitraire,
beaucoup plus difficilement, vu que le débordement ne se fait pas sur
la piule, on ne peut pas écraser l'addresse de retour de la fonction
Je pense que dans un cas comme dans l'autre, si le serveur d'un
client est planté (puisqu'on semble parler de mise en faille
distante), le problème est le même.
Enfin pour moi les problèmes sont tout aussi grave.
<valable sous Linux>
Quand à ce qui est de l'exécution sur pile, en mettant un buffer
statique (static), on résout le problème puisqu'on fait passer le bloc
sur le segment de données.
(Quelle saugrenue idée de rendre exécutable la pile !)
</valable sous Linux>
Et tu verras si tu les lis, ces standrads, que PATH_MAX est
_optionnel_, un système POSIX n'est PAS obligé de définir PATH_MAX. Ce
que dit POSIX c'est "si le système définit PATH_MAX, alors aucun
chemin ne peut dépasser PATH_MAX", mais certains systèmes POSIX (comme
GNU/Hurd) n'ont pas de limite.
Effectivement, mais on peut forcer la valeur à _XOPEN_PATH_MAX ou à une
valeur arbitraire comme 1024 si PATH_MAX n'existe pas.
Un 3ème point est qu'accumuler des allocations mémoires pour obtenir une
"meilleure" "sécurité" ne fait qu'aggraver les performances de ton
programmes. Et oui, la présence de malloc() tout le long de l'exécution
n'est pas signe de performance.
Mauvaise libc, changer libc ? ;)
l'implémentation GNU ne me paraissait pas si catastrophique pourtant ...
malloc est peu coûteux, plus coûteux que rien c'est sur, mais pas tant
que ça non plus, c'est très rarement le facteur limitant.
c'est déjà plus coûteux qu'une allocation statique.
Le problème du buffer overflow n'est pas que le buffer soit fixe, c'est
savoir comment utiliser judicieusement le buffer qu'on a prévu (par
exemple buffer de taille PATH_MAX fixe) en tenant compte des paramètres
du système (PATH_MAX par exemple).
C'est aussi qu'il est sur la pile, et donc beaucoup plus dangereux
(car si on déborde, on tape sur la sauvegarde de EIP ou
équivalent).
C'est quoi EIP ;) ?
Ah ? Moi je n'en ai vu aucune qui soit flexible (utilisable avec un
nombre qeulconque de chaines) et qui n'impose pas de limite statique à
la taille du résultat.
La solution de Horst Kraemer résolvait le problème en l'adaptant un
petit peu.
Par contre, l'utilisation initiale ne demandait peut-être pas un nombre
quelconque de chaînes de caractères ou une taille illimitée. Qui sait ?
Le faire planter oui, le contraindre à exécuter du code arbitraire,
beaucoup plus difficilement, vu que le débordement ne se fait pas sur
la piule, on ne peut pas écraser l'addresse de retour de la fonction
Je pense que dans un cas comme dans l'autre, si le serveur d'un
client est planté (puisqu'on semble parler de mise en faille
distante), le problème est le même.
Enfin pour moi les problèmes sont tout aussi grave.
<valable sous Linux>
Quand à ce qui est de l'exécution sur pile, en mettant un buffer
statique (static), on résout le problème puisqu'on fait passer le bloc
sur le segment de données.
(Quelle saugrenue idée de rendre exécutable la pile !)
</valable sous Linux>
Et tu verras si tu les lis, ces standrads, que PATH_MAX est
_optionnel_, un système POSIX n'est PAS obligé de définir PATH_MAX. Ce
que dit POSIX c'est "si le système définit PATH_MAX, alors aucun
chemin ne peut dépasser PATH_MAX", mais certains systèmes POSIX (comme
GNU/Hurd) n'ont pas de limite.
Effectivement, mais on peut forcer la valeur à _XOPEN_PATH_MAX ou à une
valeur arbitraire comme 1024 si PATH_MAX n'existe pas.
Un 3ème point est qu'accumuler des allocations mémoires pour obtenir une
"meilleure" "sécurité" ne fait qu'aggraver les performances de ton
programmes. Et oui, la présence de malloc() tout le long de l'exécution
n'est pas signe de performance.
Mauvaise libc, changer libc ? ;)
l'implémentation GNU ne me paraissait pas si catastrophique pourtant ...
malloc est peu coûteux, plus coûteux que rien c'est sur, mais pas tant
que ça non plus, c'est très rarement le facteur limitant.
c'est déjà plus coûteux qu'une allocation statique.
Le problème du buffer overflow n'est pas que le buffer soit fixe, c'est
savoir comment utiliser judicieusement le buffer qu'on a prévu (par
exemple buffer de taille PATH_MAX fixe) en tenant compte des paramètres
du système (PATH_MAX par exemple).
C'est aussi qu'il est sur la pile, et donc beaucoup plus dangereux
(car si on déborde, on tape sur la sauvegarde de EIP ou
équivalent).
C'est quoi EIP ;) ?
Ah ? Moi je n'en ai vu aucune qui soit flexible (utilisable avec un
nombre qeulconque de chaines) et qui n'impose pas de limite statique à
la taille du résultat.
La solution de Horst Kraemer résolvait le problème en l'adaptant un
petit peu.
Par contre, l'utilisation initiale ne demandait peut-être pas un nombre
quelconque de chaînes de caractères ou une taille illimitée. Qui sait ?
Le faire planter oui, le contraindre à exécuter du code arbitraire,
beaucoup plus difficilement, vu que le débordement ne se fait pas sur
la piule, on ne peut pas écraser l'addresse de retour de la fonction
Je pense que dans un cas comme dans l'autre, si le serveur d'un
client est planté (puisqu'on semble parler de mise en faille
distante), le problème est le même.
Enfin pour moi les problèmes sont tout aussi grave.
<valable sous Linux>
Quand à ce qui est de l'exécution sur pile, en mettant un buffer
statique (static), on résout le problème puisqu'on fait passer le bloc
sur le segment de données.
(Quelle saugrenue idée de rendre exécutable la pile !)
</valable sous Linux>
Et tu verras si tu les lis, ces standrads, que PATH_MAX est
_optionnel_, un système POSIX n'est PAS obligé de définir PATH_MAX. Ce
que dit POSIX c'est "si le système définit PATH_MAX, alors aucun
chemin ne peut dépasser PATH_MAX", mais certains systèmes POSIX (comme
GNU/Hurd) n'ont pas de limite.
Effectivement, mais on peut forcer la valeur à _XOPEN_PATH_MAX ou à une
valeur arbitraire comme 1024 si PATH_MAX n'existe pas.
Un 3ème point est qu'accumuler des allocations mémoires pour obtenir une
"meilleure" "sécurité" ne fait qu'aggraver les performances de ton
programmes. Et oui, la présence de malloc() tout le long de l'exécution
n'est pas signe de performance.
Mauvaise libc, changer libc ? ;)
l'implémentation GNU ne me paraissait pas si catastrophique pourtant ...
malloc est peu coûteux, plus coûteux que rien c'est sur, mais pas tant
que ça non plus, c'est très rarement le facteur limitant.
c'est déjà plus coûteux qu'une allocation statique.
Le problème du buffer overflow n'est pas que le buffer soit fixe, c'est
savoir comment utiliser judicieusement le buffer qu'on a prévu (par
exemple buffer de taille PATH_MAX fixe) en tenant compte des paramètres
du système (PATH_MAX par exemple).
C'est aussi qu'il est sur la pile, et donc beaucoup plus dangereux
(car si on déborde, on tape sur la sauvegarde de EIP ou
équivalent).
C'est quoi EIP ;) ?
(Quelle saugrenue idée de rendre exécutable la pile !)
(Quelle saugrenue idée de rendre exécutable la pile !)
(Quelle saugrenue idée de rendre exécutable la pile !)
Enfin, il y a la solution utilise asprintf (libc GNU) ou
g_strdup_printf (GLib) qui fonctionne comme snprintf mais alloue
automatiquement la taille nécessaire.
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Et une autre mauvaise habitude consiste à travailler avec des buffers
de taille fixe (pire, des char buf[SIZE] et bonjour l'exploit au
moindre bug) qui sont la plupart du temps du gachis de mémoire (buffer
trop grand) et le reste du temps des limitations (buffer trop petit).
Prendre l'habitude d'utiliser des fonctions propres (comme celle de
libc GNU), quitte à les inclure ensuite dans le programme c'est
beaucoup plus positif. (et je rappelle à tout le monde que, par
exemple, un nom de fichier ou une URL n'ont _pas_ de taille limite,
pas 512, pas 4096, pas PATHMAX, pas même fpathconf).
Enfin, il y a la solution utilise asprintf (libc GNU) ou
g_strdup_printf (GLib) qui fonctionne comme snprintf mais alloue
automatiquement la taille nécessaire.
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Et une autre mauvaise habitude consiste à travailler avec des buffers
de taille fixe (pire, des char buf[SIZE] et bonjour l'exploit au
moindre bug) qui sont la plupart du temps du gachis de mémoire (buffer
trop grand) et le reste du temps des limitations (buffer trop petit).
Prendre l'habitude d'utiliser des fonctions propres (comme celle de
libc GNU), quitte à les inclure ensuite dans le programme c'est
beaucoup plus positif. (et je rappelle à tout le monde que, par
exemple, un nom de fichier ou une URL n'ont _pas_ de taille limite,
pas 512, pas 4096, pas PATHMAX, pas même fpathconf).
Enfin, il y a la solution utilise asprintf (libc GNU) ou
g_strdup_printf (GLib) qui fonctionne comme snprintf mais alloue
automatiquement la taille nécessaire.
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Et une autre mauvaise habitude consiste à travailler avec des buffers
de taille fixe (pire, des char buf[SIZE] et bonjour l'exploit au
moindre bug) qui sont la plupart du temps du gachis de mémoire (buffer
trop grand) et le reste du temps des limitations (buffer trop petit).
Prendre l'habitude d'utiliser des fonctions propres (comme celle de
libc GNU), quitte à les inclure ensuite dans le programme c'est
beaucoup plus positif. (et je rappelle à tout le monde que, par
exemple, un nom de fichier ou une URL n'ont _pas_ de taille limite,
pas 512, pas 4096, pas PATHMAX, pas même fpathconf).
<valable sous Linux>
Quand à ce qui est de l'exécution sur pile, en mettant un buffer
statique (static), on résout le problème puisqu'on fait passer le bloc
sur le segment de données.
(Quelle saugrenue idée de rendre exécutable la pile !)
</valable sous Linux>
<valable sous Linux>
Quand à ce qui est de l'exécution sur pile, en mettant un buffer
statique (static), on résout le problème puisqu'on fait passer le bloc
sur le segment de données.
(Quelle saugrenue idée de rendre exécutable la pile !)
</valable sous Linux>
<valable sous Linux>
Quand à ce qui est de l'exécution sur pile, en mettant un buffer
statique (static), on résout le problème puisqu'on fait passer le bloc
sur le segment de données.
(Quelle saugrenue idée de rendre exécutable la pile !)
</valable sous Linux>
Et cette technique d'implementation necessite d'avoir, au moins,
des bouts de pile executable, car elle repose sur la generation de
`stubs' de code de maniere dynamique a l'execution.
Et cette technique d'implementation necessite d'avoir, au moins,
des bouts de pile executable, car elle repose sur la generation de
`stubs' de code de maniere dynamique a l'execution.
Et cette technique d'implementation necessite d'avoir, au moins,
des bouts de pile executable, car elle repose sur la generation de
`stubs' de code de maniere dynamique a l'execution.
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Et une autre mauvaise habitude consiste à travailler avec des buffers
de taille fixe (pire, des char buf[SIZE] et bonjour l'exploit au
moindre bug) qui sont la plupart du temps du gachis de mémoire (buffer
trop grand) et le reste du temps des limitations (buffer trop petit).
Prendre l'habitude d'utiliser des fonctions propres (comme celle de
libc GNU), quitte à les inclure ensuite dans le programme c'est
beaucoup plus positif. (et je rappelle à tout le monde que, par
exemple, un nom de fichier ou une URL n'ont _pas_ de taille limite,
pas 512, pas 4096, pas PATHMAX, pas même fpathconf).
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, avoir des chemins de taille quelconque, c'est parfois utile.
Meme si ca sert en pratique parfois. A cote de cela, on attend
toujours l'integration de certaines fonctions sures comme strlcpy
ou strlcat dans la glibc, si je ne m'abuse...
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Et une autre mauvaise habitude consiste à travailler avec des buffers
de taille fixe (pire, des char buf[SIZE] et bonjour l'exploit au
moindre bug) qui sont la plupart du temps du gachis de mémoire (buffer
trop grand) et le reste du temps des limitations (buffer trop petit).
Prendre l'habitude d'utiliser des fonctions propres (comme celle de
libc GNU), quitte à les inclure ensuite dans le programme c'est
beaucoup plus positif. (et je rappelle à tout le monde que, par
exemple, un nom de fichier ou une URL n'ont _pas_ de taille limite,
pas 512, pas 4096, pas PATHMAX, pas même fpathconf).
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, avoir des chemins de taille quelconque, c'est parfois utile.
Meme si ca sert en pratique parfois. A cote de cela, on attend
toujours l'integration de certaines fonctions sures comme strlcpy
ou strlcat dans la glibc, si je ne m'abuse...
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Et une autre mauvaise habitude consiste à travailler avec des buffers
de taille fixe (pire, des char buf[SIZE] et bonjour l'exploit au
moindre bug) qui sont la plupart du temps du gachis de mémoire (buffer
trop grand) et le reste du temps des limitations (buffer trop petit).
Prendre l'habitude d'utiliser des fonctions propres (comme celle de
libc GNU), quitte à les inclure ensuite dans le programme c'est
beaucoup plus positif. (et je rappelle à tout le monde que, par
exemple, un nom de fichier ou une URL n'ont _pas_ de taille limite,
pas 512, pas 4096, pas PATHMAX, pas même fpathconf).
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, avoir des chemins de taille quelconque, c'est parfois utile.
Meme si ca sert en pratique parfois. A cote de cela, on attend
toujours l'integration de certaines fonctions sures comme strlcpy
ou strlcat dans la glibc, si je ne m'abuse...
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, GNU/Hurd n'a pas de limites, par conception même, toute forme de
limites en est banni. Rendre la liberté aux utilisateurs, c'est aussi
éviter que l'utilisateur ne subisse des limites codées en dur dans les
applications, ni des limites techniques, comme l'impossibilité de
"monter" une image ISO sans être root, ou
le fait de devoir se
reloguer pour être rajouer à un groupe.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, GNU/Hurd n'a pas de limites, par conception même, toute forme de
limites en est banni. Rendre la liberté aux utilisateurs, c'est aussi
éviter que l'utilisateur ne subisse des limites codées en dur dans les
applications, ni des limites techniques, comme l'impossibilité de
"monter" une image ISO sans être root, ou
le fait de devoir se
reloguer pour être rajouer à un groupe.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
De plus, la nature virale de la licence GPL pose aussi probleme: si
on commence a developper en integrant des bouts de code GPL, on place
d'office le developpement sous licence GPL... et on se coupe de certaines
personnes, qui auront un a priori tres negatif vis-a-vis de la GPL, et
de certaines possibilites de faire evoluer son code, vers certaines
pratiques commerciales par exemple.
Moi, je prefere que ca soit un choix assume, que la personne qui utilise
du code GPL sache bien dans quel engrenage elle met son doigt.
Il n'y a, helas ou heureusement, pas que le critere technique de la
qualite du code concerne a considerer.
Tiens, ca sent tres fort le Hurd, ca, comme habitude.
Oui, GNU/Hurd n'a pas de limites, par conception même, toute forme de
limites en est banni. Rendre la liberté aux utilisateurs, c'est aussi
éviter que l'utilisateur ne subisse des limites codées en dur dans les
applications, ni des limites techniques, comme l'impossibilité de
"monter" une image ISO sans être root, ou
le fait de devoir se
reloguer pour être rajouer à un groupe.
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
Non, en effet, il faut aussi un peu se préoccuper de problèmes
éthiques et défendre la liberté de son code.
strlcpy et strlcat sûres ? mwarf, elles n'apportent quasiment rien de
plus que des strncpy et strncat, désolé, chez GNU on préfère éviter
les buffers statiques plutôt que de rajouter des fonctions pour les
gérer de manière un peu moins non-sûre.
On a strndup, asprintf, ... plutôt.
Enfin, comme toujours, chez BSD on préfère rajouter des ristounes
plutôt que de revoir la conception. On préfère faire des jails et
coder des "privilege separation" au niveau des applis, plutôt que
d'avoir une infrastructure qui permet de gagner et perdre
dynamiquement des jetons de sécurité, de faire tourner réellement
plusieurs piles TCP/IP n'ayant pas de privilèges... Moi je préfère
concevoir les choses proprement plutôt que de faire des bidouilles.
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
Non, en effet, il faut aussi un peu se préoccuper de problèmes
éthiques et défendre la liberté de son code.
strlcpy et strlcat sûres ? mwarf, elles n'apportent quasiment rien de
plus que des strncpy et strncat, désolé, chez GNU on préfère éviter
les buffers statiques plutôt que de rajouter des fonctions pour les
gérer de manière un peu moins non-sûre.
On a strndup, asprintf, ... plutôt.
Enfin, comme toujours, chez BSD on préfère rajouter des ristounes
plutôt que de revoir la conception. On préfère faire des jails et
coder des "privilege separation" au niveau des applis, plutôt que
d'avoir une infrastructure qui permet de gagner et perdre
dynamiquement des jetons de sécurité, de faire tourner réellement
plusieurs piles TCP/IP n'ayant pas de privilèges... Moi je préfère
concevoir les choses proprement plutôt que de faire des bidouilles.
Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.
Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.
Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.
Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.
Non, en effet, il faut aussi un peu se préoccuper de problèmes
éthiques et défendre la liberté de son code.
strlcpy et strlcat sûres ? mwarf, elles n'apportent quasiment rien de
plus que des strncpy et strncat, désolé, chez GNU on préfère éviter
les buffers statiques plutôt que de rajouter des fonctions pour les
gérer de manière un peu moins non-sûre.
On a strndup, asprintf, ... plutôt.
Enfin, comme toujours, chez BSD on préfère rajouter des ristounes
plutôt que de revoir la conception. On préfère faire des jails et
coder des "privilege separation" au niveau des applis, plutôt que
d'avoir une infrastructure qui permet de gagner et perdre
dynamiquement des jetons de sécurité, de faire tourner réellement
plusieurs piles TCP/IP n'ayant pas de privilèges... Moi je préfère
concevoir les choses proprement plutôt que de faire des bidouilles.
