Стильно, модно, молодёжно.

Mozilla Foundation публикует победную запись в блоге: Make your Firefox browser a privacy superpower with these extensions.

И внезапно выясняется, что

With this extension, I see that for every page you load in your browser, there is a POST to http://136.243.163.73/. The posted data is garbled, maybe someone will have the time to investigate further.

Ну и развязка: Firefox Add-On With 220,000+ Installs Caught Collecting Users' Browsing History.

Где там было сравнение производительности движков? «Servo ворует ваши личные данные вдвое быстрее, чем Gecko и XUL».

Ну и, для тех, кто забыл, 2 года назад вся эта ахинея начиналась так:

More Secure Extensions

Because extensions built with the Add-on SDK can request XPCOM privileges, they could still introduce unintentional security and stability issues into Firefox. Even add-ons written by well-meaning developers can accidentally introduce vulnerabilities that could allow malicious code to execute with the full privileges of the browser. WebExtensions uses its manifest.json to mitigate this by requiring add-on authors to declare up front which permissions their code will need to operate. Unlike the Add-on SDK, WebExtensions does not allow arbitrary XUL/XPCOM access, so even insecure/vulnerable code is limited to its whitelisted subset of functionality. This vastly reduces the vulnerability surface of a WebExtension, leading to faster review times and a more stable browser.

Попробовал тут по старой памяти скрестить богомерзкий slack (стильно, модно, молодёжно, корпоративный стандарт) с Pidgin через XMPP, но увы.

Модуль для weechat (wee-slack/wee-slack) тоже не взлетел (т. е. соединяется, но не работает).

Вот ещё нашёл erroneousboat/slack-term (альфа, проект не обновлялся с апреля) и cixtor/slackapi, но их пощупать пока руки не дошли.

Какой у кого есть опыт? Поделитесь, пожалуйста.

Хочется slack-клиент, который бы не был написан на JavaScript и жрал бы меньше 1G оперативы.

Дано:

• Один пользователь, от имени которого запущены X Window
• Другой пользователь (имеющий доступ к текущему DISPLAY), от имени которого запущено некоторое GUI-приложение, показывающее оповещения через dbus. Но dbus наплевать на текущий DISPLAY.

Хочется странного: чтобы dbus-оповещения другого пользователя показывались на экране. Т. е., чтобы имело видимый эффект, например, следующее:

sudo -u ihateslack notify-send 'Заголовок' 'Текст' --icon=dialog-information

Приветствую.

По какой-то причине настройки клавиатуры внутри /etc/X11/xorg.conf:

Section "InputDevice"
        Identifier      "Keyboard0"

        Driver          "evdev"
        Option          "Device"        "/dev/input/by-id/usb-Logitech_USB_Keyboard-event-kbd"

        Option          "XkbRules"      "xorg"
        Option          "XkbModel" "pc105"
        Option          "XkbLayout" "us,ru"
        Option          "XkbVariant" ",winkeys"
        Option          "XkbOptions" "altwin:meta_win,compose:ralt,grp:menu_toggle,grp:rctrl_switch,grp:sclk_toggle,grp_led:scroll,terminate:ctrl_alt_bksp"
EndSection

не работают должным образом (ну, т. е., не включается переназначение Meta на Win, игнорируется Ctrl+Alt+Backspace и т. д.), так что приходится всё дублировать в ~/.xinitrc:

setxkbmap -option
setxkbmap -option altwin:meta_win
setxkbmap -option compose:ralt
setxkbmap -option grp:menu_toggle
setxkbmap -option grp:rctrl_switch
setxkbmap -option grp:sclk_toggle
setxkbmap -option grp_led:scroll
setxkbmap -option terminate:ctrl_alt_bksp

В логе на старте виже следующее (т. е. «клавиатур», похоже, было найдено куда больше, чем я просил):

( (простыня) )

Ну и в том же самом логе многократно в процессе работы:

[2021148.899] (II) input device 'Power Button', /dev/input/event6 is tagged by udev as: Keyboard
[2021148.899] (II) input device 'Power Button', /dev/input/event6 is a keyboard
[2021148.900] (II) input device 'Video Bus', /dev/input/event16 is tagged by udev as: Keyboard
[2021148.900] (II) input device 'Video Bus', /dev/input/event16 is a keyboard
[2021148.900] (II) input device 'Power Button', /dev/input/event4 is tagged by udev as: Keyboard
[2021148.900] (II) input device 'Power Button', /dev/input/event4 is a keyboard
[2021148.901] (II) input device 'Sleep Button', /dev/input/event5 is tagged by udev as: Keyboard
[2021148.901] (II) input device 'Sleep Button', /dev/input/event5 is a keyboard
[2021148.902] (II) input device 'Logitech USB Keyboard', /dev/input/event1 is tagged by udev as: Keyboard
[2021148.902] (II) input device 'Logitech USB Keyboard', /dev/input/event1 is a keyboard
[2021148.902] (II) input device 'Logitech USB Keyboard', /dev/input/event2 is tagged by udev as: Keyboard
[2021148.902] (II) input device 'Logitech USB Keyboard', /dev/input/event2 is a keyboard
[2021148.903] (II) input device 'Logitech Logitech USB Headset', /dev/input/event0 is tagged by udev as: Keyboard
[2021148.903] (II) input device 'Logitech Logitech USB Headset', /dev/input/event0 is a keyboard
[2021148.904] (II) input device 'ACPI Virtual Keyboard Device', /dev/input/event20 is tagged by udev as: Keyboard
[2021148.904] (II) input device 'ACPI Virtual Keyboard Device', /dev/input/event20 is a keyboard

Как можно дальше продиагностировать это поведение?

Хочется однократно задать настройки клавиатуры для всех пользователей, а не носить ~/.xinitrc туда-сюда.

Если экземпляр BasicDataSource из Apache commons-dbcp (версии 1.4, т. к. я ограничен Java 1.6) сконфигурирован с defaultAutoCommit=false, то библиотека выполняет два идиотских ROLLBACK'а — один при взятии соединения из пула, и ещё один при возвращении его обратно (т. е. закрытии соединения из пула при сохранении низкоуровневого физического соединения открытым).

Соответствующие стек-трейсы (на примере T4CConnection драйвера Oracle Thin):

T4CConnection(PhysicalConnection).rollback() line: 1950	
PoolableConnection(DelegatingConnection).rollback() line: 368	
PoolableConnectionFactory.passivateObject(Object) line: 685	
BasicDataSource.validateConnectionFactory(PoolableConnectionFactory) line: 1559	
BasicDataSource.createPoolableConnectionFactory(ConnectionFactory, KeyedObjectPoolFactory, AbandonedConfig) line: 1545	
BasicDataSource.createDataSource() line: 1388	
BasicDataSource.getConnection() line: 1044	

и

T4CConnection(PhysicalConnection).rollback() line: 1950	
PoolableConnection(DelegatingConnection).rollback() line: 368	
PoolableConnectionFactory.passivateObject(Object) line: 685	
GenericObjectPool.addObjectToPool(Object, boolean) line: 1379	
GenericObjectPool.returnObject(Object) line: 1342	
PoolableConnection.close() line: 90	
PoolingDataSource$PoolGuardConnectionWrapper.close() line: 191	

Т. обр., каждая успешная транзакция — это последовательность след. вида:

1. ROLLBACK
2. полезная работа с БД
3. COMMIT
4. ROLLBACK

(вместо единственного COMMIT'а), в то время как каждая неудачная — это:

1. ROLLBACK
2. полезная работа с БД
3. ROLLBACK
4. ROLLBACK

(вместо единственного ROLLBACK'а).

Вышеописанное поведение даёт дополнительную нагрузку на redo- и undo-подсистемы (что очень хорошо видно под нагрузкой в Oracle, но, на самом деле, при использовании commons-dbcp проблема универсальна — я наблюдал ровно то же самое для MySQL).

Вопрос 1: как избавиться от пресловутых ROLLBACK'ов, сохранив экземпляр DataSource сконфигурированным с defaultAutoCommit=false (т. е. без необходимости вручную вызывать setAutoCommit(false) для каждого соединения, взятого из пула)?

Вопрос 2: как можно обойти проблему средствами Oracle (т. е. без необходимости менять прикладной код или библиотеки)?

Долго пытался заставить GTK+ версии 3 выглядеть согласованно с темой Raleigh из GTK+ 2.0 (разработчики бросили её обновлять давным-давно, и в варианте по умолчанию она непригодна для использования), пока не наткнулся на вот эту годноту.

На снимке — meld, gedit и evince.

Не то, чтобы я стал активно переползать на третью версию с GTK+ 2.0 и Qt 5 (свят, свят), но теперь хотя бы не плююсь при её виде.

Плюсуйте проект на Гитхабе — автору темы наверняка будет приятно.

Ни один из штатных (во FreeBSD 11) драйверов для Realtek, похоже, не поддерживает RTL8821AE.

В результате, в качестве последнего средства, попробовал ndiswrapper.

Драйвера для WinNT 5.1 сконвертировались в ядрёный модуль без ошибок, в выводе утилиты nm вижу символы.

Модули ndis и if_ndis загружены.

Тем не менее, при загрузке полученного модуля в dmesg вижу следующее:

no match for RtlGUIDFromString
no match for ExNotifyCallback
no match for ExCreateCallback
no match for KeInitializeSemaphore
no match for KeReleaseSemaphore
no match for IoWMIQueryAllData
no match for IoWMIOpenBlock
no match for IoCsqInsertIrp
no match for IoCsqRemoveNextIrp
no match for IoCsqInitialize

— и новый сетевой интерфейс, ясное дело, не появляется.

Есть ещё какие-л шаги, которые можно предпринять, или плюнуть и поставить Linux?

Приветствую.

Есть античный пакет, в качестве системы сборки использующий imake.

Процесс установки выглядит как make install, но, в отличие от пакетов, использующих autotools, я не могу указать prefix, DESTDIR и вот это вот всё.

Пакет хочется «дебианизировать».

Вопрос: я правильно понимаю, что всю логику установки мне придётся вручную переносить из Imakefile в debian/rules с использованием множества команд debhelper (dh_*), или есть более простой способ?

checkinstall задействовать не хочется — как инструмент он очень ненадёжен.

Приветствую.

Пытаюсь освоить ${subj}.

Все примеры ([1], [2], [3]) прекрасно компилируются, но при просмотре dvi-выхлопа блоки на диаграмме отображаются, а все текстовые метки выводятся не внутри блоков, а строго в одной точке (друг поверх друга).

При преобразовании dvi2ps и скармливании результата движку gv диаграмма рисуется частично, текст не отображается вообще, в сообщениях следующее:

Error: /undefined in VResolution
Operand stack:
   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   0.12   72
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval-- GPL Ghostscript 9.20: Unrecoverable error, exit code 1
  --nostringval--   --nostringval--   false   1   %stopped_push   1999   1   3   %oparray_pop   1998   1   3   %oparray_pop   1982   1   3   %oparray_pop   1868   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1209/1684(ro)(G)--   --dict:1/20(G)--   --dict:87/200(L)--   --dict:171/300(L)--   --dict:58/200(L)--
Current allocation mode is local
Last OS error: Resource temporarily unavailable

В то же время pdflatex обрабатывает исходный .tex-файл без проблем, на выходе не диаграмма, а конфетка.

Вопрос: это такое хитрое ограничение TikZ, что он не работает с dvi-форматом?

Debian 9, texlive-full установлен.

Собственно, ${subj}.

При обновлении debian/changelog dch вставляет моё имя из /etc/passwd и генерит почтовый адрес как ${LOGNAME}@${HOSTNAME}.

Хочется поменять это поведение.

Сильно не бейте — я нуб, и Too Many Fucking Manuals to Read.

Была раньше такая технология (https://www.x.org/docs/XPRINT/Xprint_FAQ.html).

Насколько я понимаю, любой клиент мог воспользоваться принтерами, подключёнными к X-серверу (вплоть до печати просто содержимого окна), через вызовы клиентской библиотеки libXp.so и отдельный экземпляр X-сервера, отвечающий за собственно печать (Xprt).

Насколько я понимаю, CUPS, cairo и вот это вот всё — вещи сугубо клиентские.

А вот как нынче реализуется возможность вывода на локальный принтер удалённого X-клиента?

Возможно ли технически собрать Xprt из современного кода Xorg? Сохранились ли этот сервер и сопутствующие утилиты в портах *BSD (кастую iZEN)?

Вот, собственно, такой вопрос.

Несмотря на существование файла ~/.Xauthority и на явно выставленное окружение (XAUTHORITY=~/.Xauthority), X-сервер всегда стартует с аргументом -auth, указывающим на случайный файл в /tmp (см. заголовок).

Это, разумеется, если не переопределить иное (через ~/.xserverrc).

Вот скажите — вот нафига так? У меня же один и тот же файл спокойно может обслуживать несколько разных значений переменной DISPLAY.

Update: cast Zubok.

Приветствую.

После того, как в офисе выключилось электропитание, стал проверять файловые системы. И вот для 10 файлов e2fsck выдал пресловутое сообщение.

Запуск debugfs привёл к вот таким файлам:

# debugfs -R 'ncheck -c 125090 135942 146377 149354 149355 154279 155520 178619 179280 280807' /dev/mapper/unit--725--vg--bulk-public 
debugfs 1.43.4 (31-Jan-2017)
Inode   Pathname
125090  /distfiles/mozilla/seamonkey/seamonkey-2.49.1/obj-x86_64-pc-linux-gnu/dist/seamonkey/libxul.so
135942  /distfiles/mozilla/seamonkey/seamonkey-2.49.2.source.tar.xz
146377  /distfiles/mozilla/seamonkey/seamonkey-2.49.1.source.tar.xz
149354  /distfiles/mozilla/seamonkey/seamonkey-x86_64-pc-linux-gnu-gtk2+alsa-2.49.2.tar.bz2
149355  /distfiles/mozilla/seamonkey/seamonkey-2.46.source.tar.xz
154279  /Java/IDEA/ideaIU-2017.2.6-no-jdk.tar.gz
155520  /Java/JBoss/6.1/jboss-as-distribution-6.1.0.Final.zip
178619  /distfiles/mozilla/seamonkey/seamonkey-2.46/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
179280  /distfiles/mozilla/seamonkey/seamonkey-2.46/obj-x86_64-pc-linux-gnu/dist/seamonkey/libxul.so
280807  /Drivers/HP/LJM1120-Full-Solution.exe

Проверка архивов ошибок не выявила (а libxul.so — да и хрен бы с ним).

И вот тут у меня несколько вопросов.

• Файлы были записаны давно и долго не менялись, т. е. некорректная контрольная сумма с отключением питания, скорее всего, никак не связана. Раньше раздел проверки fsck успешно проходил. Как контрольная сумма могла «испортиться»?
• Сами данные оказались корректными (благо, это архивы и можно проверить). Возможно, контрольная сумма была изначально записана неверно. Но, опять же, как?
• О каких вообще контрольных суммах идёт речь, если, насколько мне известно, ext4 (в отличие от btrfs, zfs и hammer) использует таковые только для метаданных?

Собственно, сабж.

Имею два варианта AT&T ksh93 — один 93u+20120801-1 из Debian 8, другой 93u+20120801-3.1 из Debian 9.

Кодовая база, очевидно, почти одна и та же — основной код не меняется уже десятилетиями. В ChangeLog — 3 штуки NMU и всякая мелочь.

Было:

$ echo $((1./2))
0.5

Стало:

$ echo $((1./2))
ksh: 1./2: arithmetic syntax error

Теперь, похоже, единственный шелл, который по-прежнему умеет в FP без внешнего bc.exe — это zsh.

ЧЯДНТ?

Приветствую.

Как известно, есть магическая ANSI escape-последовательность (\e]0;строка\007), позволяющая динамически менять заголовок окна терминала (вернее, одновременно WM_NAME и WM_ICON_NAME, иначе 0 нужно заменить на 1 или 2).

Последовательность поддерживается подавляющим большинством эмуляторов терминалов, в т. ч. и XTerm.

А вот теперь, собственно, вопрос. У XTerm есть ресурс titleModes, описание которого гласит:

       titleModes (class TitleModes)
               Tells xterm whether to accept or return window- and icon-labels
               in ISO-8859-1 (the default) or UTF-8.  Either can be encoded in
               hexadecimal.  The default for this resource is “0”.

               Each bit (bit “0” is 1, bit “1” is 2, etc.)  corresponds to one
               of the parameters set by the title modes control sequence:

               0    Set window/icon labels using hexadecimal

               1    Query window/icon labels using hexadecimal

               2    Set window/icon labels using UTF-8 (overrides utf8Title
                    resource).

               3    Query window/icon labels using UTF-8

Странность состоит в том, что, если ресурс имеет значение 0 (0b00) или 2 (0b10), то всё работает корректно и совершенно идентично (в «не-юникодной локали», в соответствии с ICCCM, выставляются атомы WM_NAME(COMPOUND_TEXT) и WM_ICON_NAME(COMPOUND_TEXT), в «юникодной» же, в соответствии с EWMH, дополнительно к первым двум выставляются _NET_WM_NAME(UTF8_STRING) и _NET_WM_ICON_NAME(UTF8_STRING)).

А вот при значениях 1 (0b01) и 3 (0b11) всё одинаково не работает — escape-последовательность игнорируется (т. е. значение атомов не меняется).

Кто-нибудь может мне растолковать данный ман, а также как с ним коррелирует наблюдаемое поведение?

Спасибо.

16 февраля состоялся выпуск SeaMonkey 2.49.2.

SeaMonkey — это набор интегрированных сетевых приложений, включающий в себя браузер, почтовый клиент, RSS/Atom-агрегатор и WYSIWYG-редактор HTML-страниц. Выпуск 2.49.2 синхронизирован с кодовой базой Firefox 52.6 ESR и Thunderbird 52.6 ESR (см. соотв. примечания к выпуску по ссылкам).

( читать дальше... )

>>> Английская версия

Во времена mc 4.5-4.6 был в настройках редактора такой флаг как Key emulation, который можно было выставить в Emacs (F9 -> Options -> General). В файле настроек ~/.mc/ini этому соответствовало

[Midnight-Commander]
editor_key_emulation=1

Затем (кажется, в mc 4.7) флаг из UI убрали, но хотя бы оставили возможность написать в ~/.mc/ini

[Midnight-Commander]
keymap=mc.keymap.emacs

Теперь вот сижу на новомодном mc 4.8, в котором 100500 цветовых палитр, — и хрен. Emacs-эмуляция не работает, и непонятно, как включить.

WTF?!

Есть машина с Debian 9, и есть несколько машин с более ранними версиями (от Woody до Jessie).

Проблема в том, что у X-приложений, запущенных с локальной машины (Debian 9), я не могу запросить ресурсы утилитой editres. Проблема не в самой утилите editres из «девятки» — она прекрасно справляется с клиентами, запущенными с Debian 8 и использующих локальный X-сервер. Совершенно аналогично, editres из Debian 8 работает с клиентами, запущенными с Debian 8 (на локальном X-сервере) и не работает с программами из Debian 9.

Т. е., похоже, какая-то дрянь с клиентскими X-библиотеками (скорее всего, Xt). Но, странное дело, версии библиотеки на Debian 8 и Debian 9 одни и те же (вплоть до sha1-суммы):

$ dpkg-query -W libxt6
libxt6:amd64    1:1.1.5-1
libxt6:i386     1:1.1.5-1

Для сравнения, вот так выглядит editres, когда он «работает»:

https://habrastorage.org/webt/p7/me/qo/p7meqo3rmq98i9nitffrnjguwiy.png

А вот так — для локальных клиентов («Message sent to client asking for widget tree»):

https://habrastorage.org/webt/0h/fw/9_/0hfw9_ah44wknkqfwp6fui52eta.png

Чёрт побери, что они опять сломали в Debian 9?

P. S. Да, ещё важное дополнение. editres из «девятки», слинкованный с /usr/lib/x86_64-linux-gnu/libXaw.so.7, может «спросить» ресурсы сам у себя. Но вот у других клиентов, слинкованных с той же библиотекой (включая другой экземпляр такого же editres) — уже хрен.

Про SSL (и TLS) известно, что асимметричная (public-key) криптография используется лишь на этапе handshake — клиент подписывает публичным ключом сервера случайно сгенерированный (симметричный) ключ сессии, и, когда этот ключ безопасно передаётся на сервер, то уже в полный рост идёт шифрование данных каким-нибудь AES256 или, прости господи, 3DES.

Это легко проверить:

$ curl -iv https://linux.org.ru 2>&1 | grep AES
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
$ openssl s_client -connect linux.org.ru:443 -prexit 2>&1 | grep -Ei '(aes|3des|fish)'
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

Ровно так же работает и PGP — сообщение шифруется «ключом сессии», а сам ключ сессии шифруется публичным ключом адресата и отправляется вместе с письмом.

Читаю документацию по SSH — и не нахожу ничего подобного, хотя симметричные шифры (AES, 3DES, ARCFOUR, twofish, serpent, blowfish) вроде упоминаются.

В выводе ssh -v тоже ничего, что напоминало бы о симметричных шифрах:

debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:...
debug1: Host '...' is known and matches the ECDSA host key.
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: Offering RSA public key: ...
debug1: Server accepts key: pkalg ssh-rsa blen 535

Вопрос: использует ли SSH симметричную криптографию, или же всё время идёт шифрование с публичным ключом?

Приветствую.

Полез давеча посмотреть на сертификаты серверов в SeaMonkey — и увидел 9 штук в Builtin Object Token. Я их поудалял, но они продолжают «висеть» во вкладке «Others»:

https://habrastorage.org/webt/xa/2q/is/xa2qisg6arve5xwmc6tmpcmwrqw.png

Сертификаты просроченные (срок действия истёк в 2014, пример для addons.mozilla.org):

https://habrastorage.org/webt/5f/ry/ox/5fryoxyqavfrl6hcibhnsbzjxuw.png

и, естественно, не отличаются от текущих SSL-сертификатов соотв. сайтов:

https://habrastorage.org/webt/rs/rq/we/rsrqwev0r-wnaujxrpacyf-s0s4.png

Версия SeaMonkey достаточно свежая — 2.46, выпущена в декабре 2016 (кстати, недавняя 2.49.1 ведёт себя так же). В (пустом) заново созданном профиле вижу ровно то же самое:

https://habrastorage.org/webt/5d/ay/ch/5daychmswvrkawglzjk68bp7vfa.png

Вопрос: на кой чёрт браузеру поставлять просроченные сертификаты?