---

Hejsa

Jeg kunne godt tænke mig at lave en hjemmeside hvor folk
fx. kunne pinge og traceroute fra.

Dette ville jeg lave i python og den måde det skulle forgå
på var at folk indtastede domænet eller ipen i en form
også kaldte jeg ping med indholdet i formen.

Fx. ping variabel

men så kom jeg i tanke om at folk kunne putte kommandoer
med i den form fx. med | således at der fx. blev skrevet
adsltips.dk | rm -rf / så kommandoen kom til at hedde
ping adsltips.dk | rm -rf / eller noget.

Det ville jo være ret skidt.

Derfor tænkte jeg at en masse andre mennesker måtte have
haft samme problem og ville høre om der var nogen der havde
links til sider der omhandler løsning på problemet?

En mulighed jeg har overvejet er at gennemgå tekst strengen og
sikre at den kun indeholder a-zA-Z, 0-9 og . Vil det være nok
til at forhindre unoder eller hvordan bør jeg gribe det an?

Jeg er lidt i tvivl om spørgsmålet høre hjemme her eller i
dk.edb.programmering men her kommer det.


Martin
--
Besøg http://www.adsltips.dk for guider til
ADSL og opsætning af Cisco/Zyxel routere.

---

Den 18 Jul 2004 10:26:45 +0200 skrev Martin Schultz:
> Hejsa
>
> Jeg kunne godt tænke mig at lave en hjemmeside hvor folk
> fx. kunne pinge og traceroute fra.
>
> Dette ville jeg lave i python og den måde det skulle forgå
> på var at folk indtastede domænet eller ipen i en form
> også kaldte jeg ping med indholdet i formen.
>
> Fx. ping variabel
>
> men så kom jeg i tanke om at folk kunne putte kommandoer
> med i den form fx. med | således at der fx. blev skrevet
> adsltips.dk | rm -rf / så kommandoen kom til at hedde
> ping adsltips.dk | rm -rf / eller noget.
>
> Det ville jo være ret skidt.
>
> Derfor tænkte jeg at en masse andre mennesker måtte have
> haft samme problem og ville høre om der var nogen der havde
> links til sider der omhandler løsning på problemet?
>
> En mulighed jeg har overvejet er at gennemgå tekst strengen og
> sikre at den kun indeholder a-zA-Z, 0-9 og . Vil det være nok
> til at forhindre unoder eller hvordan bør jeg gribe det an?

I stedet for at bruge hvad der svarer til system() i C, så brug
hvad der svarer til fork()/exec().

Forskellen er at system() kalder "sh -c kommando", og det er sh
der deler op ved mellemrum, og fortolker semikolon'er og pipe-tegn.
Det gør exec() ikke, du skal så selv sørge for at dele ved
mellemrum.

Og hvis du husker "--" så bliver du heller ikke snydt af en der forsøger
at ping'e -f.

exec("/bin/ping","ping","--",host,NULL);

Denne løsning er meget mere sikker end at begynde at kigge efter
underlige tegn i hostnavnet, og sparer desuden lidt ressourcer (ingen
kald af sh). Hvordan det helt præcist skrives i Python må du selv
checke.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
>
> I stedet for at bruge hvad der svarer til system() i C, så brug
> hvad der svarer til fork()/exec().

Enig. Det er en god idé.

>
> Og hvis du husker "--" så bliver du heller ikke snydt af en der forsøger
> at ping'e -f.

Korrekt, men mig bekendt kan et korrekt hostnavn ikke
begynde med "-", så man kunne blot afvise alle navne der
har "-" et ugyldigt sted.

>
> exec("/bin/ping","ping","--",host,NULL);

Jeg går ud fra du tænker på execl. I øvrigt bør man også
tænke på sit environment. I det her tilfælde tror jeg dog
ikke der er nogen risiko.

>
> Denne løsning er meget mere sikker end at begynde at kigge efter
> underlige tegn i hostnavnet, og sparer desuden lidt ressourcer (ingen
> kald af sh).

Det er rigtigt, men jeg ville dog stadig checke at navnet
var gyldigt inden jeg sendte det videre til ping. Samtidig
ville jeg, hvis det er muligt, vælge at køre programmet
under et seperat brugerid.

> Hvordan det helt præcist skrives i Python må du selv checke.

Jeg er heller ingen Python ekspert.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Den Sun, 18 Jul 2004 16:02:26 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> I stedet for at bruge hvad der svarer til system() i C, så brug
>> hvad der svarer til fork()/exec().
>
> Enig. Det er en god idé.
>
>> Og hvis du husker "--" så bliver du heller ikke snydt af en der forsøger
>> at ping'e -f.
>
> Korrekt, men mig bekendt kan et korrekt hostnavn ikke
> begynde med "-", så man kunne blot afvise alle navne der
> har "-" et ugyldigt sted.

Lige indtil man ramler ind i en ping der har samme vane som tar
(tar xfz a.tar) eller lignende.

>> exec("/bin/ping","ping","--",host,NULL);
>
> Jeg går ud fra du tænker på execl.

Egentlig irrelevant, jeg forsøgte blot at illustrere princippet. Det
hedder sandsynligvis noget helt andet i Python alligevel.

> I øvrigt bør man også
> tænke på sit environment. I det her tilfælde tror jeg dog
> ikke der er nogen risiko.

Korrekt

>> Denne løsning er meget mere sikker end at begynde at kigge efter
>> underlige tegn i hostnavnet, og sparer desuden lidt ressourcer (ingen
>> kald af sh).
>
> Det er rigtigt, men jeg ville dog stadig checke at navnet
> var gyldigt inden jeg sendte det videre til ping.

For et hostnavn giver det mening, da det er specificeret præcist hvad
sådan et må indeholde (hvilket kan bruges som whitelist). Men normalt
synes jeg ikke om princippet med at filtrere de farlige tegn fra
(blacklist), da man nemt overset en eller anden kunstruktion.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
>
> Lige indtil man ramler ind i en ping der har samme vane som tar
> (tar xfz a.tar) eller lignende.

Kan man finde en version af ping, der givet et
gyldigt hostnavn som argument finder på at
fortolke det som noget andet end et hostnavn?

>
> For et hostnavn giver det mening, da det er specificeret præcist hvad
> sådan et må indeholde (hvilket kan bruges som whitelist). Men normalt
> synes jeg ikke om princippet med at filtrere de farlige tegn fra
> (blacklist), da man nemt overset en eller anden kunstruktion.

Jeg mener ikke der er noget galt i fremgangsmåden.
Ethvert tegn er enten gyldigt eller ugyldigt. Og
hvis et gyldigt tegn kan være et problem skal der
bruges passende escaping.

Kan man vælge mellem forskellige fremgangsmåder
bør man naturligvis foretrække den hvor der er
færrest tegn, som skal escapes. Men i nogle
tilfælde kan man ikke undgå escaping.

Inden kode sættes i produktion bør man teste at
hele karaktersættet håndteres korrekt. Hvis der
er tegn man betragter som ugyldigt input skal de
også testes, for at se at fejlhåndteringen er
korrekt. (f.eks. en besked om at ` er et ugyldigt
tegn i et hostnavn).

Har man testet som beskrevet her, så har jeg
svært ved at se hvordan en fejl af denne type
kunne undgå at blive opdaget.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Den Sun, 18 Jul 2004 17:30:53 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> Lige indtil man ramler ind i en ping der har samme vane som tar
>> (tar xfz a.tar) eller lignende.
>
> Kan man finde en version af ping, der givet et
> gyldigt hostnavn som argument finder på at
> fortolke det som noget andet end et hostnavn?

Måske ikke lige for ping - men xfz er skam et gyldigt filnavn, selvom
tar opfatter det på en anden måde (og "-r" er også, selvom det kan
være svært at overbevise rm om det).

>> For et hostnavn giver det mening, da det er specificeret præcist hvad
>> sådan et må indeholde (hvilket kan bruges som whitelist). Men normalt
>> synes jeg ikke om princippet med at filtrere de farlige tegn fra
>> (blacklist), da man nemt overset en eller anden kunstruktion.
>
> Jeg mener ikke der er noget galt i fremgangsmåden.
> Ethvert tegn er enten gyldigt eller ugyldigt. Og
> hvis et gyldigt tegn kan være et problem skal der
> bruges passende escaping.
>
> Kan man vælge mellem forskellige fremgangsmåder
> bør man naturligvis foretrække den hvor der er
> færrest tegn, som skal escapes. Men i nogle
> tilfælde kan man ikke undgå escaping.
>
> Inden kode sættes i produktion bør man teste at
> hele karaktersættet håndteres korrekt.

Mon ikke Microsoft har brugt denne femgangsmåde? Og alligevel havde
de overset at flere UTF-8 konstruktioner giver samme unicode-tegn,
og pludselig kunne man alligevel ..\..\.. ud af wwwroot.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis wrote:
>
> Mon ikke Microsoft har brugt denne femgangsmåde? Og alligevel havde
> de overset at flere UTF-8 konstruktioner giver samme unicode-tegn,
> og pludselig kunne man alligevel ..\..\.. ud af wwwroot.

Jeg har altid syntes at UTF-8 var en forfærdelig opfindelse.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:

>> Mon ikke Microsoft har brugt denne femgangsm?de? Og alligevel havde
>> de overset at flere UTF-8 konstruktioner giver samme unicode-tegn,
>> og pludselig kunne man alligevel ..\..\.. ud af wwwroot.
>
> Jeg har altid syntes at UTF-8 var en forf?rdelig opfindelse.

Det kan godt vaere, men den er hamrende noedvendig.

--
j.

---

Jesper Louis Andersen <jlouis@miracle.mongers.org> wrote:

>Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:
>
>>> Mon ikke Microsoft har brugt denne femgangsm?de? Og alligevel havde
>>> de overset at flere UTF-8 konstruktioner giver samme unicode-tegn,
>>> og pludselig kunne man alligevel ..\..\.. ud af wwwroot.
>>
>> Jeg har altid syntes at UTF-8 var en forf?rdelig opfindelse.
>
>Det kan godt vaere, men den er hamrende noedvendig.

Ja. Jeg synes UTF-8 er en fremragende opfindelse.

Og i øvrigt foreskriver standarden faktisk at man *skal* bruge den
kanoniske form for et tegns kodning i UTF-8 - dvs. der er kun én
lovlig kodning af hvert Unicode-tegn.

Problemet er dårlige implementationer der accepterer tegnsekvenser som
ikke er lovlige UTF-8-kodninger.

Citat fra RFC2279:

>NOTE -- actual implementations of the decoding algorithm above
>should protect against decoding invalid sequences. For
>instance, a naive implementation may (wrongly) decode the
>invalid UTF-8 sequence C0 80 into the character U+0000, which
>may have security consequences and/or cause other problems. See
>the Security Considerations section below.

og:

>Implementors of UTF-8 need to consider the security aspects of how
>they handle illegal UTF-8 sequences. It is conceivable that in some
>circumstances an attacker would be able to exploit an incautious
>UTF-8 parser by sending it an octet sequence that is not permitted by
>the UTF-8 syntax.
>
>A particularly subtle form of this attack could be carried out
>against a parser which performs security-critical validity checks
>against the UTF-8 encoded form of its input, but interprets certain
>illegal octet sequences as characters. For example, a parser might
>prohibit the NUL character when encoded as the single-octet sequence
>00, but allow the illegal two-octet sequence C0 80 and interpret it
>as a NUL character. Another example might be a parser which
>prohibits the octet sequence 2F 2E 2E 2F ("/../"), yet permits the
>illegal octet sequence 2F C0 AE 2E 2F.

RFC2279 er fra januar 1998, så det burde efterhånden ikke komme som en
overraskelse for implementører at man skal passe på den slags.

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Den Mon, 19 Jul 2004 01:41:52 +0200 skrev Jesper Dybdal:
> Jesper Louis Andersen <jlouis@miracle.mongers.org> wrote:
>
>>Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:
>>
>>>> Mon ikke Microsoft har brugt denne femgangsm?de? Og alligevel havde
>>>> de overset at flere UTF-8 konstruktioner giver samme unicode-tegn,
>>>> og pludselig kunne man alligevel ..\..\.. ud af wwwroot.
>>>
>>> Jeg har altid syntes at UTF-8 var en forf?rdelig opfindelse.
>>
>>Det kan godt vaere, men den er hamrende noedvendig.
>
> Ja. Jeg synes UTF-8 er en fremragende opfindelse.

Er der nogen platforme hvor det ikke giver masser af problemer?

> Og i øvrigt foreskriver standarden faktisk at man *skal* bruge den
> kanoniske form for et tegns kodning i UTF-8 - dvs. der er kun én
> lovlig kodning af hvert Unicode-tegn.
>
> Problemet er dårlige implementationer der accepterer tegnsekvenser som
> ikke er lovlige UTF-8-kodninger.
>
> Citat fra RFC2279:
>
>>NOTE -- actual implementations of the decoding algorithm above
>>should protect against decoding invalid sequences. For
>>instance, a naive implementation may (wrongly) decode the
>>invalid UTF-8 sequence C0 80 into the character U+0000, which
>>may have security consequences and/or cause other problems. See
>>the Security Considerations section below.
>
> og:
>
>>Implementors of UTF-8 need to consider the security aspects of how
>>they handle illegal UTF-8 sequences. It is conceivable that in some
>>circumstances an attacker would be able to exploit an incautious
>>UTF-8 parser by sending it an octet sequence that is not permitted by
>>the UTF-8 syntax.
>>
>>A particularly subtle form of this attack could be carried out
>>against a parser which performs security-critical validity checks
>>against the UTF-8 encoded form of its input, but interprets certain
>>illegal octet sequences as characters. For example, a parser might
>>prohibit the NUL character when encoded as the single-octet sequence
>>00, but allow the illegal two-octet sequence C0 80 and interpret it
>>as a NUL character. Another example might be a parser which
>>prohibits the octet sequence 2F 2E 2E 2F ("/../"), yet permits the
>>illegal octet sequence 2F C0 AE 2E 2F.
>
> RFC2279 er fra januar 1998, så det burde efterhånden ikke komme som en
> overraskelse for implementører at man skal passe på den slags.

Den sender du lige til Microsoft...

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis <nospam@nospam.invalid> wrote:

>Den Mon, 19 Jul 2004 01:41:52 +0200 skrev Jesper Dybdal:
>> Jesper Louis Andersen <jlouis@miracle.mongers.org> wrote:
>>
>>>Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:
>>>
>>>>> Mon ikke Microsoft har brugt denne femgangsm?de? Og alligevel havde
>>>>> de overset at flere UTF-8 konstruktioner giver samme unicode-tegn,
>>>>> og pludselig kunne man alligevel ..\..\.. ud af wwwroot.
>>>>
>>>> Jeg har altid syntes at UTF-8 var en forf?rdelig opfindelse.
>>>
>>>Det kan godt vaere, men den er hamrende noedvendig.
>>
>> Ja. Jeg synes UTF-8 er en fremragende opfindelse.
>
>Er der nogen platforme hvor det ikke giver masser af problemer?

Jeg mener ikke UTF-8 giver problemer. Men elendige implementationer
af masser af ting, herunder UTF-8, giver problemer. Jeg ved ikke
hvilke platforme forkert UTF-8-dekodning har eller ikke har givet
problemer på - men det er altså ikke vildt svært at dekode UTF-8
korrekt, herunder at fange de tegnsekvenser som ikke er UTF-8.

Og UTF-8 er, som Jesper L A også skriver, nødvendig. UTF-8 er så vidt
jeg kan se det eneste realistiske bud på en repræsentation af et stort
tegnsæt som er velegnet til nogenlunde smertefrit at tage over på
steder hvor man traditionelt har brugt noget der for langt de fleste
tegns vedkommende er USASCII.

Det er fx ikke kun via illegale UTF-8-lignende tegnsekvenser man har
kunnet lave "/../"-nummeret - MS (og sikkert også andre) har svjh
præsteret at lave helt samme slags bug med de banale
"%xx"-konstruktioner i URL'er.

Problemet er ikke UTF-8 - problemet er programmører der ikke tænker i
sikkerhedsbaner, og heller ikke gider læse de vejledninger om
sikkerhedsaspekter man fx kan finde i RFC2279. Hvis man skal hindre
den slags programmører i at lave "/../"-bugs så skal man spærre deres
processer inde i et chroot-fængsel - men det kan man vist ikke i
Windows.

>> RFC2279 er fra januar 1998, så det burde efterhånden ikke komme som en
>> overraskelse for implementører at man skal passe på den slags.
>
>Den sender du lige til Microsoft...

MS har jo traditionelt, siden de tidlige DOS-versioner, prioriteret at
lave ting hurtigt fremfor korrekt. De kan kun lære sikkerhed ved at
miste markedsandele - og det er vist på vej til at ske nu, men har
naturligvis taget uhyggeligt lang tid.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Den Mon, 19 Jul 2004 12:41:51 +0200 skrev Jesper Dybdal:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>>Den Mon, 19 Jul 2004 01:41:52 +0200 skrev Jesper Dybdal:
>>> Jesper Louis Andersen <jlouis@miracle.mongers.org> wrote:
>>>
>>>>Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:
>>>>
>>>>>> Mon ikke Microsoft har brugt denne femgangsm?de? Og alligevel havde
>>>>>> de overset at flere UTF-8 konstruktioner giver samme unicode-tegn,
>>>>>> og pludselig kunne man alligevel ..\..\.. ud af wwwroot.
>>>>>
>>>>> Jeg har altid syntes at UTF-8 var en forf?rdelig opfindelse.
>>>>
>>>>Det kan godt vaere, men den er hamrende noedvendig.
>>>
>>> Ja. Jeg synes UTF-8 er en fremragende opfindelse.
>>
>>Er der nogen platforme hvor det ikke giver masser af problemer?
>
> Jeg mener ikke UTF-8 giver problemer. Men elendige implementationer
> af masser af ting, herunder UTF-8, giver problemer.

Så hvis bare man lader være med at implementere UTF-8, giver det ingen
problemer?

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis <nospam@nospam.invalid> wrote:
>
> S? hvis bare man lader v?re med at implementere UTF-8, giver det ingen
> problemer?
>

Ja og nej. Du slipper umiddelbart for de problemer der kan vaere med
implementationer af UTF-8, men du goer det ogsaa umuligt at sprede
dit programmel til resten af verden. UTF-8 er noedvvendigt fordi
der er flere end 127 skrifttegn og vi mangler en kanonisk maade at
beskrive dem paa. Styrken ved UTF-8 er netop en kodning der goer det
muligt at overgaa til dette nye format uden at det skaber for mange
problemer. Der er andre muligheder, men det er bestemt ikke muligheder
der er at foretraekke.

At skrive en rigtig UTF-8 parser er nok ikke saa svaert. Det er vaerre
at skrive en renderer, men det er jo bare ikke saa relevant sikkerheds-
maessigt. Selve parserstumpen er ogsaa relativt lille, saa det burde
ikke vaere svaert at lave et audit af den.

I specialiserede systemer kan man undlade UTF-8, men det viser sig
nok at det skal inkluderes i samtlige general-purpose operativsystemer
paa sigt.

--
j.

---

Kent Friis <nospam@nospam.invalid> wrote:

>> Jeg mener ikke UTF-8 giver problemer. Men elendige implementationer
>> af masser af ting, herunder UTF-8, giver problemer.
>
>Så hvis bare man lader være med at implementere UTF-8, giver det ingen
>problemer?

Jeg forstår ikke hvad du mener. Men det er da korrekt at hvis man
lader være med at skrive kode, så laver man ingen kodefejl.

Men man kan lave masser af problemer selv uden UTF-8.

Fx tror jeg der har været langt flere fejl som konsekvens af at man
begyndte at bruge 8-bits-tegnsæt end som konsekvens af UTF-8.

Utallige programmer er døde eller har opført sig forkert første gang
de mødte et tegn med den mest betydende bit sat. Utallige
programmører tror formodentlig stadig at man i C kan bruge
konstruktioner som isspace(c) hvor c er en "char"-variabel. Men den
dag man møder fx et ISO 8859-"å" vil den konstruktion i en typisk
(korrekt) C-implementation hvor en "char" kan være negativ, medføre at
man indekserer negativt i et array og får et tilfældigt resultat.

Det jeg forsøger at sige, er at når man udvider de mulige inddata (fx
fra USASCII til ISO 8859 eller fra ISO 8859 til en eller anden
Unicode-variant), så går ting galt medmindre man passer på.

Det mener jeg personligt ikke er en grund til at lade være med at
bruge Unicode eller ISO 8859: vi har faktisk brug for mere end
USASCII, og rigtig mange mennesker i verden har brug for mere end ISO
8859.

Og hvis du bare mener at lige netop UTF-8 er en særlig farlig
repræsentation af Unicode, så mangler du at fortælle hvilken
repræsentation du mener er bedre. Men husk at den helst også skal
have ganske mange af de gode egenskaber ved UTF-8 som er remset op i
fx RFC 2279, og som gør at det er praktisk ladsiggørligt at skifte fra
gammeldags 7/8-bits-tegnsæt til det. UCS-4 er fx en dejlig
repræsentation af Unicode - men det er altså ikke rigtig praktisk
muligt at begynde at bruge den i fx URL'er.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Den Mon, 19 Jul 2004 13:21:46 +0200 skrev Jesper Dybdal:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>>> Jeg mener ikke UTF-8 giver problemer. Men elendige implementationer
>>> af masser af ting, herunder UTF-8, giver problemer.
>>
>>Så hvis bare man lader være med at implementere UTF-8, giver det ingen
>>problemer?
>
> Jeg forstår ikke hvad du mener.

Jeg spurgte om platforme hvor UTF-8 ikke giver problemer, og svaret
var at UTF-8 giver ikke problemer, det er kun implementationen der
gør det.

Konklusionen må være at sålænge man bare lader være med at implementere
det så giver det ingen problemer.

Mvh
KEnt
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Jesper Dybdal wrote:
>
> Problemet er dårlige implementationer der accepterer tegnsekvenser som
> ikke er lovlige UTF-8-kodninger.

Jeg har tit problemer med programmer, der tror deres
input er UTF-8 og derfor afviser "ugyldige" sekvenser.
(Og programmer, der mener at tekstrengen "æøå" er 6
tegn lang.)

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:

>Jesper Dybdal wrote:
>>
>> Problemet er dårlige implementationer der accepterer tegnsekvenser som
>> ikke er lovlige UTF-8-kodninger.
>
>Jeg har tit problemer med programmer, der tror deres
>input er UTF-8 og derfor afviser "ugyldige" sekvenser.

Man kan naturligvis ikke forvente at programmer der er beregnet til at
få UTF-8 som input, kan håndtere andre formater. Og det er da fint at
programmet fortæller dig at du har leveret input i det gale format i
stedet for bare at gøre noget forkert ved det.

Det svarer helt til at man får problemer hvis man forventer at en
ASCII-teksteditor har det godt med at få et Word-dokument som input.

>(Og programmer, der mener at tekstrengen "æøå" er 6
>tegn lang.)

Og omvendt kan man heller ikke forvente at programmer der er beregnet
til at få et simpelt 8-bits-tegnsæt som input, kan håndtere andre
formater. (Det med de 6 tegn kan naturligvis også bare være en fejl.)

Jeg forstår ikke hvad det er du og Kent argumenterer for. Mener I at
vi skal stoppe verden ved ISO 8859, og så er det bare ærgerligt for de
milliarder af mennesker der bruger andre tegnsæt? (Og heldigt for os
at amerikanerne ikke på tilsvarende vis stoppede verden ved USASCII.)

Hvis det ikke er det I argumenterer for, så hører jeg meget gerne
jeres forslag til et praktisabelt alternativ til UTF-8.

Som jeg ser det, er det nødvendigt at komme videre til mere end
8-bits-tegnsæt. Og af hensyn til de mange eksisterende programmer som
temmelig nemt kan bringes til at være brugbare med fx UTF-8, men som
det ville være et enormt besvær at få til at bruge fx UCS-4, er vi
nødt til at have en repræsentation hvor tegnene ikke fylder lige mange
bytes. UTF-8 er svjv det klart bedste bud på sådan en repræsentation.

Undervejs vil der naturligvis være programmer der ikke virker
ordentligt. Og den tendens forstærkes af at UTF-8 ligner tidligere
tegnsæt så meget at mange eksisterende programmer vil virke halvvejs
eller vil blive ændret til at kunne UTF-8 på lidt halvhjertet facon.
Men det er stadig meget bedre end at insistere på at vi ikke kan komme
videre end 8-bits-tegnsæt før alle programmer på magisk vis på én gang
er lavet drastisk om til at håndtere et tegnsæt hvor alle tegn fylder
lige meget og mere end én byte.

Naturligvis er tegnsæt med varierende tegnlængde i mange sammenhænge
dødirriterende at skulle programmere til - men der er, i en lang
overgangsfase, ikke rigtig noget godt alternativ. Det vil naturligvis
være godt hvis programmører vil tænke sig lidt om - men det gælder
sådan set enhver form for programmeludvikling.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Den Mon, 19 Jul 2004 18:54:56 +0200 skrev Jesper Dybdal:
> Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:
>
>>Jesper Dybdal wrote:
>>>
>>> Problemet er dårlige implementationer der accepterer tegnsekvenser som
>>> ikke er lovlige UTF-8-kodninger.
>>
>>Jeg har tit problemer med programmer, der tror deres
>>input er UTF-8 og derfor afviser "ugyldige" sekvenser.
>
> Man kan naturligvis ikke forvente at programmer der er beregnet til at
> få UTF-8 som input, kan håndtere andre formater. Og det er da fint at
> programmet fortæller dig at du har leveret input i det gale format i
> stedet for bare at gøre noget forkert ved det.
>
> Det svarer helt til at man får problemer hvis man forventer at en
> ASCII-teksteditor har det godt med at få et Word-dokument som input.

Problemet forekommer ofte med programmer der forventer at *filnavne*
er UTF-8. Og resultatet er at man hurtigt er tilbage til at filnavne
kun må indeholde 7-bit tegn, selvom det var det stik modsatte der
var meningen.

>>(Og programmer, der mener at tekstrengen "æøå" er 6
>>tegn lang.)
>
> Og omvendt kan man heller ikke forvente at programmer der er beregnet
> til at få et simpelt 8-bits-tegnsæt som input, kan håndtere andre
> formater. (Det med de 6 tegn kan naturligvis også bare være en fejl.)
>
> Jeg forstår ikke hvad det er du og Kent argumenterer for. Mener I at
> vi skal stoppe verden ved ISO 8859, og så er det bare ærgerligt for de
> milliarder af mennesker der bruger andre tegnsæt? (Og heldigt for os
> at amerikanerne ikke på tilsvarende vis stoppede verden ved USASCII.)
>
> Hvis det ikke er det I argumenterer for, så hører jeg meget gerne
> jeres forslag til et praktisabelt alternativ til UTF-8.

Mit forslag: Lad dem som mener UTF-8 er så skide smart om at fixe
de problemer det giver, inden vi andre bliver prakket det på.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kent Friis <nospam@nospam.invalid> wrote:

>Mit forslag: Lad dem som mener UTF-8 er så skide smart om at fixe
>de problemer det giver, inden vi andre bliver prakket det på.

Nu er jo altså sådan at man ikke kan indføre UTF-8 enkelte steder i
verden, og lade resten i fred indtil man ser det virke. WWW er
verdensomspændende, og hvis vi vil acceptere at der findes andre
tegnsæt end de vesteuropæiske som bør kunne anvendes i WWW (og det vil
jeg), så må vi finde os i en løsning.

Og som sagt: UTF-8 giver i sig selv ikke mange problemer - men
inkompetent implementering af UTF-8, lige så vel som inkompetent
implementering af alt mulig andet, gør.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Den Tue, 20 Jul 2004 23:55:42 +0200 skrev Jesper Dybdal:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>>Mit forslag: Lad dem som mener UTF-8 er så skide smart om at fixe
>>de problemer det giver, inden vi andre bliver prakket det på.
>
> Nu er jo altså sådan at man ikke kan indføre UTF-8 enkelte steder i
> verden, og lade resten i fred indtil man ser det virke. WWW er
> verdensomspændende, og hvis vi vil acceptere at der findes andre
> tegnsæt end de vesteuropæiske som bør kunne anvendes i WWW (og det vil
> jeg), så må vi finde os i en løsning.

Og hvad er der i vejen for at lade serveren fortælle browseren hvilket
tegnsæt det drejer sig om? Det gør den faktisk i forvejen, og det virker
fint.

Det er først når samme side skal til at indeholde både russisk og
kinesisk at man får brug for UTF-8. Og så er næste problem at sørge
for at brugeren også kan læse både russisk og kinesisk. For hvis han
kun kan læse en af delene, så er der heller ikke brug for at vise
begge dele.

> Og som sagt: UTF-8 giver i sig selv ikke mange problemer - men
> inkompetent implementering af UTF-8, lige så vel som inkompetent
> implementering af alt mulig andet, gør.

Og så er vi tilbage ved at hvis bare det aldrig blev implementeret,
ville det virke perfekt.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

In <40fe2b99$0$66478$14726298@news.sunsite.dk> Kent Friis <nospam@nospam.invalid> writes:

>Den Tue, 20 Jul 2004 23:55:42 +0200 skrev Jesper Dybdal:
>> Kent Friis <nospam@nospam.invalid> wrote:
>>
>>>Mit forslag: Lad dem som mener UTF-8 er så skide smart om at fixe
>>>de problemer det giver, inden vi andre bliver prakket det på.
>>
>> Nu er jo altså sådan at man ikke kan indføre UTF-8 enkelte steder i
>> verden, og lade resten i fred indtil man ser det virke. WWW er
>> verdensomspændende, og hvis vi vil acceptere at der findes andre
>> tegnsæt end de vesteuropæiske som bør kunne anvendes i WWW (og det vil
>> jeg), så må vi finde os i en løsning.

>Og hvad er der i vejen for at lade serveren fortælle browseren hvilket
>tegnsæt det drejer sig om? Det gør den faktisk i forvejen, og det virker
>fint.

>Det er først når samme side skal til at indeholde både russisk og
>kinesisk at man får brug for UTF-8. Og så er næste problem at sørge
>for at brugeren også kan læse både russisk og kinesisk. For hvis han
>kun kan læse en af delene, så er der heller ikke brug for at vise
>begge dele.

>> Og som sagt: UTF-8 giver i sig selv ikke mange problemer - men
>> inkompetent implementering af UTF-8, lige så vel som inkompetent
>> implementering af alt mulig andet, gør.

>Og så er vi tilbage ved at hvis bare det aldrig blev implementeret,
>ville det virke perfekt.

>Mvh
>Kent
>--
>Help test this great MMORPG game - http://www.eternal-lands.com/

Hvad er det egentlig vi diskuterer ? Det er jo indlysende klart
at det for de fleste nationale formål er ok at nøjes med en
national løsning. Dvs russerne har et (eller rettere mange, mange)
tegnsætskodninger, der klarer det kyrilliske alfabet, kineserne har
et til kinesisk, japanerne osv. Problemerne opstår når vi ønsker
at mikse det. Du behøver ikke gå så langt for at finde dem. Fx
et bibliotekssystem, hvor du gerne vil kunne vise en oversat bogs
originaltitel eller en udenlandsk bogs titel korrekt.
I den slags sammenhænge er det noget jammer at skulle skifte tegnsæt
hele tiden. Unicode er det hidtil bedste bud jeg har set på en
løsning. Dårlige løsninger har jeg set nok af. UTF-8 er vel bare
et kompromis, der sikrer at usa og nordeuropa kan blive vel at skrive
i ascii uden at deres filer pludseligt skal fylde det dobbelte

mvh Birger Nielsen (bnielsen@daimi.au.dk)

---

Den Thu, 22 Jul 2004 07:50:16 +0000 (UTC) skrev Kai Birger Nielsen:
>
> Hvad er det egentlig vi diskuterer ? Det er jo indlysende klart
> at det for de fleste nationale formål er ok at nøjes med en
> national løsning. Dvs russerne har et (eller rettere mange, mange)
> tegnsætskodninger, der klarer det kyrilliske alfabet, kineserne har
> et til kinesisk, japanerne osv. Problemerne opstår når vi ønsker
> at mikse det. Du behøver ikke gå så langt for at finde dem. Fx
> et bibliotekssystem, hvor du gerne vil kunne vise en oversat bogs
> originaltitel eller en udenlandsk bogs titel korrekt.

Hvis det var den slags det blev brugt det, ville jeg ikke have noget
problem med det. Men når det bliver brugt til at genere os andre, fordi
en gruppe UTF-8-fanatikere med vold og magt vil have det indført
overalt, på trods at dets åbenlyse fejl og mangler, så er jeg altså
kraftig modstander af det.

> I den slags sammenhænge er det noget jammer at skulle skifte tegnsæt
> hele tiden. Unicode er det hidtil bedste bud jeg har set på en
> løsning. Dårlige løsninger har jeg set nok af. UTF-8 er vel bare
> et kompromis, der sikrer at usa og nordeuropa kan blive vel at skrive
> i ascii uden at deres filer pludseligt skal fylde det dobbelte

Hele verden kan såmænd blive ved med at skrive i ascii (US-ascii) uden
at deres filer pludselig fylder det dobbelte. Men nordeuropa kan ikke
bruge vores nationale tegn i UTF-8 uden at de både kommer til at fylde
en hel del mere, og at alt skal konverteres. Det er kun amerikanerne
(og enlænderne har vist heller ikke nogen udover ascii) der slipper
for problemerne.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Kai Birger Nielsen wrote:
>
> UTF-8 er vel bare
> et kompromis, der sikrer at usa og nordeuropa kan blive vel at skrive
> i ascii uden at deres filer pludseligt skal fylde det dobbelte

Er det reelt et problem hvis vores tekstfiler kommer
til at fylde det dobbelte? Hvor stor en del af den
diskplads vi bruger i dag er rent faktisk til tekst?

Og skulle der være tilfælde hvor det har betydning,
så kan vi komprimere vores filer. Hvis du tager den
samme tekst i en 8-bits pr. tegn indkodning og en
32-bits pr. tegn indkodning og komprimerer med en
god komprimeringsalgoritme, så burde resultaterne
fylde ca. lige mange bits.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Jesper Dybdal wrote:
>
> Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:
>
> >
> >Jeg har tit problemer med programmer, der tror deres
> >input er UTF-8 og derfor afviser "ugyldige" sekvenser.
>
> Man kan naturligvis ikke forvente at programmer der er beregnet til at
> få UTF-8 som input, kan håndtere andre formater. Og det er da fint at
> programmet fortæller dig at du har leveret input i det gale format i
> stedet for bare at gøre noget forkert ved det.

Jeg snakker ikke om programmer der er beregnet til at få
UTF-8 som input. Jeg snakker om programmer, der er beregnet
til at få en vilkårlig teksfil eller binær fil som input.

>
> Hvis det ikke er det I argumenterer for, så hører jeg meget gerne
> jeres forslag til et praktisabelt alternativ til UTF-8.

Jeg mener det mål man burde sigte efter er et system, hvor
en char er 16 eller 32 bits. Jeg synes ikke UTF-8 ser ud som
et skridt i den retning. Jeg mener man bør helt gøre op med
den 8-bits enhed vi har været vant til. Det vil give lidt
kompatibilitets udfordringer på vejen, men jeg mener ikke
det bør være væsentligt sværere end at skifte mellem to
arkitekturer med forskellig endianess.

Man behøver ikke udskifte sin hardware for at bruge en anden
char størrelse. Man kan lave sin compiler og OS kode, så en
char/byte ikke mere er 8 bits, men noget større. Hvis det
slår igennem kan man så på længere sigt fjerne muligheden
for at addressere 8 bits enheder fra fremtidige arkitekturer.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

On 2004-07-19, Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:

> Man behøver ikke udskifte sin hardware for at bruge en anden
> char størrelse. Man kan lave sin compiler og OS kode, så en
> char/byte ikke mere er 8 bits, men noget større. Hvis det
> slår igennem kan man så på længere sigt fjerne muligheden
> for at addressere 8 bits enheder fra fremtidige arkitekturer.

Ville det ikke - blandt andet - give kolossale logistiske problemer?
Alle datastørrelser måles jo i bytes eller multipla deraf. Da enhedens
eneste eksistensgrundlag er, at verdens CPU-arkitekturer kan adressere
den, må det næste logiske skridt så være at gå over til at måle i "de
nye chars," til stor forvirring for ikke-nærder (og sikkert også nogle
nørder; det er jo ikke alle, der ved hvad et maskinord er for en
størrelse). Så kunne man lave en Microsoft og helt afskaffe
måleenheden - Fru Jensen ville så i fremtiden skulle købe en harddisk
2010 eller et RAM-modul 2015. Det tror jeg heller ikke du synes er en
god ide.

Lars

---

Lars Skovlund wrote:
>
> Ville det ikke - blandt andet - give kolossale logistiske problemer?
> Alle datastørrelser måles jo i bytes eller multipla deraf.

Bortset fra kommunikationshastigheder, der for det
meste måles i bits i stedet for bytes. Det kunne man
da også gøre med RAM og HD. Og producenterne ville
ikke have noget imod det, da deres medier kom til at
lyde otte gange større. Du vil til gengæld ikke se
nogen producenter begynder at måle størrelsen i nye
bytes på 16 eller 32 bits, da det ville betyde at de
skulle opgive et tal der var 2 eller 4 gange mindre.

> Da enhedens
> eneste eksistensgrundlag er, at verdens CPU-arkitekturer kan adressere
> den,

Faktisk er der jo kun internt at CPUen arbejder med
bytes. På busen har alle CPUer siden 286eren arbejdet
med større enheder. Der findes nok stadig nogle
embedede arkitekturer, der kører med 8 bits på busen.

> må det næste logiske skridt så være at gå over til at måle i "de
> nye chars," til stor forvirring for ikke-nærder (og sikkert også nogle
> nørder; det er jo ikke alle, der ved hvad et maskinord er for en
> størrelse). Så kunne man lave en Microsoft og helt afskaffe
> måleenheden - Fru Jensen ville så i fremtiden skulle købe en harddisk
> 2010 eller et RAM-modul 2015. Det tror jeg heller ikke du synes er en
> god ide.

Jeg mener måleenheden er det mindste problem. Vi
måler allerede størelser i bits, bytes, Kb, KB, osv.
Og der er fire forskellige muligheder for hvad man
kaldet for en GB. Og på trods af det er det ikke
gået helt galt.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:

>Jeg snakker ikke om programmer der er beregnet til at få
>UTF-8 som input. Jeg snakker om programmer, der er beregnet
>til at få en vilkårlig teksfil eller binær fil som input.

Øh? Hvorfor brokker sådan et program sig så over at dets input ikke
er UTF-8? Er det ikke bare et sygt program vi snakker om?

>Jeg mener det mål man burde sigte efter er et system, hvor
>en char er 16 eller 32 bits.

Her er vi helt enige. Det er målet. Men jeg tror ikke man i praksis
kan springe direkte til det.

>Jeg synes ikke UTF-8 ser ud som
>et skridt i den retning. Jeg mener man bør helt gøre op med
>den 8-bits enhed vi har været vant til. Det vil give lidt
>kompatibilitets udfordringer på vejen, men jeg mener ikke
>det bør være væsentligt sværere end at skifte mellem to
>arkitekturer med forskellig endianess.

Jeg tror det er *meget* sværere. Vi har ganske mange
kommunikationsprotokoller der er baseret på 8-bits bytes. Vi har en
masse programmer som håndterer sekvenser af 8-bit-tegn, og som
rimeligt nemt kan ændres til at acceptere at der sommetider går mere
end én 8-bit byte på et synligt tegn. Men at skifte til 32-bit tegn
generelt er en meget stor ændring: det ændrer repræsentationen af ca.
alle binære datafiler.

>Man behøver ikke udskifte sin hardware for at bruge en anden
>char størrelse. Man kan lave sin compiler og OS kode, så en
>char/byte ikke mere er 8 bits, men noget større.

Det er en grundlæggende ulempe ved C-standarden (og også alle
tidligere C-varianter) at de går ud fra at den mindste adresserbare
enhed er den der svarer til et synligt tegn. Det er jo nemt nok (og
ikke i modstring med standarden) at lave en C-oversætter med en 32-bit
char, men der bliver problemer med fx kommunikationsprotokoller som
regner i 8-bit bytes og med adgang til hardware.

Jeg tror man får brug for programmeringssprog der skelner mellem bytes
(den mindste adresserbare enhed) og tegn. C har det næsten allerede:
"char" er en byte, wchar_t er et tegn. Men wchar_t er en noget
kluntet løsning.

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Jesper Dybdal wrote:
>
> Det er en grundlæggende ulempe ved C-standarden (og også alle
> tidligere C-varianter) at de går ud fra at den mindste adresserbare
> enhed er den der svarer til et synligt tegn.

Det kan der være noget om. Men det er jo ikke kun
i sproget, men også i måden flere programmer virker
på, at den antagelse ligger. Men det kan da godt
være, at man burde prøve at komme væk fra den
antagelse.

> Det er jo nemt nok (og
> ikke i modstring med standarden) at lave en C-oversætter med en 32-bit
> char,

Enig.

> men der bliver problemer med fx kommunikationsprotokoller som
> regner i 8-bit bytes

Så må der ligge noget konvertering i implementationen
af kommunikationsprotokollen. Den nødvendige
konvertering burde kunne gøres simplere end hvad
der skal til at generere og parse UTF-8.

> og med adgang til hardware.

Jeg kan ikke se problemet. Der findes allerede
hardware, hvor man skal manipulere data, der er
mindre end en byte.

>
> Jeg tror man får brug for programmeringssprog der skelner mellem bytes
> (den mindste adresserbare enhed) og tegn. C har det næsten allerede:
> "char" er en byte, wchar_t er et tegn. Men wchar_t er en noget
> kluntet løsning.

Jeg kender ikke til detaljerne, men bare navnet på
den type er slemt nok i sig selv. Hvorfor kunne de
ikke bare have kaldt den wchar? Eller have indført
en type kaldet byte og et krav om
sizeof(byte)<=sizeof(char)

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.

---

Den Tue, 20 Jul 2004 23:55:36 +0200 skrev Jesper Dybdal:
> Kasper Dupont <remove.invalid@nospam.lir.dk.invalid> wrote:
>
>>Jeg synes ikke UTF-8 ser ud som
>>et skridt i den retning. Jeg mener man bør helt gøre op med
>>den 8-bits enhed vi har været vant til. Det vil give lidt
>>kompatibilitets udfordringer på vejen, men jeg mener ikke
>>det bør være væsentligt sværere end at skifte mellem to
>>arkitekturer med forskellig endianess.
>
> Jeg tror det er *meget* sværere. Vi har ganske mange
> kommunikationsprotokoller der er baseret på 8-bits bytes. Vi har en
> masse programmer som håndterer sekvenser af 8-bit-tegn, og som
> rimeligt nemt kan ændres til at acceptere at der sommetider går mere
> end én 8-bit byte på et synligt tegn. Men at skifte til 32-bit tegn
> generelt er en meget stor ændring: det ændrer repræsentationen af ca.
> alle binære datafiler.

Er problemet ikke blot at C ikke har nogen datatype "byte", men bruger
unsigned char?

Hvis det blev ændret, og programmer brugte char, når de mente et tegn,
og byte når de mente 8 bits, tror jeg skiftet af char-størrelse ville
gå nemt. I VB.NET er en char mig bekendt større end 8-bit, men jeg er
ikke klar over den præcise størrelse, fordi det er uinteressant. Det
skal compileren og frameworket nok bekymre sig om.

Hvor mange programmer bekymrer sig reelt om størrelsen på et tegn
(og ikke byte), hvis man forestiller sig at char havde den rigtige
størrelse?

UTF-8 derimod giver problemer hver gang man skal bruge længden af en
streng. Hver eneste gang skal utf-8 dekodes eller enkodes, og glemmer
man det bare en enkelt gang, har man en buffer-overflow, "../"-
problemer eller lignende.

IMHO giver UTF-8 flere problemer.

Problemet med programmer der tror alt er UTF-8 ville heller ikke
eksistere hvis vi havde en 16- eller 32-bit char, og en 8-bit byte,
på et system med 8-bit char ville compileren bare generere
instruktioner til at tilgå en byte, og på et system med større chars
ville den generere instruktioner til at tilgå en unsigned int. Ok,
det kræver at programmerne recompiles, men i forhold til hvad
../configure ellers checker for, er det småting.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

Martin Schultz wrote:
>
> En mulighed jeg har overvejet er at gennemgå tekst strengen og
> sikre at den kun indeholder a-zA-Z, 0-9 og .

Jeg mener det er den rigtige fremgangsmåde. Du bør dog
lige tage et kig på den relevante RFC for at se præcis
hvilke tegn, der er gyldige i et domænenavn. Du kan i
hvert fald bruge bogstaver, cifre og bindestreg. Der
er også nogle begrænsninger på hvor bindestreg må
bruges, det vigtigste er nok at du ikke tillader det
første tegn at være en bindestreg.

> Vil det være nok
> til at forhindre unoder eller hvordan bør jeg gribe det an?

Du skal også checke længden af strengen. Desuden skal
du overveje, om du vil tillade ping af et vilkårligt
hostnavn eller IP adresse. Ellers kan jeg ikke komme i
tanke om flere muligheder, men det er der sikkert andre,
der kan.

>
> Jeg er lidt i tvivl om spørgsmålet høre hjemme her eller i
> dk.edb.programmering men her kommer det.

Da hovedparten af de sikkerhedshuller jeg ser på websites
skyldes at man har glemt disse overvejelser, så synes jeg
bestemt det er on topic i den her gruppe.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
I'd rather be a hammer than a nail.