- NevemTeve blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Nopéldául:
http://openssl.6102.n7.nabble.com/openssl-dev-64-bit-compilacion-seems-…
vagyis egy perl-script írja meg az Assembly source-t:
crypto/modes/asm/ghash-x86_64.pl (ez Power-processzornál is így van), tehát a scriptet meg a Perl-t kell gyanusítani.
Nagy biztonsággal ez az érintett rész:
659 sub \$0x30,$len
660 mov \$0xA040608020C0E000,%rax # ((7..0)ˇ0xE0)&0xff
661 movdqu 0x30($Htbl),$Hkey3
662 movdqu 0x40($Htbl),$Hkey4
- A hozzászóláshoz be kell jelentkezni
64 bites környezetben nem kell a bigint, 32 biten meg igen. Ha a környezet, ahol a fordítást csinálod 64 bites, akkor joggal tételezi fel a cucc, hogy az eszközök, amit használsz (a Perl is) 64 bites. Szerintem... Sőt, külön van Perl script 32 meg 64 bites környezetre...
- A hozzászóláshoz be kell jelentkezni
Így lehet tesztelni:
$ perl -e 'print(11547335547999543296)'
1.15473355479995e+19 # na ez a rossz
$ perl -e 'use bigint; print(11547335547999543296)'
11547335547999543296 # ez meg a jó
- A hozzászóláshoz be kell jelentkezni
Azt is elmagyarázod, hogy a "na ez rossz" helyett ugyanazzal a kóddal mit kellene látni? Vagy nem értem. Azaz nem a perl a hibás, hanem a perl scriptben használnak valamit rosszul (és az első forma helyett a másodikat kellene)?
- A hozzászóláshoz be kell jelentkezni
A lényeg ugye, hogy vannak a szép nagy számok, és azokat kétféleképpen lehet kiírni: tudományos jelöléssel (pl. 1.2E13, azaz 1.2*10^13) vagy kiírod végig pontosan.
Nos, mivel a generáló Perl script szar, ezért az tudományos jelölést használ ahelyett, hogy kiírná pontosan. Ez a baj, mivel az assembler ezt nem tudja parzolni.
Nézz utána: https://en.wikipedia.org/wiki/Scientific_notation#E_notation
- A hozzászóláshoz be kell jelentkezni
Precízebben mondva, szabadon választhatunk a 'use bignum;' és a 64-bites perl telepítése között. Az egyszerűség kedvéért most az előbbit választottam (egy-egy sor kommentet feláldozva):
sed_repl 's|# March, June 2010|use bigint;|' crypto/modes/asm/ghash-x86_64.pl
sed_repl 's|# Dual-ABI styling rules.|use bigint;|' crypto/perlasm/x86_64-xlate.pl
- A hozzászóláshoz be kell jelentkezni
Még precízebben szólva: te a megoldás két módját írod le, nem a problémát. Én meg a problémát írtam le.
- A hozzászóláshoz be kell jelentkezni
A probléma oka az, hogy a fejlesztő hallgatólagosan feltette, hogy a felhasználónak, ha már 64-bites SSL-t akar fordítani, akkor nyilván 64-bites Perlje is van, ami 'use bigint;' nélkül is elboldogul 64-bites számokkal.
- A hozzászóláshoz be kell jelentkezni
Csak erdekesseg miatt kerdeznem, hogy miert forgatsz openssl-t forrasbol?
- A hozzászóláshoz be kell jelentkezni
Nem is tudom, van-e még Debian package 6.0.5-höz...
- A hozzászóláshoz be kell jelentkezni
6.0.5? A 6.0.10 mar egy eves, de nem tul lenyeges, mert a debian mar nem tamogatja a squeeze-t. Mivel nem volt benne openssl 1.0.x, hanem csak 0.9.8 igy a hozza valo cuccok alapbol nem mennek az uj openssl verziokkal. Persze mindenki ugy szivatja magat, ahogy akarja...
- A hozzászóláshoz be kell jelentkezni
Azért szerencsére a világmindenség nem semmisül meg, ha nekem van a /usr/lib/libssl.0.9.8 mellett egy /usr/local/lib/libssl.1.0.2 fájlom is...
Jó dolgok vannak Unix-ban;)
- A hozzászóláshoz be kell jelentkezni
Arra celoztam, hogy mivel a squeeze mar nem tamogatott, igy inkabb frissiteni celszeru legalabb wheezy-re, mint pl. openssl-t hackolni ra, es melletenni alkalmazasokat. Mondjuk az AIX 5.3 melle jo parositas a debian 6 :)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
"Mondjuk az AIX 5.3 melle jo parositas a debian 6"
Ez szarkazmus volt. ;)
- A hozzászóláshoz be kell jelentkezni
mar frissitett 5.3-ra, ez is nagy szo! biztos nem fordult a forditoja :((( vagy az mceditje.
- A hozzászóláshoz be kell jelentkezni
"GNU assembler (GNU Binutils for Debian) 2.20.1-system.20100303"
- (mindegy, latom hogy mas a para)
- A hozzászóláshoz be kell jelentkezni