Re: Problemes amb automysqlbackup combinat amb un "locale" en català

2020-12-20 Conversa Orestes Mas 
El diumenge, 20 de desembre de 2020, a les 10:40:27 CET, Joan Montané va 
escriure:

> Hola,
> 
> Anem a pams, que potser s'estan barrejant temes.
> 
> Els canvis a la glibc es van per fer coincidir els formats de data amb el
> CLDR. Objectivament, aquests canvis permeten escriure les dates
> correctament. És a dir, la iniciativa original no va ser des de Softcatalà,
> però sí a la glibc. En castellà no apostrofen els mesos, per això en el
> format de data tenen "hardcoded" la preposició "de". En francès no usen la
> preposició "de" en les dates (sospito que en el seu dia van triar fer-ho
> així per a evitar el problema de l'apostrofació)
> 
> En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o
> majúscula) en el format de date perquè usi el format sense proposició.
> Hauria de funcionar en tots els locales. P.ex: date -d "2018/04/01" +"%OB"
> retorna "abril" (sense preposició).
> 
> El tema dels mesos incorrectes a "ls -l" no està directament relacionat amb
> això. És un altre problema que se suposa ja està corregit i tard o d'hora
> arribarà tothom [1]
> 
> Salutacions,
> Joan Montané
> 
> Més informació:
> https://rluzynski.fedorapeople.org/slides/2017-01-27-DevConf.cz/GenitiveMon
> ths-updated.pdf I, en concret per al català:
> https://www.softcatala.org/projectes/abril/ [1]
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963513


Desconeixia que "+%OB" retorna el nom del mes en "cas nominatiu". Molt 
interessant. En el cas que ens ocupa (català) això podria ser la solució, però 
desconec si en altres llengües arreglaria el problema o no.

En qualsevol cas, potser el desenvolupador de automysqlbackup desconeix aquest 
canvi a la glibc. Serà qüestió d'esbrinar-ho.

-- 
Cordialment,
Orestes Mas

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

2020-12-20 Conversa Orestes Mas 
El diumenge, 20 de desembre de 2020, a les 13:36:42 CET, Eloi va escriure:
Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1] i l'he 
encertat de ple: 
com es pot veure a la funció shell, definida a partir de la línia 424, tant $1 
com $2 no estan 
degudament protegits. 
El fet que un espai en blanc trenqui la creació de còpies de seguretat, per si 
sol, entenc 
que mereix que el bug tingui una severitat major que normal. Ara bé, que $1 
tampoc 
estigui protegit i el paràmetre correspongui a una dada facilitada per 
l'usuari, el nom de la 
base de dades, em fa témer que podria arribar a explotar-se com a 
vulnerabilitat per a la 
injecció de comandes. Per exemple: una configuració que fes còpia d'una base de 
dades 
"foo; dropdb foo" (en el cas de treballar amb Postgres, on tinc experiència) 
podria, segons 
els permisos, destruir la base de dades, el que ho faria un bug crític [2]. Ara 
bé, no he 
comprovat fins a quin punt és explotable, però és quelcom que fa saltar totes 
les meves 
alarmes. 
També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es tractés 
d'una 
"cometa simple", causaria error i no completaria el backup. 
L'altre tema és el d'anomenar els backups en funció del locale, que està bé per 
a humans 
però és terrible per a gestió automàtica per a màquines. Si jo fes anar 
l'script (i, pel que he 
vist fins ara, el deixaria de fer servir immediatament) obriria dos bug 
reports: el primer, 
més greu, amb el problema d'escapament dels paràmetres de la funció dbdump; i 
el 
segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de forma 
humana 
(com fins ara) o mecànica (en un format -MM-DD o similar però respectant 
l'ordre 
any-mes-dia i 4-2-2 dígits). 
No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, doncs no 
podria 
donar respostes a preguntes addicionals del desenvolupador o de l'empaquetador, 
però 
puc ajudar a qui l'obri.


[1] 
[1]
 
cf. [2] 
[2] https://xkcd.com/327/[3]

Ostres, *moltes* gràcies a tots els qui heu respost aportant el vostre punt de 
vista. Ja em 
semblava que la cosa tenia més suc i transcendència del que hom podia pensar a 
primera 
vista, i el resultat no m'ha decebut gens :-)

Atès que sóc jo qui ha iniciat el fil veig que em tocarà a mi d'obrir el bug 
contra 
l'automysqlbackup. Passa que vaig una mica atrafegat amb el final de curs i no 
sé ben bé 
quan podré fer-ho. A més, tampoc no sóc gens expert en els temes de locale, 
libc, bash i 
demés. Vull dir que obrir el bug m'hi veig en cor, però proposar solucions més 
enllà de les 
que heu comentat (protegir les variables amb cometes, etc.) ja no tant.

En tot cas ho provo i si el desenvolupador demana més coses, aleshores ja us 
demanaré 
consell a vosaltres.

-- 
Cordialment,
Orestes Mas


[1] https://salsa.debian.org/zigo/automysqlbackup/-/blob/debian/automysqlbackup
[2] https://tracker.debian.org/pkg/automysqlbackup
[3] https://xkcd.com/327/

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

2020-12-20 Conversa julio 
"Doble quote lost in space", m'encanten aquestes novel•les de misteri 
col•laboratives.
+1000

Le 20 décembre 2020 13:36:42 GMT+01:00, Eloi  a écrit :
>El 20/12/20 a les 12:27, Joan Montané ha escrit:
>>
>>
>> Missatge de Josep Lladonosa > > del dia dg., 20 de des. 2020 a les
>11:56:
>>
>> Hola,
>>
>> Sembla que ja està encaminada la solució però volia aportar la
>> meva opinió:
>>
>> Per a mi és un "bug" d'aquest script ja que no hauria de suposar
>> que les dates no tinguin espais si s'han d'usar en nom de fitxer
>> ja que un nom de fitxer pot contenir-ne, d'espais.
>>
>> Potser es pot reportar un bug al creador del script i fins i tot
>> fer una proposta per resoldre'l, "escapant" el nom de fitxer.
>>
>>
>> Efectivament, en el cas particular que ens ocupa hi ha dues coses que
>
>> coincideixen, i fan aparèixer el problema:
>>
>> 1. En algunes llengües, la variable que conté el nom del mes conté un
>
>> espai. És el cas de català si s'usa el format %B per a tots els mesos
>
>> menys abril, agost i octubre.
>> 2. L'script no escapa els possibles espais de les variables i si hi
>ha 
>> espais, aleshores l'script no fa el que se suposa que ha de fer.
>>
>> L'error és a 2 (no es pot assumir alegrement que una variable no té 
>> espais). El problema es podria rodejar usant "%OB" a l'script per a 
>> extraure els noms de mesos (totes les llengües que he mirat retornen 
>> els mesos sense espai), però això segueix sense garantir que les 
>> cadenes no tindran espais, i el problema descrit a 2 podria tornar a 
>> reproduir-se. La solució bona és escapar els espais de les variables,
>
>> amb les cometes dobles.
>>
>> Com diu el Josep, el millor és obrir un bug a automysqlbackup i, 
>> idealment, aportar-hi la solució.
>
>Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1]
>
>i l'he encertat de ple: com es pot veure a la funció shell, definida a 
>partir de la línia 424, tant $1 com $2 no estan degudament protegits.
>
>El fet que un espai en blanc trenqui la creació de còpies de seguretat,
>
>per si sol, entenc que mereix que el bug tingui una severitat major que
>
>normal. Ara bé, que $1 tampoc estigui protegit i el paràmetre 
>correspongui a una dada facilitada per l'usuari, el nom de la base de 
>dades, em fa témer que podria arribar a explotar-se com a
>vulnerabilitat 
>per a la injecció de comandes. Per exemple: una configuració que fes 
>còpia d'una base de dades "foo; dropdb foo" (en el cas de treballar amb
>
>Postgres, on tinc experiència) podria, segons els permisos, destruir la
>
>base de dades, el que ho faria un bug crític [2]. Ara bé, no he 
>comprovat fins a quin punt és explotable, però és quelcom que fa saltar
>
>totes les meves alarmes.
>
>També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es 
>tractés d'una "cometa simple", causaria error i no completaria el
>backup.
>
>L'altre tema és el d'anomenar els backups en funció del locale, que
>està 
>bé per a humans però és terrible per a gestió automàtica per a
>màquines. 
>Si jo fes anar l'script (i, pel que he vist fins ara, el deixaria de
>fer 
>servir immediatament) obriria dos bug reports: el primer, més greu, amb
>
>el problema d'escapament dels paràmetres de la funció dbdump; i el 
>segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de
>
>forma humana (com fins ara) o mecànica (en un format -MM-DD o 
>similar però respectant l'ordre any-mes-dia i 4-2-2 dígits).
>
>No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, 
>doncs no podria donar respostes a preguntes addicionals del 
>desenvolupador o de l'empaquetador, però puc ajudar a qui l'obri.
>
>[1] 
>
>
>cf. 
>
>[2] https://xkcd.com/327/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

2020-12-20 Conversa Eloi 

El 20/12/20 a les 12:27, Joan Montané ha escrit:



Missatge de Josep Lladonosa > del dia dg., 20 de des. 2020 a les 11:56:


Hola,

Sembla que ja està encaminada la solució però volia aportar la
meva opinió:

Per a mi és un "bug" d'aquest script ja que no hauria de suposar
que les dates no tinguin espais si s'han d'usar en nom de fitxer
ja que un nom de fitxer pot contenir-ne, d'espais.

Potser es pot reportar un bug al creador del script i fins i tot
fer una proposta per resoldre'l, "escapant" el nom de fitxer.


Efectivament, en el cas particular que ens ocupa hi ha dues coses que 
coincideixen, i fan aparèixer el problema:


1. En algunes llengües, la variable que conté el nom del mes conté un 
espai. És el cas de català si s'usa el format %B per a tots els mesos 
menys abril, agost i octubre.
2. L'script no escapa els possibles espais de les variables i si hi ha 
espais, aleshores l'script no fa el que se suposa que ha de fer.


L'error és a 2 (no es pot assumir alegrement que una variable no té 
espais). El problema es podria rodejar usant "%OB" a l'script per a 
extraure els noms de mesos (totes les llengües que he mirat retornen 
els mesos sense espai), però això segueix sense garantir que les 
cadenes no tindran espais, i el problema descrit a 2 podria tornar a 
reproduir-se. La solució bona és escapar els espais de les variables, 
amb les cometes dobles.


Com diu el Josep, el millor és obrir un bug a automysqlbackup i, 
idealment, aportar-hi la solució.


Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1] 
i l'he encertat de ple: com es pot veure a la funció shell, definida a 
partir de la línia 424, tant $1 com $2 no estan degudament protegits.


El fet que un espai en blanc trenqui la creació de còpies de seguretat, 
per si sol, entenc que mereix que el bug tingui una severitat major que 
normal. Ara bé, que $1 tampoc estigui protegit i el paràmetre 
correspongui a una dada facilitada per l'usuari, el nom de la base de 
dades, em fa témer que podria arribar a explotar-se com a vulnerabilitat 
per a la injecció de comandes. Per exemple: una configuració que fes 
còpia d'una base de dades "foo; dropdb foo" (en el cas de treballar amb 
Postgres, on tinc experiència) podria, segons els permisos, destruir la 
base de dades, el que ho faria un bug crític [2]. Ara bé, no he 
comprovat fins a quin punt és explotable, però és quelcom que fa saltar 
totes les meves alarmes.


També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es 
tractés d'una "cometa simple", causaria error i no completaria el backup.


L'altre tema és el d'anomenar els backups en funció del locale, que està 
bé per a humans però és terrible per a gestió automàtica per a màquines. 
Si jo fes anar l'script (i, pel que he vist fins ara, el deixaria de fer 
servir immediatament) obriria dos bug reports: el primer, més greu, amb 
el problema d'escapament dels paràmetres de la funció dbdump; i el 
segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de 
forma humana (com fins ara) o mecànica (en un format -MM-DD o 
similar però respectant l'ordre any-mes-dia i 4-2-2 dígits).


No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, 
doncs no podria donar respostes a preguntes addicionals del 
desenvolupador o de l'empaquetador, però puc ajudar a qui l'obri.


[1] 
 
cf. 


[2] https://xkcd.com/327/

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

2020-12-20 Conversa Joan Montané 
Missatge de Josep Lladonosa  del dia dg., 20 de des.
2020 a les 11:56:

> Hola,
>
> Sembla que ja està encaminada la solució però volia aportar la meva opinió:
>
> Per a mi és un "bug" d'aquest script ja que no hauria de suposar que les
> dates no tinguin espais si s'han d'usar en nom de fitxer ja que un nom de
> fitxer pot contenir-ne, d'espais.
>
> Potser es pot reportar un bug al creador del script i fins i tot fer una
> proposta per resoldre'l, "escapant" el nom de fitxer.
>
>
Efectivament, en el cas particular que ens ocupa hi ha dues coses que
coincideixen, i fan aparèixer el problema:

1. En algunes llengües, la variable que conté el nom del mes conté un
espai. És el cas de català si s'usa el format %B per a tots els mesos menys
abril, agost i octubre.
2. L'script no escapa els possibles espais de les variables i si hi ha
espais, aleshores l'script no fa el que se suposa que ha de fer.

L'error és a 2 (no es pot assumir alegrement que una variable no té
espais). El problema es podria rodejar usant "%OB" a l'script per a
extraure els noms de mesos (totes les llengües que he mirat retornen els
mesos sense espai), però això segueix sense garantir que les cadenes no
tindran espais, i el problema descrit a 2 podria tornar a reproduir-se. La
solució bona és escapar els espais de les variables, amb les cometes dobles.

Com diu el Josep, el millor és obrir un bug a automysqlbackup i, idealment,
aportar-hi la solució.

Salut!
Joan Montané

PS: encara gràcies que amb %B "d'abril", "d'agost" i "d'octubre" usen
l'apòstrof tipogràfic, perquè sospito que si usessin l'apòstrof recte,
l'script també hauria tingut problemes en aquests mesos.

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

2020-12-20 Conversa Josep Lladonosa 
Hola,

Sembla que ja està encaminada la solució però volia aportar la meva opinió:

Per a mi és un "bug" d'aquest script ja que no hauria de suposar que les
dates no tinguin espais si s'han d'usar en nom de fitxer ja que un nom de
fitxer pot contenir-ne, d'espais.

Potser es pot reportar un bug al creador del script i fins i tot fer una
proposta per resoldre'l, "escapant" el nom de fitxer.

Salutacions,
Josep

On Sun, 20 Dec 2020 at 11:07, Ernest Adrogué  wrote:

> 2020-12-20, 10:40 (+0100); Joan Montané escriu:
> > Anem a pams, que potser s'estan barrejant temes.
> >
> > Els canvis a la glibc es van per fer coincidir els formats de data amb el
> > CLDR. Objectivament, aquests canvis permeten escriure les dates
> > correctament. És a dir, la iniciativa original no va ser des de
> Softcatalà,
> > però sí a la glibc.
> > En castellà no apostrofen els mesos, per això en el format de data tenen
> > "hardcoded" la preposició "de".
> > En francès no usen la preposició "de" en les dates (sospito que en el seu
> > dia van triar fer-ho així per a evitar el problema de l'apostrofació)
> >
> > En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o
> > majúscula) en el format de date perquè usi el format sense proposició.
> > Hauria de funcionar en tots els locales. P.ex:  date -d "2018/04/01"
> +"%OB"
> > retorna "abril" (sense preposició).
> >
> > El tema dels mesos incorrectes a "ls -l" no està directament relacionat
> amb
> > això. És un altre problema que se suposa ja està corregit i tard o d'hora
> > arribarà tothom [1]
>
> Gràcies per l'aclariment.
>
>

-- 
--
Salutacions...Josep
--

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

2020-12-20 Conversa Ernest Adrogué 
2020-12-20, 10:40 (+0100); Joan Montané escriu:
> Anem a pams, que potser s'estan barrejant temes.
> 
> Els canvis a la glibc es van per fer coincidir els formats de data amb el
> CLDR. Objectivament, aquests canvis permeten escriure les dates
> correctament. És a dir, la iniciativa original no va ser des de Softcatalà,
> però sí a la glibc.
> En castellà no apostrofen els mesos, per això en el format de data tenen
> "hardcoded" la preposició "de".
> En francès no usen la preposició "de" en les dates (sospito que en el seu
> dia van triar fer-ho així per a evitar el problema de l'apostrofació)
> 
> En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o
> majúscula) en el format de date perquè usi el format sense proposició.
> Hauria de funcionar en tots els locales. P.ex:  date -d "2018/04/01" +"%OB"
> retorna "abril" (sense preposició).
> 
> El tema dels mesos incorrectes a "ls -l" no està directament relacionat amb
> això. És un altre problema que se suposa ja està corregit i tard o d'hora
> arribarà tothom [1]

Gràcies per l'aclariment.

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

2020-12-20 Conversa Ernest Adrogué 
2020-12-20, 03:51 (+0100); Toni Mas Soler escriu:
> Doncs jo ho entenc com un bug del propi locale. Voleu dir que som l'única
> llengua que es troba en aquesta situació?
> 
> Com a primer plantejament caldria considerar la correcció del locale per
> tal que un date +%B retorni el mes sense preposició.

Exacte, el problema és el local ca_ES.  Mireu aquest fil de fa 2 anys:

https://lists.debian.org/debian-user-catalan/2018/10/msg0.html

Pel que sembla, des de Softcatalà, van promoure un canvi al local ca_ES,
que és el que provoca que ara apareguin els mesos amb preposició en
llocs on no hi ha d'haver preposició.  Ni el francès [1], ni el castellà
[2], ni l'italià [3], que utilitzen els mesos igual que el català, han
fet cap canvi similar en els respectius locals

[1] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c

[2] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/es_ES;h=aa919a26267fd6311b71d7aeb81655e55787b4df;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c

[3] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c

Jo ja fa temps vaig canviar el local a "C" perquè no podia soportar més
els llistats de 'ls -l' amb els noms dels mesos equivocats.


Salutacions.