NevemTeve blogja

Ez itt túl nehéz feladat a 'mcview'-nek, belefagy:

mcview /usr/java5/include/jni.h

Szerk: aljas rágalom, a 'file' utility döglött meg (akit a mcview hívott meg). Innen már kezd halványan ismerős lenni a történet, mindjárt visszakeresgélek...

Szerk: ez volt az előzmény: https://hup.hu/node/155854, ott a file-5.29 volt a gond, most a file-5.32, hátha azóta van újabb.

Szerk: Innen próbálkozom az 5.34-gyel: ftp://ftp.astron.com/pub/file/

Szerk: Hát ezzel is.

Előzmény itt: libcrypto.so.1.0.2: no version information available
Akkor abban maradtam, hogy jó, Debianék biztos valamilyen jócselekedtképpen másképp linkelik az OpenSSL-t, mint a gyártó, ezért az én házilag fordított OpenSSL-em nem jó a Debian-os binárisoknak.

Nomost itt az 1.1.1, amire ismerős üzenetet kapok:

Ha semmi más nem, de a pip aztán végképp arra való, hogy megkönnyítse az életemet. Rögtön itt az első megkönnyítés:

Akarom mondani, amikor 2017. júliusában a gcc-4.9.4-et forrásból telepítettem, akkor Bobó úgy látta, hogy a /usr/include/openssl/bn.h nem jól kvarálodik a zengével, ezért neki javított változatot kell létrehoznia, és elhelyezni a könnyen megtalálható /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include-fixed/openssl könyvártban.

Az már semmiképpen sem az ő hibája, hogy azóta a világ haladt, az OpenSSL-1.1.1 is elérkezett, és az ő áldásosan megjobbított, de egyébként elavult fájlja miatt nem fordult a tomcat-native-1.2.17...

Kértem én ezt, vagy csak úgy feltelepítődött?

.config/autostart/zeitgeist-datahub.desktop

Egyelőre nincs béke, valameddig eljut a PHP fordítása, aztán azt mondja, hogy:

[17-Sep-2018 10:16:52 UTC] PHP Fatal error:  Unable to start pcre module in Unknown on line 0

Legalábbis olyan értelemben nem, hogy 'jobb két libz, mint egy'. Ezt most linuxon tudtam előadni, valószínűleg az openssl segítő jószándéka, a 'zlib-dynamic' van mögötte:

OpenSSL-1.1.1 megérkezett! Persze egyből jó is, ugye?
Madjnem.
A certificate-request-generálásnál megáll, ha a 'STate' vagy az 'OrganizationUnit' üres:

1:error:0D07A098:asn1 encoding routines:ASN1_mbstring_ncopy:string too short:crypto/asn1/a_mbstr.c:100:minsize=1

https://github.com/openssl/openssl/issues/7215

Szerk: Azt a jótanácsot kaptam, hogy teljesen hagyjam ki a "subject"-ből az üres részeket (SUBJ=/C=HU/.../ST=/.../OU=/...), akkor jó lesz. Kipróbáltam, jó lett.

2018.10.29. 06:40 Kiszivárgott, hogy az 1.1.1 sorozatban is a végére tett betűk fogják jelenteni a patchverziót. Ennek alapján, ha mondjuk lesz egy 1.1.1a, akkor abból AIX-on lehet egy ilyesmi láncolat:

libssl.so.1.1.1.a -- maga a shared lib; major=1.1, minor=1.a
libssl.so.1.1     -- szimlink az előzőre, csak major, a használó programok erre dependálnak
libssl.so         -- szimlink az előzőre/elsőre, nem használjuk semmire
libssl.la         -- programok szerkesztésekor (linkage) használjuk, ebből tudjuk meg az aktuális libraryt (a libssl.so.1.1)

Ki lehet a hibás, ha ilyen üzenet van a mod_jk.log fájlban:

[Thu Sep 06 10:40:14.221 2018] [942126:1] 
[emerg] jk_servlet_normalize::jk_util.c (2188): [*] does not start with '/'.

httpd: Apache/2.4.34
mod_jk: tomcat-connectors-1.2.44

Ugyebár beérkezik a klienstől, hogy "OPTIONS *", erre a httpd konzultál a mod_jk-val, hogy az óhajt-e valamit kezdeni vele, a mod_jk meg elsősorban arra panaszol, hogy mit csináljon ő egy csillaggal, amikor eddig abban hitben élt, hogy ottan egy path-név jön, /perjellel kezdve.

Szerk: Mondjuk egy 'AllowMethods GET POST' valószínűleg segítene rajta...

http://php.net/archive/2018.php#id2018-08-02-1
https://downloads.php.net/~cmb/php-7.3.0beta1.tar.xz

Ami nem változott alfa4 óta:
https://bugs.php.net/bug.php?id=73002

Ami változott:
bővítményeket (pl imagick) újra kell fordítani:

Na, működik elsőre?

Azért szégyen, hogy megfosztom a szegény mod_lbmethod_byrequests.so-t a betevő ap_proxy_balancer_get_best_worker-től. Ez valószínűleg a httpd-2.4.34 újdonsága, mert eddig nem volt ilyen panasz.

20180719.1117: Annyit már látok, hogy a mod_proxy.so exportálja ezt a szimbóleumot.

subversion-1.10.0 fordítása során merült fel némi gond, ami végül ahhoz a kérdéshez vezetett el, hogy mit kellene csináljon ez a shell-utasítás:

echo "`Unused_variable=" $random_variable"`"

Ebben ott vélem a gondot látni, hogy a "macskakörmön" belül van a `backtick`, és azon belül van az újabb "macskaköröm". Mindenesetre nincs gond, ha ha `backtick` helyett $(cmd) van, vagy ha a belső macskakörmön belül nincs szóköz. Vagy ha a bash/dash/zsh shellt használunk.

Köszönöm a Teremtőnek, hogy olyan könnyű munkát osztott rám, mint az ékezetes betűkkel való kínlódás... Mindig van új varázslat, valahogy sosem ér véget a dolog. Most éppen egy ilyen shell-scriptem van:

Ugye ez nem száz százalékban jó:

$ date -d "1941-04-07 23:59:59" +%s  -906771601
$ date -d "1941-04-08 00:00:00" +%s  date: invalid date '1941-04-08 00:00:00'
$ date -d "1941-04-08 00:59:59" +%s  date: invalid date '1941-04-08 00:59:59'
$ date -d "1941-04-08 01:00:00" +%s  -906771600

Vagyis a derék szoftver szerint a tavaszi előrecsavarás miatt 23:59:59 után másnap 01:00:00 következett. Namostan ha nekem egy 'csak dátum' mezőm van, akkor azt általában 00:00:00 időponttal szoktuk teljes dátum+idővé alakítani, ami a (legalábbis ezen a gépemen) "nem létezett". Speciel a wiki nem ezt írja, de persze az sem jogforrás...

Ugyebár a mi Bobókánk mindenre képes, hogy segítsen nekünk, például kitalálta, hogy a compiler "kioptimalizálhatja" a memset-et. Namostan Bobó persze nem gondolhat mindenre (vagy bármire a saját kis perspektíváján kívül), tehát filmszínházunk bemutatja: explicit_memset

PHP-7.3 implementációja:

PHPAPI void php_explicit_bzero(void *dst, size_t siz)
{
...
#elif defined(__GNUC__)
        memset(dst, 0, siz);
        asm __volatile__("" :: "r"(dst) : "memory");
...
}

Ezt persze nem értem, de bizonyára jó, csak csavarnom kell egyet a gcc opcióin, pl s/-std=c99/-std=gnu99/g

Egyelőre annyi, hogy egy tesztfájllal megbuktatni véltem az ősrégi AIX!tar-t a gépeinken.
További adat felmerüléséig pár link:
https://github.com/snyk/zip-slip-vulnerability
https://snyk.io/research/zip-slip-vulnerability
https://res.cloudinary.com/snyk/image/upload/v1528192501/zip-slip-vulne…
https://it.slashdot.org/story/18/06/05/2046213/zip-slip-vulnerability-a…

Egyesek szerint ez nem is újdonság:

https://news.ycombinator.com/item?id=17237295
https://nvd.nist.gov/vuln/detail/CVE-2001-1268
https://labs.neohapsis.com/2009/04/21/directory-traversal-in-archives/

'Account' használata mc-ben FTP-nél. Kiváncsi vagyok, ottan van-e még.
https://mail.gnome.org/archives/mc-devel/2003-March/msg00073.html

2018-04-18 14:03
Na jó, ez könnyű volt:

export AR="/usr/bin/ar -X32_64"

A rossz hír, hogy ezután sem tud EBCDIC-et (pl IBM037, IBM1047). Közben meg a linuxomon olyan iconv van, ami tud. Tehát az egy másik gyártó iconv-ja:

iconv --version
iconv (Debian GLIBC 2.19-18+deb8u10) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.

ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00…
ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP01…

2018-04-18 13:34
Na, mit találtam ki mára?

checking for ar... ar
checking the archiver (ar) interface... unknown
configure: error: could not determine ar interface

Na, most túljárt az eszemen a szoftver: egyszerűen nem találok benne olyan opciót, hogy egyszerre csináljon két dolgot:

1. a TAB billentyűre menjen a következő 4k+1. pozícióra (értelmeszerűen szóközök beszúrásával; ha akarja, optimalizálja a szóközöket TAB karakterekkel, de a következő pont figyelmbevételével)

2. a TAB karakter hatására menjen a következő 8k+1. pozícióra

A korszerűtlen grafikátlan mcedit-ben ez az "Options / General / Tabulation / Fake half tabs" nevű feature.

Botor fejjel belenéztem a php-2.7.4 'configure' futásának outputjába, ha azt írja nagy szomorúan, hogy nincs nekem 'curl_version_info'-m. De szerintem van, vagy a spájzban a befőttek között, vagy pedig a /usr/local/lib64/libcurl.so-ban.

De persze a 'configure' szuterén jogának tartja, hogy a CFLAGS/LDFLAGS-ot figyelembe vegye-e, vagy sem. Pont ebben az esetben nem vette figyelembe (bár a CPPFLAGS-ot igen), ezért megtalált valahol valami jó régi 32-bites libcurl.a-t, a default '-maix32' opciónak megfelelően.

Akkor most mi legyen? Tegyem bele a CPPFLAGS-ba is a '-maix64 -Wl,-brtl' opciókat? Az se rossz...

Eddig szokott fordulni a httpd, dehát semmi sem tart örökké... Kellett neki újabb libcurl, azt tettem neki, de annak nincs köze ehhez a hibához

libtool: compile: gcc ... mod_proxy.c -o .libs/mod_proxy.o
mod_proxy.c:2675:1: error: unknown type name 'apr_OFN_ssl_engine_set_t'

mod_proxy.c:2675:1: error: unknown type name 'apr_OFN_ssl_engine_set_t'
 static APR_OPTIONAL_FN_TYPE(ssl_engine_set) *proxy_ssl_engine = NULL;
 ^
mod_proxy.c: In function 'ap_proxy_ssl_engine':

És igaza van: a cpp -dD nevű varázseszközzel megnézve sincs ilyen 'apr_OFN_ssl_engine_set_t' definiálva.

Azt mondja a gdb-8.0.1, hogy 'nem jó' a python a gépen (2.7.11 egyébként). Megnézem a config.log-ot, ottan látható a parancs, amivel próbálkozott, meg a hibaüzenet is, hogy miért nem sikerült:

gcc64 ... -Wl,-bE:Modules/python.exp ...
ld: 0706-004 Cannot find or read export file: Modules/python.exp

Namostan ilyen 'Modules' az egész gdb-ben sincs. A /usr/local/src/Python-ban viszont van. Persze ott nem keresi senki, miért keresné? Azon kívül van olyan is, hogy /usr/local/lib64/python2.7/config/python.exp

Az optimális megoldásnak az tűnik, ha megtalálom a gdb valaminő config*-fájljában ezt a 'Modules/python.exp' stringet, és kiszedem.

Naná, miért is restart-olna. Egyébként, ha jól értem, az USR1 szignáltól kellene meg-graceful-nia.
Az első érdekesség, amit látni vélek, hogy egy 'zend_signal_init' nevű komponens is rászívózik a SIGHUP, SIGINT, SIGQUIT, SIGILL, SIGTRAP, SIGABRT, SIGEMT, SIGFPE, SIGKILL(?), SIGBUS-ra. Meg másokra (255-ig). Persze lehet, hogy csak a PHP saját futása idejére.

Szerk:nem akarom az Oracle11-et gyanusítani, de ismét találtam néhány komponenst, amiket szerintem nem kellene exportálnia

$ dump -Tv -X64 libphp.so.7
[287]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.11 guesses
[373]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 ldexp
[374]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 logb
[375]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 sigsetjmp
[376]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 siglongjmp
[377]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 acos
[378]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 asin
[379]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 atan
[380]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 atan2
[381]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 copysign
[382]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 cos
[383]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 cosh
[384]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 exp
[385]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 log
[386]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 log10
[387]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 sin
[388]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 sinh
[389]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 tan
[390]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 tanh
[391]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 unordered
[392]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.11 expm1

Mármint úgy értem, hogy túl simán ment már minden, kellett valami fordítási hiba.
libxml2-2.9.8