Mageia Blog (Україна)

Перш ніж ми перейдемо до огляду, маємо подякувати усім магейцям, хто допомагав у скиданні паролів після виявлення нашої проблеми із захистом останнього тижня. Здається, зараз проблему вже вирішено, але, будь ласка, зверніться до нашого форуму або списку листування для обговорення, якщо вам потрібна допомога.

А ось і сам огляд:

Протягом останніх двох тижні до updates/testing надійшло 1282 пакунка – команда розробників не байдикувала! І, як ви можете бачити нижче, усе ще надходять оновлення захисту для Mageia 5, але вам слід бути готовими до завершення терміну підтримки цієї версії, якщо ви усе ще не оновилися до Mageia 6.

Оновлення захисту:

• ghostscript – Mga 5, Mga6
• advancecomp – Mga6
• freetype2 – Mga6
• mariadb – Mga5
• jackson-databind – Mga6
• postgresql9.4, postgresql9.6 – Mga5, Mga6
• apache-commons-email – Mga6
• glpi, php-zetacomponents-base – Mga6
• kernel, kernel-userspace-headers, kmod-vboxadditions, kmod-virtualbox, kmod-xtables-addons – Mga6
• kernel-linus – Mga6
• kernel-tmb – Mga6
• quagga – Mga6
• irssi – Mga6
• qpdf, cups-filters – Mga6
• mpv – Mga6
• nasm – Mga6

Оновлення із виправленнями вад:

• openbox – Mga6
• hplip – Mga6
• qarte – Mga6
• pure-ftpd – Mga6
• networkmanager – Mga6

Як завжи, ви можете стежити за Mageia Advisories, Mageia AppDB, PkgSubmit, де показано оновлення протягом останніх 48 годин, таBugzilla, щоб першими дізнаватися про оновлення.

Цей допис є перекладом допису у англомовному блозі.

До нашої бази даних LDAP зміг отримати доступ одн з користувачів, який оприлюднив адреси електронної пошти, імена, а також видимі хеші паролів усіх, хто реєструвався на identity.mageia.org. Втім, оприлюднені хеші не відповідають основним записам, великі літери було прибрано, тому не зовсім очевидно, чи насправді скомпрометовано паролі. З моменту виявлення витоку даних усі паролі було скинуто з метою захисту решти даних. Було додано нові правила, які запобігають доступу до сервера LDAP. Системні адміністратори вивчають причини читання полів бази даних, незважаючи на, здавалось би, явним чином встановлену заборону.

Паролі, які зберігаються на сервері LDAP Mageia хешовано та шифровано, що означає, що повне дешифрування паролів, якщо справді мав місце їхній виток, до придатного до використання формату потребуватиме значних обчислювальних потужностей для складних паролів. Хоча оприлюднені дані містять лише імена та адреси електронної пошти користувачів identity.mageia.org, ми наполегливо рекомендуємо користувачам вжити заходів, якщо їхній пароль до облікового запису Mageia використовувався ще десь. Також рекомендуємо змінити ймовірно скомпрометовані паролі всюди, де їх було використано.

Щоб відновити доступ до вашого облікового запису Mageia, достатньо перейти за посиланням щодо скидання пароля для усіх користувачів без доступу до git. Посилання на скидання пароля можна отримати на сторінці https://identity.mageia.org/forgot_password Це посилання буде надіслано до вашої поштової скриньки.

Для відновлення доступу привілейовані користувачі мають звернутися до системних адміністраторів.

Ми щиро вибачаємося за усі проблеми та незручності, причиною яких міг стати цей виток даних.

Цей допис є перекладом допису у англомовному блозі.

Це оновлення надіслав нам tmb, наш чарівник ядра:

З часу вчорашнього випуску 4.14.18 можемо сказати, що усування наслідків вад є доволі ефективним, особливо для архітектури x86_64. Тепер система забезпечує певний захист від Spectre версій 1 і 2 та Meltdown.

Звичайно ж, протягом наступних тижнів або місяців до основної гілки розробки ядра буде включено ще більше виправлень для рідкісних випадків вад, пропущених ділянок коду та удосконалень виправлень…

Також нам знадобляться випуски мікропрограм від Intel та AMD, щоб виробники обладнання змогли випустити оновлені мікропрограми BIOS/EFI. Також чекаємо на оприлюднення мікрокоду, щоб ми могли оновити мікропрограми, якщо цього не зроблять виробники.

Ага, для тих, хто хоче перевірити 🙂 Офіційним способом перевірки стану ядра є така команда:

grep . /sys/devices/system/cpu/vulnerabilities/*

Усе ще немає виправлень вади meltdown для 32-бітової mga6, але я вже (станом на 9 лютого) використав запропоновані у основній гілці розробки латки у Cauldron, отже, ядро з цими латками опиниться у сховищі testing взавтра разом із оновленням 4.14.19

Усе ще не використано код для удосконалення швидкодії, але ми над цим працюємо.

Красно дякуємо tmb за роботу над цим оновленням!

Цей допис є перекладом допису у англомовному блозі.

Перш ніж ми перейдемо до опису FOSDEM, важливе оновлення, яке надійшло протягом останніх декількох годин – це продовження поясення від tmb у попередньому огляді:

MGASA-2018-0125 – Оновлені пакунки ядра виправляють вади захисту

Дата оприлюднення: 11 лютого 2018 року
Адреса: https://advisories.mageia.org/MGASA-2018-0125.html
Тип: захист
CVE: CVE-2017-5715, CVE-2017-5753
Опис:

Це оновлення ядра засновано на основній версії 4.14.18 і додає підтримку захисту від Spectre, варіант 1 (CVE-2017-5753), оскільки його зібрано за домогою gcc-5.5.0-1.mga6 із увімкненим retpoline, воно забезпечує повне усування Spectre за допомогою retpoline для варіанта 2 (CVE-2017-5715). WireGuard оновлено до версії 0.0.20180202. Це оновлення також усуває проблеми із драйвером rtl8812au, який не працював або не встановлювався у оновлення ядер 4.14 (mga#22524). Інші виправлення у цьому оновленні описано у відповідних журналах.

Красно дякуємо tmb та іншим розробникам за їхню працю!

Докладніший огляд подій очікуємо наступного тижня. Тепер же, до подій FOSDEM від особи, яка бере участь кожного року…

Mageia на FOSDEM 2018

З моменту появи Mageia FOSDEM була дуже важливою подією для нас. Шість разів ми мали стенд і проводили загальну асамблею під час цієї події, завжди зустрічалися на вечені Mageia, тут у нас завжди було більше нагод зустрітися один з одним.

Втім, цей допис у блозі не було б написано, оскільки менш ніж за тиждень до FOSDEM лише один з членів керівної ради, akien, зголосився бути на події. Втім, він головним чином відвідав подію через ніший чудовий проект, рушій Godot. Окрім цього, наше подання щодо стенду було відхилено (знову).

За шість днів до початку FOSDEM на сторінці вікі щодо FOSDEM 2018 почали з’являтися інші імена. За день стало зрозумілим, що подію відвідає ennael, а у середу кількість відвідувачів серед членів керівної ради зросла з 2 до 4. Лише після цього ми почали шукати волонтерів для допомоги у організації зустрічі у Брюсселі.

Ми жалкуємо щодо цього — ймовірно, якби усе було організовано краще і раніше, на зустріч з’явилося б більше магейців!

Неформальна зустріч поза загальною асамблеєю

Врешті, на FOSDEM побувало принаймні 14 учасників спільноти. Не усім вдалося зустрітися одне з одним, але більшість з нас побували на неформальній зустрічі поза загальною асамблеєю (загальну асамблею ми плануєм провести у мережі за допомогою Mumble пізніше, щоб у ній могли взяти участь більше членів ради, бюро та асоціації).

Більшу частину з того, що було сказано під час неформальної зустрічі, буде повторено і під час загальної асамблеї, окрім виступу karine, яка зголосилася до участі у спільноті (на час загальної асамблеї вона вже буде учасницею 😉 ), та зауважження, зробленого tmb, після того, як ennael повідомила про те, що у багатьох учасників нашої спільноти проблеми зі здоров’ям. Він сказав щось подібне до «Mageia, дистрибутив для людей із проблемами зі здоров’ям». Ми усі посміхнулися, але у цьому зауваженні є краплина істини: учасникам, які мають проблеми зі здоров’ям, завжди були так само раді у Mageia, як учасникам із відмінним здоров’ям.

Mageia ніколи не з’явилася б на світ, якби нею опікувалися лише здорові люди (звичайно ж, було б помилкою сказати, що її створили лише хворі люди 😉 ). Що б там не було, якщо ви хочете взяти участь, але сумніваєтеся, чи достатньо у вас здоров’я, щоб вас прийняли до спільноти: не вагайтеся, ваш внесок буде зустріто так само радісно, як і внесок будь-якого іншого учасника. Немає ніяких обмежень щодо мінімальної участі. Отже, знайдіть команду або завдання і допомагайте у створенні дистрибутива, коли почуваєтеся достатньо сильним для цього 🙂

Вечеря Mageia у суботу

Ми не замовили столик наперед, тому довелося доволі довго шукати ресторан, у якому виявилося б достатньо місця для усіх нас. Врешті, восьмеро магейців знайшли місце для вечені у арабському ресторані, у якому більшість з них побувала вперше. Це стало доброю звичкою знаходити щоразу новий ресторан, щоб поїсти вафель. Втім, можливо, ця звичка не така вже добра, якщо хтось хотів схуднути.

Пивна зустріч Mageia (ланч) у недію

Під час зустрічі akien запропонував нову традицію: зустрітися ще раз наступного дня, щоб попити пива. Для декого це був скоріше ланч, ніж смакування пива, але, що б там не було, це була ще одна чудова нагода зустрітися, оскільки без стенду Mageia ми не мали ніякого додаткового місця для зустрічей.

Сама FOSDEM

Здається, з кожним роком у FOSDEM усе більше відвідувачів. Усе частіше виступи збирають набагато більше відвідувачів, ніж може вміститися у кімнаті. Мені не вдалося навіть побачити ovitters, який був на стенді GNOME – там було так багато людей, що було важко навіть підійти ближче.

Один із магейців також вважає корисне проведення часу на FOSDEM доволі складним: «Оскільки людей дуже багато, мені не вдалося відвідати важливі для мене зустрічі, оскільки довелося б прориватися і зривати попередні виступи, щоб потрапити до потрібної кімнати до того, як її буде «зачинено». У самій кімнаті якість звуку настільки низька, що іноді неможливо було нічого розчути. Через це, я не хочу більше відвідувати цю подію. Я страшенно розчарований і жалкую втраченого часу. Усе це стосується FOSDEM та організаторів події, але не стосується мого задоволення від зустрічі з вами та іншими учасниками».

Відео з багатьох обговорень можна знайти тут: https://video.fosdem.org/2018/ і тут https://www.youtube.com/user/fosdemtalks/videos.

Майбутні зустрічіuture Mageia meetings

Оскільки на FOSDEM було багато людей, у нас не було змоги зібратися у кіманіті чи на стенді, зустрітися було доволі важко. Можливо, нам варто вибрати якесь інше місце для зустрічей — конференцію, де буде менше людей, але краще організовану, або навіть щось поза конференціями? Ваші поради стануть у пригоді. Будь ласка, залишайте коментарі під цим дописом, коментуйте на форумі та пишіть до списків листування.

Дякуємо Marja за цей допис! Ми хотіли включити до нього декілька знімків, але магейці, які їх зробили, ховаються – можливо, наступного тижня…

Цей допис є перекладом допису у англомовному блозі.

Потік оновлень цього тижня трохи послабшав:

sox (Mga 5, 6); java-1.8.0-openjdk (Mga 5,6); rsyncMga 5,6; gdk-pixbuf2.0 (Mga5) – як завжди, докладний опис на Mageia Advisories. Разом із 409 оновленнями у Cauldron, це вже доволі багато!

За лаштунками тривала робота над механізмом оновлення за допомогою аплету панелі, подальшим усуванням проблем із Meltdown/Spectra та можливим випуском Mageia 6.1. Таким чином, розробники та учасники команди із забезпечення якості мали вдосталь роботи. Як завжди, із докладним описом можна ознайомитися на Mageia Advisories, у Mageia AppDB і на PkgSubmit, де наведено список змін протягом останніх 48 годин. Bugzilla також є корисним джерелом даних щодо того, що відбувається.

Також майже щодня відбувається додавання та оновлення перекладів. Велика подяка нашій команді перекладачів, які роблять Mageia зручнішою для користувачів з усього світу!

Проміжні відомості щодо усування проблем із Meltdown/Spectra

Від tmb, нашого дуже зайнятого знавця ядра, якому ми щоденно дякуємо:

Якщо у відповідь на команду

grep cpu_insecure /proc/cpuinfo && echo "patched" || echo "unpatched"

ви бачите

unpatched

не переймайтеся – ця перевірка не є коректною. У офіційному коді ядра Linux немає жодного прапорця «cpu_insecure».

Якщо ж у відповідь на команду

   cat /proc/cpuinfo | grep bugs

ви бачите

bugs            : cpu_meltdown
bugs            : cpu_meltdown
bugs            : cpu_meltdown
bugs            : cpu_meltdown

це свідчить про те, що ваш процесор вразливий до meltdown і його слід захистити за допомогою KTPI. Єдиний спосіб позбутися від цього прапорця — придбати новий процесор. Це означає, якщо вірити Intel, новий процесор, який з’явиться наприкінці 2018 року. Якщо йдеться про AMD та вразливість Spectre, вам доведеться придбати процесор на основі Zen2, який, як припускають, буде випущено протягом 2018 року.

Якщо ви скористалися https://github.com/speed47/spectre-meltdown-checker і отримали відповідь «not OK»:

Так і має бути, і ось чому:

1. Варіант 1 Spectre важко виправити, хоча ним і важче скористатися – він потребує оновлення мікрокоду процесора. Intel не впоралася із цим завданням. За даними компанії Lenovo виправлення слід очікувати приблизно 9 лютого. AMD офіційно надсилає оновлення мікрокоду лише виробникам обладнання. Тому виправлення помилки у процесорах цієї компанії залежатиме від того, коли AMD випустить оновлені BIOS або розповсюдить мікрокод у інший спосіб. Тут також треба буде виправити код, але, наскільки відомо, виправлення ще не з’явилися у коді основної гілки розробки.

2. Варіант 2 Spectre  також потребує нового мікрокоду. Виправлення у коді ядра IBRR/IBPB/… вже почали з’являтися у основній гілці розробки протягом минулого тижня. Їх ще слід буде портувати на ядро 4.14 із подовженим терміном підтримки. Ми також маємо альтернативне виправлення із мінімальним retpoline, опис якого є на сторінці https://bugs.mageia.org/show_bug.cgi?id=22454 (я планую скористатися цим виправленням сьогодні, щойно допишу оголошення). Для повного використання retpoline нам потрібна підтримка з боку компілятора. Мені вдалося розробити відповідні виправлення під час FOSDEM, і gcc 5.5.0 у testing вже залатано, тому у наступному ядрі буде повна підтримка retpoline.

3. Meltdown виправлено у випуску ядра 4.14.13: http://advisories.mageia.org/MGASA-2018-0076.html.

ЗАУВАЖЕННЯ. Виправлення ізолюванням таблиці сторінок у ядрі стосується лише архітектури x86_64, але вже запропоновано деякі латки для i586. Сподіваємося, невдовзі виправлення з’являться у коді основної гілки розробки, і їх буде портовано на попередні версії ядра. Але, знову ж таки, meltdown не так просто використати на 32-бітовій системі, оскільки там уже є поділ пам’яті на межі 3ГБ/1ГБ, який спричиняє інші ускладнення.

Далі, як відомо, деякі (значна кількість) дистрибутиви наклали «панічні латки» із ранніми спробами виправлення вад, але, наприклад, Red Hat відклала деякі з виправлень spectre, оскільки латки спричиняли більше проблем, ніж виправляли. Тому я вирішив, що краще буде скористатися добре перевіреним кодом, який буде прийнято і використано у основній гілці розробки.

Ось на якому етапі ми зараз. Якщо у основній гілці розробки збережуть темп, сподіваємося, що усі проблеми буде вирішено протягом приблизно одного тижня…

Дякуємо, tmb!

Інші новини:

Відбувається голосування у конкурсі LQ Members Choice Awards. Ви можете зареєструватися і проголосувати за Mageia, як ваш дистрибутив, щоб трохи «прорекламувати» вашу улюблену операційну систему. Адреса сторінки голосування:

https://www.linuxquestions.org/questions/2017-linuxquestions-org-members-choice-awards-126/

Якщо ви не є учасником групи LinuxQuestions.org, вам слід зареєструватися і залишити принаймні один допис на сайті. Це надасть вам змогу проголосувати у різноманітних опитуваннях щодо Linux. Розповсюдьте цю інформацію серед інших прихильників Mageia і додайте нам голосів!

Цей допис є перекладом допису у англомовному блозі.