Zahy blogja

https://www.openssl.org/news/secadv_20140407.txt

Szokott itt gyűlni ilyen, de idén nem láttam. Linkeket kérek, én ezzel nyitok:
RFC7169: The NSA (No Secrecy Afforded) Certificate Extension

Most láttam www.freshports.org -on, hogy kijött az új VBox. Illetve hát hogy megjelent a FreeBSD ports-fában. FBSD alatt újdonságképpen az OS natív fordítójával fordítva - ami ugye 10.x-en már Clangot jelent. Kb a jövő szombaton esedékes csomagfrissítésbe fog bekerülni tippem szerint, addig remélem kijavítják a kezdeti baromságokat - nem halottam még ilyesmiről, de kizárt, hogy ne lenne. (Nem rossz ez az új csomagkezelő, de még nem 100%-osan tud automatában működni, eddig 2x vagy 3x futottam bele abba, hogy kézzel rá kellett kicsit segíteni. Viszont eddigi rövid tapasztalatom alapján jó irányba fejlődik.)

Este olvastam, hogy megjelent. Nosza. Kis tunodes utan a NAS-a esett a valasztas, igy a NAS-on futo 9.2-t este megfrissitettem.

Az OS frissitese totalisan fajdalommentesen zajlott, ami furcsa volt, hogy a kb 38 es fel ezer letoltendo frissitest az elejen meglehetosen lassan kezdte el athuzni. De aztan megemberelte magat. A legnehezebb resze a pkg_XXX -rol pkgNG-re valtas volt, de igazsag szerint ott sem futottam semmi problemaba. (*) Ami egyedul nincs automatizalva, az az olyan csomagok kezelese, mint pl. a perl - a 9-esen 5.14 az alapertelmezett verzio, a 10-esben mar 5.16. Es ahhoz, hogy mukodjon a dolog, kezzel ki kellett adni egy

Elvben ma kéne kijönnie a FreeBSD-10.0R-nek. Ehhez képest 4 db SA érkezett, ebből 1 db saját, a bsnmpd nevű szoftverhez, a másik három contrib kódhoz kapcsolódik: az ntpd, az OpenSSL és a BIND az áldozat. Nyami.

Tegnap még fel se tűnt, erre ma reggel már aszongya, hogy 10 év 1 nap.

Ma este ezekkel játszottam egy kicsit FreeBSD és Linux alatt. FreeBSD alatt az extended attributumok kezelése minden csak nem intuitív, de látszólag működik. Mondjuk a doksi vicces kissé, mert 4 parancsot is leír ugyanabban a man oldalban (setextattr, getextattr, lsextattr, rmextattr), de elfelejtették leírni, hogy pontosan melyik mire is jó :-) Még szerencse, hogy azért elég könnyű rájönni.

Ennél már csak a linuxos getfattr / setfattr viccesebb. Eleve ha szegény ember csak a setfattr man-t nézi meg nulla előismerettel, az életben nem fog tudni beállítani egyet sem, mert sehol nem szerepel az, hogy a megadandó attributumnév névtér.mezőnév formájú, ráadásul az se szerepel a doksiban, hogy mik a használható névterek (ami engem izgatott, az a user és system névtér). Szerencsére van nekünk getfattr manunk is, ebben van példa is, és máris látszik, hogy milyen formában várja a setfattr azt a nyavalyás opciót; valamint van nekünk man 5 attr, amiben legalább egyértelműen le van írva a használandó forma, és hogy egyébként milyen névterek vannnak. De a lényeg, némi küzdelem után azét csak sikerült dűlőre jutni.

Aki nem ismerné az IOCCC-t, annak a rövidítés feloldása: The International Obfuscated C Code Contest. És mit találtam: (no jó, egy ismerős mutatta): IOCCC2012 endoh1.c

Tekintve, hogy a FreePBX saját oldala szerint ha nem is supportált, de legalább tested Ubuntu 12.04 LTS-en, megprobáltam összehozni a dolgot. Mondanom se kell, a leirástól a hajam égnek áll (nem igaz, hogy "az apache-ot www-user/www-data/akarmi helyett asterisk-ként futtatjuk" megoldásnál a webes világ nem tud szebbet ilyen PHP-s trágya esetén; meg pl. CentOS-en kapcsoljuk ki a SELinuxot; stb), a nagyobbik baj, hogy nem fut le a végén a konfigurátor. Az install_amp részben valami egetverő

PHP Fatal error: Class 'notifications' not found

üzenettel örvendeztet meg. Mivel a PHP nem az én világom, ezért aztán a mai nap jelentős részében a netet túrtam és keresgéltem, de azon kívül, hogy pár hete más is belefutott a dologba (válasz: használj CentOS-t), értelmes infó nincs. Maradt a józan paraszti ész, és kitalálni, hogy az ismeretlen nyelven megírt kódban mi lehet a hiba. Szóval a lenti megoldás lehet, hogy egy hozzáértő (van olyan?) PHP-programozónál kiveri a biztosítékot, mindenesetre a problémát legalábbis arrébb tolta, mert most szépen fut az installer, és épp töltögeti a vacak moduljait.

Megjelent (elvben az előző linken elérhető, nekem csak ezen sikerült). Van pár apróság a javítási listában. Sajnos a Centrino-2230-as chip támogatás ebben sincs benne, ha jól láttam az a véglegesben sem lesz.

Ime az idei julius-szeptemberi idoszakra vonatkozo: http://www.freebsd.org/news/status/report-2013-07-2013-09.html. Nalam mondjuk kisse kiverte a biztositekot, h az Objective-C es Ada fejlesztok elsoszamu platformjava valik a FreeBSD (foleg, mert emlekeim szerint az LLVM-nel az Obj-C-rol meg mindig nem annyira szuperlativuszokban beszelnek), de ez van. Varom a 10.0-t, miutan alig egy hete frissitettem 9.2-re.

Nézem $subj leírását:

===
A simple tool to convert packet captures in 802.11 format to Ethernet format.
Lots of tools can only understand Ethernet link types, so I wrote this
tool to convert captures to a format that they can understand.
Note that this tool is really only useful for encrypted traffic.

Specify a wireless packet capture as an input file, and the name of the
desired Ethernet-format output file. Wlan2eth will only convert data frames
to the output file, which will likely result in a significantly smaller output
packet capture file. Note that wlan2eth will only convert unencrypted frames.

http://www.freebsd.org/releases/9.2R/announce.html

(Az sajnos már kiderült, hogy az iwn driver változatlanul nem támogatja a gyári laptopom wifijét, de remélem a 10.0-alpha4 ebből a szempontból előrelépés lesz.)

Néhány ftp-szerveren ott csücsül pár ISO fájl 9.2-es márkajelzéssel, 27-i dátummal. No akkor meglessük, mit tudnak. Aztán ha az előzőekben "bevált" módszert követik, akkor ma és holnap kijön még 3-5 FreeBSD Security Advisory, és megint elcsúszik 1-2 héttel a megjelenés. (Pedig nekem legkésőbb kedd estig egy laptopot fissítenem kellene, mert utána negyed évre eltűnik a kezeim közül.)

Nem olyan rég azon morogtam, hogy sajnos a BHyve még mindig nem támogatja az AMD-procikat. Erre ma véletlenül belefutottam ebbe a (kb egy hónappal ezelőtti) levlistás levélbe, és utánaolvasva kiderült, hogy immár létezik a támogatás (AMD-nél SVM-ként hivatkoznak erre a processzorfunkcióra), sőt mi több, a terv az, hogy a FreeBSD-10.0-ban benne is legyen. Ez eddig jó hír. Persze közben az járt a fejemben, hogy nekem ez tök mindegy, egy kivételtől eltekintve mindegyik gépemben Intel proci van. És noha az Intel virtualizációs támogatása (VMX processzor-flag) kivétel nélkül mindegyikben adott, a BHyve igényel egy másik, csak az újabb (az enyémeknél újabb) procikban meglevő funkciót - azaz ez számomra semmit nem jelent, nem fogom tudni még kipróbálni sem. Aztán továbbolvasva a fenti szálat, meg néhány linket végiglátogatva, kiderült hogy a helyzet ennél jobb, mert az egyetlen AMD-procis gépemben AMD Turion(tm) II Neo N40L Dual-Core Processor van, az pedig még Hyper-V alatt is támogatott (meg ESXi, meg mint kiderült BHyve alatt is). Azaz csak lesz min kipróbálni. Naccerű. Akkor már csak a 9.2-t kell kivárni (elvben ezen a héten már meg kellett volna érkezzen, tehát jövő hét végéig csak megérkezik), és akkor utána lehet izgulni, hogy az Alpha2-státuszban levő 10.0 érkezzen meg a téli szünet vége előtt, hogy legyen egy kis idő a tesztre.

Forrás: Andriy Gapon a freebsd-stable-levlistán ( http://lists.freebsd.org/pipermail/freebsd-stable/2013-September/075173… ) Jól jöhet ez még.

Now some high level information on how ZFS boot works and a little bit more
detailed information on how a root filesystem is chosen in ZFS case. The
information is applicable to recent versions of FreeBSD in head, stable/9
(including upcoming 9.2) and stable/8 (including 8.4).

- boot0-like stage always takes boot2-like stage from the same disk using simple
rules
- boot2-like stage probes all disks and partitions it can understand for ZFS pools
- default pool is the first pool detected by probing which starts at boot disk
- default filesystem is determined by bootfs property
- boot2-like stage allows to select a different pool, a specific filesystem in
the pool and a specific loader

Panaszkodik a szomszéd, h valamit elb-tak a gyerekei, mert a bal felső sarokban mindig megjelenik a TV-n az az információs logókupac, ami azt ábrázolja, hogy mit is tud a TV (4HDMI, Allshare, Personal VideoRecorder, stb). És persze rohadt idegesíti. Mondom semmi gond, ismerem a dolgot, megkeresem neki a neten, hogy hogy kell kikapcsolni. Rémlik, h valahol a szervíz menüben. Bár rohadtul nem értettem, hogy tudtak a gyerekei bejutni a szervízmenübe, az azért véletlenül nem nagyon megy. Aztán mire odáig jutottam, h gép bekapcsol és keresnék, addigra már hívott is, hogy megtalálta és megcsinálta a leírtakat, sajnos ami nagyon zavarja, hogy elvesztette a csatornabeállításait is. Sajnálkoztam, de bújkált bennem a kisördög, így mégiscsak elkezdtem keresni. Mit ad isten, van egy vagon magyar nyelvű találat (mint pl. a logout.hu amúgy nagyon jó Samsung tudástára is), mind leírja az adott probléma megoldásához a beállítások elvesztésével járó Plug-and-Play menüpontot - arról kedélyesen hallgatva, hogy ekkor hangolhatod be előlről az egész TV-t. Nosza angol nyelvű találatok, hát mit ad istem mindenütt más szerepel. Ezt végül kipróbáltuk többször is, megy. Íme az adatvesztés nélküli ki- és bekapcsolása az "üzlet mód" - "otthon mód" beállításnak. Egyszerű mint a faék, és semmi fájdalmat nem okoz.

Zseniális. Ha jó a leírás, akkor sikerült kizárólag a 9.2-RC1 és -RC2 verzióiban meglevő hibát előállítani. Persze ilyen trivialitások azért felmerülnek az emberben: mi van az RC3-mal? Honnan szedték a hibás kódot? Véletlenül nem a 10-es ágból? No mindegy, egy-két hét csúszás a 9.2 megjelenésében már megszokott mutatvány.

http://security.freebsd.org/advisories/FreeBSD-SA-13:11.sendfile.asc

Hopp, beesett még 3 - izé 4 - másik. Nem unatkoztak a fiúk.

sctp huba: Ez egy korábbinak a módosítása: http://security.FreeBSD.org/advisories/FreeBSD-SA-13:10.sctp.asc
Nyamm: interfészeket lehet buzerálni: http://security.freebsd.org/advisories/FreeBSD-SA-13:12.ifioctl.asc
Ez se rossz: http://security.freebsd.org/advisories/FreeBSD-SA-13:13.nullfs.asc
És még egy javított SA, multicast kezeléssel kapcsolatos hiba: http://security.freebsd.org/advisories/FreeBSD-SA-13:09.ip_multicast.asc

6-án megjelent. Ma már a FreeBSD ports-ban is benne van. (Mondjuk gyanítom a hamarosan (?) megjelenő 9.2-höz tartozó ports-fában még nem ezt fogják csomagolni.)

Ma hivta fel valaki a figyelmemet egy juliusi forumbejegyzesre, es ezek utan felmenve a PC-BSD oldalara, azt latom, h mar nincs 32-bites verzio az uj verziobol. Hm. Pedig van azert meg jocskan 32-bitet tudo gep, meg olyan is, amelyik akar deszktopnak is hasznalhato lenne - amire ugye szanjak. Meg szerencse, hogy a FreeBSD-ben meg megmaradt a tamogatas.

8-as es 9-es ag, ip_multicast huba: http://security.FreeBSD.org/advisories/FreeBSD-SA-13:09.ip_multicast.asc
8-as es 9-es ag, sctp huba: http://security.freebsd.org/advisories/FreeBSD-SA-13:10.sctp.asc

10-esrol nem szol a fama, felteszem hamarosan megerkeznek az aggodo levelek a listara ez ugyben, es kiderul, hogy igen, azokban is letezo libarol van szo, de mivel development statuszu agrol van szo, ezert azok nem szerepelnek a leirasban.

http://thehackernews.com/2013/08/vulnerability-in-usb-internet-modems.h…
(Csak megismételni tudom egy máshol leírt megjegyzésemet:

Némi igazsága lehet (a videókat nem néztem), de az garantáltan baromság, hogy az egymást követő telefonszámok azonos tipusú mobil-stickhez tartoznak - lévén ugye a telefonszám a benne levő SIM-kártyához tartozik. AZ persze más tészta, hogy mondjuk egy feltört Asterisken keresztül megbombázni pár tízezer mobil számot ilyen SMS-sel lehet, hogy érdekes eredményre vezetne.

http://www.freebsd.org/news/status/report-2013-04-2013-06.html

WTF? http://hvg.hu/tudomany/20130716_megszunik_a_skype_desktop_api
Ha jól tudom, ez a *x világban a pidgin-skype-plugin-t jelenti kb, az meg eddig is a natív skype-ot hívta. Lehet, hogy valamit félreértek?

Összelőttem őket (plusz minissdpd), néhány apróság:

- ha egymás mellett van az Akarmi.mkv / Akarmi.avi és Akarmi.srt, akkor a minidlna átküldi, és a TV automatában mutatja a feliratot (de természetesen kikapcsolható), elcsúszás és kódolás és méret állítható

- *.sub+*.idx-es feliratot nem kezel (valami)

- *.iso nem megy, meg se jelenik a lejátszhatóak listájában (tudom, ez a DLNA-szabvány hiányossága)

- a TV nem szereti az mkv-ban levő VORBIS codec-et, ezt egy elegáns hibaüzenettel jelzi is

- valamiért egy 3 feliratot is tartalmazó filmben egyet se mutat. Kellenének mindenféle tesztek, mert elvben lehet alapértelmezett sávokat beállítani az mkv-ban, és lehet, hogy ha ezt beállítja az ember a feliratsávra is (a hangcsatornán szokták), illetve van valami forced kapcsoló is, akkor lehet, hogy változik a helyzet.