NevemTeve blogja

Ha jól értem, ez a MUSL pont olyan mint a glibc, csak nem hasonlít hozzá. Első google-zásra Fecó és Laca hobbiprojektjének látszik, de nem ez a gondom vele, hanem hogy nem találom benne a lokalizáció telepítésének/használatának lehetőségét. A google-találatok nem túl bíztatóak, 'lehet, hogy később lesz benne az is' szerűek. https://wiki.musl-libc.org/roadmap.html

Előzmény: https://hup.hu/node/154630
Megoldás: nincs már oniguruma a 7.4-ben. Kicsit sajnálom, menő neve volt, mint valami egzotikus fűszernek.
Később: Valószínűleg ez lesz az: https://github.com/kkos/oniguruma

Szerk: szerencsére az alloca-s probléma megmaradt benne:

if ! test -f src/regint.h.orig; then cp -p src/regint.h src/regint.h.orig
else                                 cp -p src/regint.h.orig src/regint.h
fi
sed_repl '1i\
#include <alloca.h>' src/regint.h

Szerk: ezeket az opciókat nem ismeri fel a 7.4:

--with-libxml-dir=DIR => --with-libxml=DIR
--with-gd             => --enable-gd --with-external-gd
--with-png-dir        => ?
--with-jpeg-dir,      => --with-jpeg
--with-pcre-dir,      => --with-external-pcre --with-pcre-jit
  with-pcre-regex, 
--enable-zip          => --with-zip
--with-libzip         => ?

Az OpenSSH-ban mintha hibát látnék, nevezetesen a 'wtmp' fájl írásánál inkonzisztencia van a kiírt PID-ben; más processz hívja a 'login'-t, és más a 'logout'/'logwtmp'-t (ezek a libutil.so-ból jönnek).

Peremfeltételek:
* ez csak root-session esetén történik
* Linuxon a 'last' program nem törödik a PID-del, tehát az inkonzisztencia nem manifesztálódik. Na ezzel szemben AIX-on...
* legyen libutil a történetben, mert ha nincs, akkor az sshd önerőből írja a wtmp-t, és akkor ugyanazt a pid-et írja a belépéshez is, meg a kilépéshez is.

Érdekesség, hogy AIX-on általában nincs libutil, de nekem speciel kellett valamihez (azt hiszem, a Samba-hoz).

Azt mondja a derék termék, hogy ő mostan nem osztozik az előző verzió profilján, de valamiféle accountot csinálhatok nála, és akkor az adataim felkerülnek a felhőbe (vagy ilyesmi, ezt a részt nem igazán értem).

Azt hiszem, most akkor én itten egy kis pihenőt tartok a fejlődésben, talán majd később lesz nekem ilyen Firefox-67-em. Vagy lesz valami más. Például a PaleMoon-t múltkor kipróbáltam egy másik gépen, és a klasszikus Netscape-es látványvilág nagyon tetszett nekem.

Szerk: Na jó, frissítésenként törölni kell az új profilt, bosszantó, de megy. Viszont most az új thunderbird-68.1.1 is azzal köszöntött [mint előzmény nélküli új felhasználót], hogy először is állítsak be mail-servert. Ezen a ponton köszönettel visszafordultam az elavult 60.7.2-höz a meglévő beállítasaimmal.

Szomorú a javaws, mert nem tudja futtatni az 'xprop'-ot. De vajon mi az akadály?

Warning - your JRE - 1.8.0_212 - does not match requested JRE - 1.7
java.security.AccessControlException: access denied ("java.io.FilePermission" "/usr/bin/xprop" "execute")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)

Már régen nem volt semmi bajom, hát kipróbáltam egy régebbi unixODBDC-os PHP programocskát.

Mindenki őrizze meg a pánikot, nyugalomra nincs semmi ok.
https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2019-0211

Szerk: bocs, dupla. Akkor csapjunk hozzá egy PHP-7.3.4-et:
https://www.php.net/ChangeLog-7.php#7.3.4

Tegyük fel, hogy korszerű rendszeremben SSL/TLS-t is akarok, meg olyat is akarok, hogy a szolgáltatásokat ide-oda tologatom fizikai és virtuális gépek között, adott esetben terheléselosztókkal súlyosbítva.

Namostan a certificate DNS-nevek és IP-címek véges halmazára szól, ami ütközni látszik az előző feltétellel.

Esetleg szólhatna a certificate egy szolgáltatás-névre, pl 'UrsaMaior-WS', és a kliens feladata a default ellenőrzést felülbírálni.

A curl nevű komponensnél a --resolve opcióval lehet ilyesmit bűvészkedni:

curl --resolve UrsaMaior-WS:someport:someip https://UrsaMaior-WS:someport/

Itt a someport, someip értéke változó, futási paraméter.

Nyilván én vagyok a hibás, elvittem valahonnan valahová... azért érdekelne, hogy hogyan buktam le.

Ezt az üzenetet az 'igazi' libtool írta ki, azt nem tudom, hogy egyáltalán hogyan tudott elindulni, mikor én azt hittem, hogy minden példányát leirtottam, de ez csak egy kis bónusz nyomozás.

Szerk: no, ennek a két stringnek a nem-egyezése okozza a hibát:

libtool: link: warning: `/usr/local/lib64/libiconv.la' seems to be moved\
libdir='/usr/local/lib64' absdir=/usr/local/lib64

Vagyis az 'apostolok' miatt nem egyenlők. Így néz ki a libiconv.la vége:
[code]

Ezuttal valaki/valami az ssh bejelentkezést igyekszik nekem megkönnyíteni, természetesen kéretlenül és hibásan:

$ ssh zsiga@odaahova
agent key RSA SHA256:base64stringhere returned incorrect signature type

de azért sikerül.

Ezt a derék szoftvert gyanusítom:

$ bs2stat 12953 1332
%PID:      12953      PPID:  1332       NOW: 2019-03-07.18:50:44
%USERID:   zsiga      GROUP: zsiga      ELAPSED:           05:55
%STATION:  ?          PRI:   20 0       CPU-USED:       00:00:00
%SIZE(KB): 317304     %MEM:  0.5        %CPU:  0.0
%STATE:    S Sleeping                   WCHAN: SyS_po
%CWD:      /home/zsiga
%CMD:      /usr/lib/x86_64-linux-gnu/polkit-mate/polkit-mate-authentication-agent-1

Illetve futott egy ssh-agent is, kill -9 után <defunct> lett, de a jelenség ugyanaz.

https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
https://news.ycombinator.com/item?id=18909289
Kezdjek aggódni?
Számok:
CVE-2018-20685
CVE-2019-6111

2019.04.21. Nagy pánik nem lehetett ssh-éknál, de azért lett egy 8.0: https://www.openssh.com/releasenotes.html

Azt mondja nekem a kódminőségellenőrző szoftver (Java programhoz), hogy a `finalize` nem jó, az üres utasításblokkokat (`{}`) pedig gond nélkül ki lehet szedni.

Namost a `finalize` ugye arra van, hogy a natív erőforrásokat (file-handle, socket, shm) valahol fel lehessen szabadítani, még akkor is, ha a hívó elmulasztotta a close/dispose/whatnot művelet meghívását (például, mert az Exception-handlerjében is volt egy-két Exception). Ha a derék szoftver az észosztás előtt belenézett volna a src.zip-be, és megnézte volna, hogy abban hol/hogyan használják a finalize-t, akkor ő is tudná.

Telepítettem mindenfélét, de ~/.eszemelyi/eSzemelyi_Kliens.cfg fájlom az nincsen. Viszont az 'eszig-cmu' belepusztul a hiányába. Az 'eszig-eid' el se indul, mert neki <image> kellene. Ha adok neki valamilyen jpeg-et, akkor ugyanúgy megpusztul, mint a másik.

Ebben a történetben a szerveroldalon jelenik meg ez a hibaüzenet:

20181227.093618.061 sv3rd.S3IR_read_ssl(sock=18,maxlen=2000,ptn=10.129.6.30:58474)
                    SSL_read(socket=18) retuned 0
                    SSL_error=1: SSL PROTOCOL
ERR_print_errors_fp:
4294967296:error:14094418:SSL routines:ssl3_read_bytes:
tlsv1 alert unknown ca:ssl/record/rec_layer_s3.c:1528:
SSL alert number 48

Találat a 48-ra:

# define TLS1_AD_UNKNOWN_CA    48/* fatal */
# define SSL_AD_UNKNOWN_CA     TLS1_AD_UNKNOWN_CA

Volt egy gyanúm, hogy esetleg a kliens nem szereti a szerver certificate-jét, és az efeletti panaszát rögzíti a szerver. Teszteltem, de nem sikerült reprodukálni, tehát valószínűleg nem ez a baj.

Ezek nem valamiféle filmszereplők, hanem egy verziókezelő és egy operációs rendszer.
Az SVN ugyebár sokkal jobb, mint a CVS, nemcsak a sorok számát tekintve ((csak *.c és *.h) cvs: 116_468, svn: 1_289_623 + arp), de a CVS alig-alig teszi próbára a naiv felhasználót, az SVN viszont ilyen csemegével kedveskedik:
https://stackoverflow.com/questions/53882162/unable-to-create-subversio…

Az alapprobléma: a nagyon éber https://www.nejegyezzmegjelszot.hu tiltja a Firefoxnak a jelszó megjegyzését (olyan HTML-technikával, amit nem értek, és nem is akarok megérteni, van benne autocomplete=off is, meg más is, nem fontos.)

Nagyon egyszerű lesz az egész, gondoltam: csak telepítek egy "Saved Password Editor" nevű addont, és már tudok is userid+password párokat tárolni/szerkeszteni/törölni.

Vagy nem? Az az addon már régen megszűnt működni, részletek itt.

Szóval a következő egyszerű megoldást választottam: meghaxoltam a /etc/hosts fájlt, hogy a www.nejegyezzmegjelszot.hu a 127.0.0.1-re mutasson.

Mármint nem a rómaiakról van itten szó, hanem Nyomosek Bobó kollégánkról [kitalált név, korábban más volt itt]
Ide töltöttem fel: http://lzsiga.users.sourceforge.net/stevejr.html

Szerk: köszönöm a hibajelzéseket, igyekszem átvezetni őket.

Magyarításról egy pont: http://lzsiga.users.sourceforge.net/stevejr.html#Q0034

Meg egy másik: http://lzsiga.users.sourceforge.net/stevejr.html#Q0035

Ékezetes fájlnevek:
http://lzsiga.users.sourceforge.net/stevejr.html#Q0036

Semmi köze semmihez, csak éppen megemlítem, hogy mi szépet ír a 'man timegm':

For a portable version of timegm(), set the TZ environment variable  to
UTC, call mktime(3) and restore the value of TZ.

Hát persze hogy nem. Mert hiányzik neki a TVision. És az fordul? Naná, hogy nem. És miért? Mert C++. Na jó, most megbuktam, ugyszintén a programozó kolléga:

static
unsigned iSqr( unsigned i )
{
    unsigned res1 = 2;
    unsigned res2 = i/res1;
    while( abs( res1 - res2 ) > 1 )
        {
        res1 = (res1 + res2)/2;
        res2 = i/res1;
        }
    return res1 < res2 ? res1 : res2;
}

Ezen a ponton az 'abs' felesleges, hiszen két 'unsigned' különbsége is 'unsigned'.

Szerk: a következő nagyon tudományos megoldással próbálkozom:

#define uns_abs_diff(i,j) ((i)>=(j)?(i)-(j):(j)-(i))

Nem fontos, csak megtetszett a neve. Nyilván nagyon megkönnyíti az internetes bankolást egy ilyen piwikpro.

2018.10.28. 10:03 Egyelőre csak egy emlékeztető magamnak: Egy debuggolási lehetőség olvasható itt: https://jvns.ca/blog/2017/09/03/debugging-netlink-requests/

2018.10.28. 12:00 Azért nem tökéletesen tökéletes:

python decoder.py pyroute2.netlink.nl80211.nl80211cmd message

Egy rész van benne, ami olvasható: {'attrs': [('NL80211_ATTR_REG_RULES',
Talán kezdetnek jó.

2018.10.28. 12:38 Azt vélem látni, hogy a netlink.h-ban definiált 'nl_wait_for_ack'-ból jön a -7 mint hibakód.

2018.10.28. 19:2 Egyelőre visszaraktam a modules.conf-ba:

options cfg80211 ieee80211_regdom=EU

a /lib/udev/rules.d/85-regulatory.rules-ben pedig mindent kikommenteztem. Mint a kőbaltás ember. Viszont most nem hányja a hibákat.

"Az adatvédelmi jogszabályoknak való megfelelés érdekében arra kérjük, hogy szánjon rá néhány percet, és tekintse át a Google adatvédelmi irányelveinek főbb pontjait."

Feltétlenül át fogom tekinteni, mihelyt időm lesz rá, addig is: https://www.ecosia.org/

Akarom mondani, a haladás nem áll meg, tehát az sshd-t már a systemd indítja a kis laptopomon. És az is állítja meg. Kb. 30 másodperc után. Mert valamiért úgy érzi, hogy nem indult el. Tök jó, hogy ilyen rendes szoftverek vannak, amik gondoskodnak debuggolnivalóról...

Mondjuk egy zavaros pontot azért látok a dologban: ha azt hiszi, hogy nem indult el, akkor mit állít le? Szóval azért tudja, hogy 'jé van itt egy process, amit én indítottam', csak valamiért nem vagyok elégedett vele, hát leállítom'

Szerk: most leírom a legsötétebb gondolatot, ami csak eszembe jutott, és reménykedem, hogy nem ez lesz az igaz: Debianék belemaszt...mesterkedtek az OpenSSH-ba, hogy systemd-kompatibilis legyen, ami persze az eredeti gyári termékben nincs benne. Ezek szerint a megoldás a Type=notify helyett Type=forking lehetne.

Mármint az OpenSSL-1.1.1 és az OpenSSH-7.9p1 között. Még nem tökéletes a dolog, de valami megmozdult.

http://mek.oszk.hu/12500/12517/12517.htm
Mondta a bennszülött miniszter országa egyetlen fehér lakójának.

Hát most a tomcat-native!configure van úgy vele, hogy neki $JAVA_HOME/include/jni_md.h nélkül nem sors a sorsa.

Az semmiképpen sem az ő hibája, hogy egyes implementációkban ugyanez $JAVA_HOME/include/jniport.h néven létezik, továbbá hogy ő ezt a fájlt igazából nem is használja, csak a $JAVA_HOME/include/jni.h-t, ami aztán valahogy gondoskodik a többiről.