fox :: echo/0pTTcdzgAwBbcd8ToSAV

Re: g2k14: Marc Espie on ports and packages

zhuk@ — 2014-08-04 20:22:17

zhuk@ -> 51t

> а чтобы любой адрес *.ipv6.51t.ru работал? чтобы я мог все сервисы и на 51t.ru и на ipv6.51t.ru вешать

done

Re: g2k14: Marc Espie on ports and packages

51t — 2014-08-04 20:14:43

51t -> zhuk@

а чтобы любой адрес *.ipv6.51t.ru работал? чтобы я мог все сервисы и на 51t.ru и на ipv6.51t.ru вешать, одни для ipv4, другие для ipv6 (кстать, уже нашёл и исправил косяк регистрации при работе ipv6).

Re: g2k14: Marc Espie on ports and packages

zhuk@ — 2014-08-04 20:04:12

zhuk@ -> 51t

Ну вот как-то так уже работает:

$ host -t ANY ipv6.51t.ru 127.0.0.1  
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

ipv6.51t.ru has SOA record ns1.ohvost.ru. mail.51t.ru. 2014080402 28800 7200 864000 86400
ipv6.51t.ru name server ns1.ohvost.ru.
ipv6.51t.ru has IPv6 address 2a01:7c8:aab0:4af::5

Re: черновик от тэо

zhuk@ — 2014-08-04 19:55:42

zhuk@ -> 51t

(попробовал перевести сам... вроде, терпимо, но надо будет ещё раз вычитать)

g2k14: Theo de Raadt: безопасность и конфигурашность

Лидер проекта OpenBSD Тео де Раадт (deraadt@) пишет об g2k14:

Две недели перед Словенией я работал с Бобом Беком (Bob Beck) над заменяющими getentropy(2) функциями. В начале хакафона были внесены последние штрихи, нужные Бобу и Бренту Куку (Brent Cook) для дальнейшей работы.

Затем пришло время разбираться с очередной проблемой безопасности, о которой мне стало известно. К нашему прискорбию выяснилось, что исчерпание ограничения на количество одновременно открытых файлов может быть использовано для сокрытия уведомлений о переполнении стека от соответствующего механизма защиты. Защитнику стека требуется файловый дескриптор, чтобы сообщить об ошибке. Те, кто уже читал заметки об arc4random и getentropy, уже в курсе данной ситуации.(*)

Проблема стала очевидной из-за технологии "песочницы", используемой ныне в SSH-утилитах, которая закрыла syslog_r() доступ к socket(), connect(), sendto()... всем системным вызовам, необходимым для сообщения об ошибке, но потенциально опасным - что как раз "песочница" и должна предотвращать.

Задача была решена путём создания нового системного вызова, который может отправить сообщение в syslogd без использования лишних ресурсов; syslog_r(3) теперь использует его напрямую: один щелчок, выстрел, поехали дальше. Данный системный вызов имеет более чем узкое применение, и поэтому был назван sendsyslog(2), и при этом он также подходит для специфических условий, таких как использование "песочницы".

В этом плане, ситуация схожа с тем, как getentropy(2) была вынесена из sysctl. Забавно, как одно приводит к другому.

В качестве передышки от пространства ядра, пришла пора для небольшой уборки и, надеюсь, улучшения в /etc, sysmerge и инструментах установки. Роберт и Антуан помогли спланировать практически пустой /etc/rc, эта работа ещё не окончена, но приведёт к улучшенному sysmerge. На других фронтах я работал с теми, кто занимается установочными скриптами и DRM, чтобы в нашем следующем релизе можно было автоматически по возможности прикрывать прямой доступ к оборудованию для X на поддерживаемых в этом плане чипсетах [по сути это современные Intel - прим. ред.].

В остальное время хакафона я мелькал тут и там, как обычно, участвуя в проектах других разработчиков. Очень приятная и производительная неделя!

> * Речь об исчерпании лимита на количество открытых файлов, которое в случае использования syslog(3) могло привести к тому, что сообщения об ошибках не попадут в системный журнал. Дело в том, что syslog(3) оперировал через открытие файла /dev/log, которое, в случае исчерпания оных лимитов, становится невозможным.

Re: g2k14: Marc Espie on ports and packages

51t — 2014-08-04 19:26:18

51t -> zhuk@

> Эм. Пока у тебя есть запись вида "*.51t.ru. IN A 149.210.140.35", я ничего не смогу сделать... Если только я не тупой, и трюк вида "ipv6.51t.ru является отдельной зоной" каким-то волшебным образом не сработает.

ну сделай сейчас ресолв ipv6.51t.ru :) я прописал туда левые NS-записи, и A-запись уже не срабатывает :)

Re: g2k14: Marc Espie on ports and packages

zhuk@ — 2014-08-04 19:24:08

zhuk@ -> 51t

> ты можешь сделать DNS, чтобы на любой адрес ipv6.51t.ru отдавала ipv6-адрес и только его? я ns пропишу.

Эм. Пока у тебя есть запись вида "*.51t.ru. IN A 149.210.140.35", я ничего не смогу сделать... Если только я не тупой, и трюк вида "ipv6.51t.ru является отдельной зоной" каким-то волшебным образом не сработает.

> допереведи два предложения от тео

Ой, а я так и не отправил, значит... Ща.

Re: g2k14: Marc Espie on ports and packages

51t — 2014-08-04 06:04:36

51t -> zhuk@

в ii когда-то была вики :) http://r.51t.ru/wiki.14

ещё у меня было две самописных. но вики, это ссылки, которые надо прокликивать. а никто не прокликивает :) а если ещё и два уровня иерархи...

а у ленты топовые сообщения всем видны, и если ими постоянно маячить :) поэтому можно хоть словарь, хоть что угодно, писать в виде предложений - потом это всё можно собрать.

а так... вики, которая позволяет экспортировать сообщение из ii, затем издеваться над ним, а затем обратно импортировать - это было бы интересно :)

ps. ты можешь сделать DNS, чтобы на любой адрес ipv6.51t.ru отдавала ipv6-адрес и только его? я ns пропишу.

ps2. допереведи два предложения от тео :) остальные статьи я тисну так :)

Re: g2k14: Marc Espie on ports and packages

zhuk@ — 2014-08-04 00:49:08

zhuk@ -> 51t

> ну, сделай вики, если тебе так удобнее

Ты знал, ты знал! Пошёл я искать вики-систему, написанную по-человечески... и не нашёл. :( Избаловался, что ли... Хоть сам пиши. Ну или идти к ii прикручивать функционал. :)

Re: дошли

51t — 2014-08-03 20:40:02

51t -> zhuk@

логично, ведь это точка для клиента, а не для юзера :)

http://off.51t.ru/u/e/off.gatter.14

http://off.51t.ru/u/m/WkifCDi5oOs5zwmzybAL

http://off.51t.ru/m/WkifCDi5oOs5zwmzybAL

Re: дошли

zhuk@ — 2014-08-03 20:35:40

zhuk@ -> 51t

> Просто берите свой любимый ii-клиент, прописывайте адрес http://off.51t.ru/u/, выбирайте интересные эхи, загружайте и читайте.

http://off.51t.ru/u/ выдаёт 404. :((

дошли

51t — 2014-08-03 19:50:26

51t -> 51t

http://off.51t.ru

Re: g2k14: Marc Espie on ports and packages

51t — 2014-08-03 19:26:41

51t -> zhuk@

> А как _я_ в него что-то добавлю? Вот встретил я какой-то неоднозначный термин, хочу добавить свой перевод - а как? Неудобняк-с.

ща на примере офлайнизатора покажу, только руки до него не дошли... там просто отдельная эха в боковой панели транслируется :)

Re: g2k14: Marc Espie on ports and packages

51t — 2014-08-03 19:25:43

51t -> zhuk@

ну, сделай вики, если тебе так удобнее... :) мне удобнее лента, когда тут всё потоком идёт, и не надо по страницам скакать туда-сюда. главное, чтобы тексты перевести, а кому как удобно - это дело десятое :)

Re: g2k14: Marc Espie on ports and packages

zhuk@ — 2014-08-03 19:23:19

zhuk@ -> 51t

> я тебе и в веб-интерфейсе эхи могу выложить сбоку отдельный словарик. :)

А как _я_ в него что-то добавлю? Вот встретил я какой-то неоднозначный термин, хочу добавить свой перевод - а как? Неудобняк-с.

> и любые записи вести :)

А править их? В вики можно хоть по абзацу переводить, без лишних движений: открыл текст, поправил, сохранил. Перечитал, захотел исправить косяк - снова то же самое (скажем, в только что отправленном переводе отчёта Марка Эспи я у себя же насчитал как минимум крупных косяка). Ну и история тоже лишней не бывает, особенно при массовых правках (заменах терминов, скажем).

Re: g2k14: Marc Espie on ports and packages

51t — 2014-08-03 19:03:11

51t -> guest

я тебе и в веб-интерфейсе эхи могу выложить сбоку отдельный словарик. :)

и любые записи вести :)

Re: g2k14: Marc Espie on ports and packages

guest — 2014-08-03 18:59:41

guest -> 51t

> не вижу особой разницы с вики. в вики они обычно лежат мёртвым грузом и никто не шевелится. :)

В вики есть средства организации одновременной работы, тот же MediaWiki умеет предупреждать об одновременном редактировании. Плюс рядом можно класть тот же словарик - который в вики может пополняться не одним человеком (который может уехать, заболеть, помереть или просто не иметь времени). Вот обсуждения и новости в вики выглядят по-идиотски, согласен.

> меня вот больше Тео беспокоит - там три предложения, которые уже неделю не переведены, потому что не могу их сути постичь :(

... и никто не шевелится. ;) Сейчас гляну.

Re: g2k14: Martin Pelikan on ext4, filesystems in general

51t — 2014-08-03 17:44:30

51t -> vit01

Мартин Пеликан пишет в отчёте с g2k14:

Мой первоначальный план состоял в том, чтобы в нашей base мог собираться libcpp из LLVM, дав нам поддержку C++11. После того, как я читал о последних дополнениях локалей POSIX, другие разработчики прояснили, что будет нужно больше вариантов версии библиотеки, чтобы не сломать порты. После того, как первый diff был готов, я поднял сборку базовой системы, чтобы проверить, сломается ли она. И затем моя жизнь изменилась...

За несколько дней до хакатона я решил поставить на свой ноутбук Linux, Windows и OpenBSD рядом друг за другом. Одна из связанных с локалями статей была оставлена на разделе с Линуксом, и я хотел открыть её в Австрии, которая просто полна тоннелей без интернета. Наше ядро не любит ext4; будучи слишком ленивым для перезагрузки, я решил "пришло то самое время", чтобы выяснить, почему.

Неудивительно. ext4 использует extents, которые в былые времена не поддерживались. Беглый взгляд на FreeBSD показал, что у них уже есть read-only поддержка, которая стала более-менее функциональной на моём ядре OpenBSD в среду вечером. Нет индексов каталога HTree, нет 64-битных номеров блоков, нет журналов или снапшотов, или защиты от мульти-монтирования. Но я мог наконец прочитать PDF без перезагрузки и затем даже скопировать файл, больше, чем 4 ГБ, или открыть каталог с 50 000 подкаталогов в нём. Никогда прежде не видя исходников файловой системы, я смог сделать рабочий порт за несколько часов? Жизнь прекрасна!

Теперь вопрос состоял в том, как это интегрировать. Разработчики OpenBSD не любят гигантские diffы, и на это есть серьёзное основание. После починки формата inode и добавления новых флагов, Тед указал на древнее правило "кто последний полез в эту часть - тот теперь её мейнтейнер". Было очевидно, что я должен был получить больше знаний, читая тексты дизайна и код других систем, прежде чем смогу делать ценные и правильные коммиты. Устаревшие остатки, похожие на трудно (и неправильно) закодированный лимит размеров файлов были первыми. Части кода понимались с трудом, но FreeBSD удалось их разделить, так или иначе. После этого наши пути кода выглядели достаточно похожими, и поддержка ext4 ворвалась в нашу жизнь.

Несмотря на то, что цель хакафона была в написании кода, я должен был буквально учиться работать с подсистемой, которую я видел до этого только однажды и мельком (c FUSE). Поскольку всё это уже было во FreeBSD, и заставить это работать было так просто, это было очень хорошее место, чтобы научиться писать код файловой системы самому. В течение следующих дней я начал с того, что написал парсинг и чтение журнала, а закончил тем, что сидел и сознательно ломал мою файловую систему, и смотрел, как она будет восстанавливаться и что для этого нужно ещё сделать. В общем, это верный путь, и цель - сделать поддержку записи.

Это было бы невозможно без Филипа Гуентэра, который рассмотрел мои diff-ы после того, как я продолжал отвлекать его от более важных дел. Тед, Тео, Кен и Боб дали мне много ценного и объяснили, как вещи должны работать. Стефан Сперлинг дал мне доступ к одной из его машин sparc64 и с удовольствием держал дерево актуальным, таким образом, мои поломки были относительно небольшими и незначительными. Обсуждения о сетевом стеке помогли сузить наш фокус в направлении и по поводу других решений. Митя занимался организацией встречи, чтобы дела шли так, как им и должно идти. Каждый всё сделал отлично, спасибо!

Будем надеяться, что этот энтузиазм насчёт файловой системы сохранится, потому что теперь я должен переключиться назад на GSoC (Google Summer of Code) - в задачи, которые мне знакомы. Надеюсь, что файловая система, сломанная у меня сейчас, когда-нибудь поможет починить вашу... [эти слова оказались пророческими, и после этого мы с Мартином вели обширную переписку о поломках. прим. ред.]

Re: g2k14: Marc Espie on ports and packages

51t — 2014-08-03 17:27:21

51t -> guest

> всё-таки вики для такой работы удобнее - не в обиду; и ещё нужно словарик составить терминов для единого стиля...

не вижу особой разницы с вики. в вики они обычно лежат мёртвым грузом и никто не шевелится. :)

по словарику - поскольку я выпускающий редактор :), я и поправляю окончательно термины. не знаю, что там коряво, а в целом, текст нормальный.

меня вот больше Тео беспокоит - там три предложения, которые уже неделю не переведены, потому что не могу их сути постичь :(

Re: g2k14: Marc Espie on ports and packages

guest — 2014-08-03 17:15:59

guest -> vit01

(всё-таки вики для такой работы удобнее - не в обиду; и ещё нужно словарик составить терминов для единого стиля... Да, я не помню свой новый пароль от почты и поэтому не помню и auth-ключ - zhuk)

Ещё один отчёт с завершившегося недавно хакатона g2k14, от Марка Эспи:

В Словении я был в первый раз. За несколько часов - к счастью, удалось избежать гроз - осмотрел столицу. Очень интересное соединение никогда не видел подобного сочетания восточной Европы, южной Европы и туристических мест (КОРЯВО).

Что до самого хакатона, я прибыл на него вскоре после крупного изменения (переупорядоченные пакеты), и был практически готов исправлять проблемы в случае необходимости. К моему удивлению, всё работало как часы... Если я что-то и сломал, то никто этого не заметил; зато всем должно понравиться ускорение процесса обновления пакетов.

После продолжительного подпинывания, Вадим Жуков таки закоммитил digikam-kde4 [порт Digikam для KDE4, - В.Ж.]. Я провёл креш-сборку и информировал его о найденных проблемах, которые он быстро исправил.

Я работал над немногочисленными мелочами... столкнулся же со многими, и исправил чуть меньше после обычного слома дерева портов, связанного с нашими бесстрашными ломателями исходников (в основном негативные последствия были из-за libressl, endian.h и обновления mesa).

Я работал над новым механизмом, обеспечивающим лучшую целостность репозиториев пакетов. Пакет "quirks" теперь сообщает о дате своего подписывания (которая в свою очередь проверяется, поэтому подделать её не получится), благодаря чему теперь можно знать, что срез пакетов достаточно свеж, или же что кто-то помешал ему попасть на ваше любимое зеркало...

... а ещё пакет "quirks" содержит в себе список уязвимых версий пакетов, благодаря чему вы получите сигнал опасности, если вам требуется обновиться из-за уязвимости в старой версии и при этом новой версии пакета на зеркале нет.

Всё это лишь уведомляет пользователя, так как срезы пакетов требуют определённого времени для расползания по зеркалам... У нас есть идеи, как побороть ЭТУ проблему, но после обсуждения с вовлечёнными сторонами было принято решение отложить внедрение до следующего релиза в связи с необходимостью чересчур серьёзных переделок.

Я также пытался решить проблему с необходимостью наличия исходных текстовой базовой ОС для сборки пакета "pkglocatedb". К моему большому удивлению, Тео согласился, и мы зашли даже дальше, чем изначально планировалось, благодаря чему снапшоты теперь будут включать locate-базы как для базовой системы, так И для иксов.

Я провёл немало времени, играя с этими базами: теперь и pkg_check использует их, позволяя проверить систему полностью. По-прежнему слишком много лишних сообщений, но прогресс налицо.

Также я провёл немало времени за вычисткой устаревшего кода. Оно не так привлекательно, но, является, пожалуй, важнейшей частью процесса, так как при этом достигается уверенность в том, что мы не запускаем более не нужный и не поддерживаемый код...

Ещё я должен упомянуть о отдельном cpp [препроцессоре C - прим. ред.] для calendar и xrdb, теперь иксы не потребуют для своей работы установки базового набора comp.

Как обычно, встречаться лицом к лицу собратьев по разработке очень помогло некоторым проектам продвинуться вперёд.

Спасибо [OpenBSD] Foundation за спонсирование этого мероприятия, а также Мите за место, всё было организовано настолько хорошо, что нам даже не приходилось о чём-то задумываться.

ORIG: g2k14: Andrew Fresh on Programming Perl

51t — 2014-07-31 08:01:07

51t -> All

This was my first hackathon so I wasn't really sure what to do. I had some plans to possibly import perl 5.20, but I was hoping to include 5.20.1 which isn't out for at least a month and espie@ says that it is too close to lock. I will continue to push local patches upstream to get everyone using perl on OpenBSD to be using the same improvements that are in our base perl.

I was sure some project would present itself that I really wanted to work on, so I started out by slacking and working on the tool I've been playing with to make generating ports for things that keep track of their dependencies and have automated installers, such as things from perl's CPAN or Node's NPM Perl support is pretty good, but both Python and Nodejs, while started have run into roadblocks due to the different ways they handle dependencies. Talked some to abeiber@ about how to solve the nodejs problem and it sounds like someone will have to end up patching npm to add support for features we need, mostly the ability to install dependencies offline. Still not sure how to ask python packages for a list of their dependencies so automating that has ground to a halt.

During the time I was avoiding reading npm source or better understanding Python's different package systems, I got the last few dependencies updated so that I can update DBIx::Class to the current version. I actually submitted that update, but zhuk@ mentioned that he has examples of how to start up local database instances with their datafiles inside of the port's ${WRKDIR} so that I can run "live" tests automatically. That sounds like a great feature so I will figure out how to accomplish that and update the port before re-submitting.

I did submit a few bugs to perl upstream while at the hackathon, reporting an issue that ended up being unsolvable due to the way perl buffers output and also adding configure glue and other things for pelikan@'s POSIX international currency formatting additions. I need to do a little cleanup on it, but that should go in soon.

Eventually, there was discussion about why there are adduser, useradd, and "user add" commands and how terrible they were. There was a suggestion to get rid of the perl based adduser, but many people prefer the interactive interface because they add users so infrequently that the additional prompting is super helpful. Unfortunately, I fell for their trick and looked inside the file. I am now working on rewriting adduser with some more modern perl style, I got started on that on Friday evening and got about half way through an initial rewrite by Sunday night. The current design I am looking at is providing a module to do the heavy lifting so that people scripting system management tools (in perl) can talk to a better API than forking out and driving one of the existing scripts. I hope to make it easy to write your own tools to manage users safely and programmatically, while also providing a tool with a friendly, interactive frontend that is also easy to drive from a shell script.

Ljubljana is beautiful, the people were amazing and so much good, vegan food. Plus the weather was overcast, all of which kept me from getting too homesick for Portland, OR. I really enjoyed how friendly and welcoming all of the people we met there were and how well we worked around the surprisingly few language barriers.

As this was my first time in Europe, I left the hackathon on Monday morning and took a shuttle to Venice as recommended. The recommendations were always "Venice? Don't go there, it's so touristy! Oh, you've never been? You should go and see it at least once." So Lisa and I went and added to the number of tourists. We have learned that we really enjoy traveling the world and I am greatly looking forward to the next hackathon for an excuse to finally see more of the world. It did make me want to improve the number of human languages I can do basic things in.

I too need to be sure to mention what a good job Mitja did organizing the hackathon, many, many thanks to him and to Dijaski dom Tabor.

ORIG: Ted Unangst on the Art of the Tedu

51t — 2014-07-31 08:00:28

51t -> All

Ted Unangst (tedu@) talks about teduing a goodly amount of code, among other things:

Despite being in the same room as many other LibreSSL developers for the first time (since the beginning of LibreSSL at least), I didn't do too much work on that front. I did remove the compression feature (as made famous by the CRIME attack; not all protocols or deployments are vulnerable, but we're also aiming for a simpler feature set overall) and made a few other cleanups. While it's very helpful to be in the same room as other hackers to exchange ideas, having everyone pounding on the source at the same time is a little troublesome so I elected to stay out of the way.

I did, however, take the chance to bounce some ideas for a ressl API off the other developers. Instead of continuing to use the OpenSSL API, the ressl API is entirely separate. Internally, ressl itself uses the OpenSSL API, but the interface presented to the user is quite different. Our particular focus is on absolving the user of the need to know about X.509 and ASN.1 internals; instead you simply ask ressl to verify the remote peer's hostame. And actually, you don't even need to do that because that's the default behavior. (Un)fortunately, jsing@ liked the idea so much he ran ahead and implemented it before I got the chance. One of the dangers of being at a hackathon, I guess.

Besides that, I continued my hackathon tradition of deleting a lot code that most people probably never even knew existed. Say goodbye to asa, fpr, mkstr, xstr, oldrdist, fsplit, uyap, and bluetooth. Of these, you may possibly miss bluetooth support. Unfortunately, the current code doesn't work and isn't structured properly to encourage much future development.

I reviewed a few filesystem diffs from pelikan@ for ext2fs and tobias@ for msdosfs. At the beginning of the hackathon I showed some developers a diff that changes the buffer cache to using a 2Q like strategy. That's gone through a few iterations, but won't make 5.6. Expect to see it soon, though.

I made two changes to the kernel malloc(). The first was an idea deraadt@ had suggested some time ago. The current poison values (designed to detect use after free and other corruption) are rather limited, meaning that if a particular flag bit is set or unset, the incorrect code may continue to function. I change the poison values to inverted patterns, reversing all the bits. This proved to be very successful, finding many more bugs. Too successful, in fact, because there's not enough time to chase down and fix all the fallout before release, so that change has since been reverted.

The second change was to add a size argument to free(9). This is currently not used, as most callers pass 0 to indicate unknown, but will allow us to simplify some code on the free side and make some other fun changes as well.

For userland malloc(3), I did some work to accelerate threaded applications. I now have a stable first version of this ready, but it will wait for the next release as well.

Re: он сказал openxcom!! :)

vit01 — 2014-07-28 09:36:16

vit01 -> 51t

g2k14: Jonathan Gray on driver improvements for X

Джонатан Грэй (jsg@) сообщил нам, почему он провёл 30 часов в автобусе, чтобы быть с нами:

Одной из первых вещей, которые я сделал в g2k14, был импорт обновления Mesa, над которым я теперь работал в течении некоторого времени. Я следил за git репозиторием Mesa несколько месяцев и отправлял патчи, чтобы уменьшить всю ту боль, причинённую локальным diffом, который не был таким большим, но приходилось тратить много времени на обновления.

Незадолго до хакатона я столкнулся с проблемой, заставляя Mesa собираться на i386, как бы то ни было. Это происходит только в том куске кода, который с помощью sysctl проверяет, включен ли SSE. Это, как оказалось, было проблемой, потому что sysctl.h включает в себя utm_extern.h, который, в свою очередь, берёт заголовочные файлы ядра, включая mutex.h, это означает, что mtx_init() из Mesa конфликтует с mtx_init() ядра. Тео потратил немного времени, вычищая sysctl и заголовки utm, таким образом, они не будут включать где-либо много определений. Эту работу уже закоммитили, когда я пришёл на хакатон.

На следующий день я сделал немного сборок xenocara, чтобы найти любые дополнительные проблемы. Проблема, которую я нашёл, происходила из-за симлинка в файл дистрибутива Mesa, который игнорировался cvs import, что починили ссылками из Make-файлов в другую директорию. Я также проверил дважды работоспособность сборок Mesa со включенным LLVM, который всё ещё работал через программный рендеринг LLVMpipe.

Другая проблема со сборками Mesa заключалась в том, что sys.mk, автоматически включаемый через make в Makefile, добавляет CFLAGS к CXXFLAGS. Поскольку Mesa является смесью C, которая включает и код C99, с C++, g++ ругался на то, что к нему попадал C-специфичный флаг -std=c99. diff, который исправляет это в системных Make-файлах и некоторых других местах, будет потом отправлен по почте.

Я также проконтролировал, чтобы дерево исходников собиралось с OPENSSL_NO_DEPRECATED, который в большинстве случаев добавлял инклюды, которые больше автоматически не брались из других инклюдов. Для некоторых вещей, таких как nginx, которые поддерживаются извне, есть патчи, которые уже доступны в следующих версиях. Мы их потом возьмём, но пока что ещё не так уж и стоит патчить нашу версию, когда есть другие места в дереве (libkeynote/bind/sendmail и.т.д.), где требуется сделать изменения. Я также вскользь посмотрел на компиляцию с OPENSSL_NO_SSL_INTERN, но после того, как увидел, что dc и gzsig поломались во время сборки, я решил посмотреть в другие места.

Я посмотрел на обновление некоторых патчей clang, которые искал пару лет, и коммитил некоторые вещи, касающиеся этого.

Xorg теперь может работать без необходимости предоставлять прямой доступ из пространства пользователя к памяти ядра/устройства, если режим modesetting (KMS) ядра поддерживается. Проблема ещё заставляет некоторые устройства требовать доступ к этому окну памяти, чтобы запустился Xorg. Установщик задаёт вопрос, если находит vga устройство, которое включает окно через machdep.allowaperture sysctl. После обсуждения с парой людей на g2k14 я написал небольшие скрипты, чтобы забирать номера поставщика/продукта PCI из драйверов radeondrm и inteldrm, которые используются pci вложением в vga драйвер, чтобы написать строчку в dmesg, если это окно памяти требуется для запуска Xorg. Установщик был изменён halex@ и rpe@, чтобы проверить эту строку и теперь будет только спрашивать, нужно ли человеку запускать X11 (который включает окно), если оно найдено. Вопрос X11 не будет задан теперь на многих серверах, так как есть чёрный список серверных графических устройств в коде, решающем, нужен ли aperture.

Проблема, с которой я столкнулся теперь несколько раз, - это недостаток заголовка cpuid.h, который идёт из gcc >= 4.3 и clang, чтобы обеспечить интерфейс, запрашивающий cpuid на i386 и amd64. Mesa из git теперь требует cpuid.h для сборки. Intel-овский драйвер Xorg отключает код, включённый в решение, если SSE присутствует, и делает решения, основанные на размерах кэша, если его нет. И, по крайней мере, некоторые порты (т.е. OpenXCOM), кажется, теперь его ждут. Таким образом, я взял cpuid.h из clang, чтобы включить его в нашу версию GCC 4.2.1. Сначала я изменил определения SSE_4_1 и SSE_4_2 на SSE_41 и SSE42, чтобы соответствовать именам, используемым в GCC, но, вероятно, они оба будут включены, когда это закоммитят.

Большое спасибо OpenBSD Foundation и Мите за g2k14!

черновик от тэо

51t — 2014-07-26 14:30:23

51t -> All

Re: g2k14: Theo de Raadt: безопасность и конфигурашность

Лидер проекта OpenBSD Тео де Раадт (deraadt@) пишет об g2k14:

Две недели до Словении я работал с Бобом Беком над заменой функциям, которые потребуются для эмуляции getentropy(2). С начала хакафона пошёл окончательный этап работы, чтобы гарантировать, что у Боба и Брента Кука - всё путём.

Затем пришло время конкретно разобраться с одним вопросом касаемо безопасности, о котором я узнал. Истощение дескрипторов может использоваться для сокрытия отчётов о переполнении буфера через stack protector. Охрана stack protector требует файловый дескриптор для того, чтобы сообщить об ошибке. Кто-то из тех, кто подписан на блоги по arc4random и getentropy понимают, в чём проблема. *

Эта проблема была сделана очевидной из-за метода песочницы systrace, используемого теперь в ssh инструментах. который препятствует тому, чтобы syslog_r открывал сокет, соединялся, отправлял.. хорошие системные вызовы для того, чтобы сообщить о неудачах, но, однако, опасные - и точно те, что песочница пытается предотвратить.

Проблема была решена созданием нового системного вызова, который может отправлять сообщения для syslogd, вообще не используя никаких дополнительных ресурсов: syslog_r(3) может это делать напрямую, как по взмаху волшебной палочки. Системный вызов довольно узкоцелевой, поэтому назван sendsyslog(2), but this also fits the narrow use case it will have such as sandboxing.

Это подобно пути getentropy(2), который вырезали из sysctl. Забавно, как одна вещь приводит к другой.

Отдохнув от ядрёной части, самое время взяться за очистку и улучшение для /etc, sysmerge и скриптов установки. Роберт и Антошка помогли нам с планом конкретной зачистки /etc/rc, но это дело ещё не завершено. Оно приведёт к улучшениям в работе sysmerge. Также я работал с пацанами и из отдела инсталляционного скриптования и из отдела DRM, для того, чтобы установщик мог автоматически выставлять aperture.

В остаток хакафона я мелькал тут и там, как обычно, участвуя в проектах других разработчиков. Очень приятная и производительная неделя!

> * Речь об исчерпании лимита на количество открытых файлов, которое в случае использования syslog(3) могло привести к тому, что сообщения об ошибках не попадут в системный журнал. Дело в том, что syslog(3) оперировал через открытие файла /dev/log, которое, в случае исчерпания оных лимитов, становится невозможным.

ORIG: g2k14: Landry Breuil on Taming Mozilla

51t — 2014-07-25 20:59:46

51t -> All

As is now an habit, i had made zero plans for this hackathon, i had some unfinished stuff lying around, and no real big task ahead. Firefox 31 betas were already working for me, and only needed actual testing.

In the end, i spent quite a bunch of time doing some sysadmin stuff with ansible, with which i've really felt in love. Thanks to rpe@, we have a really up-to-date port, and it was the perfect occasion for me to reconfigure some of my infrastructure servers, starting by our test bulk cluster OPI - which can be now fully upgraded/reconfigured in a single ansible playbook task, taking care of all the steps to be able to run a bulk build. This will soon be featured in an article in a french newspaper issue about BSD systems. I'll really stress that ansible can be the perfect tool to remotely administer OpenBSD systems, only needing ssh and python on the remote machine, and the learning curve of the tool is really smooth.

I also spent some time digging in various pkg_tools/pkg_locatedb/pkg_check/sqlports/pkg_sign usecases, more material for another article in the same newspaper - along this, i had lots of questions for espie@, who still thinks his code is easy to understand to outsiders.. unfortunately, not everyone is as smart as him.

A hackathon wouldnt be one without some activity in mozilla's bugzilla, so i resumed pushing some patches that were still local and pending to reduce our count of local modifications - unfortunately, some last minute changes to our headers (read: endian.h) brought more patches to all our mozilla ports, and ruined my efforts :)

I tried porting the new mozilla sync server, since the one we have in-tree will stop working with gecko 31. Unfortunately, after 15 new ports of some python libs, and realizing i'd also need to port around a bazillions of node js modules, i totally gave up on this. I doubt this'll improve in the future, the new sync server is not really designed to be properly packaged, rather ran directly from a one-shot checkout of its sources.

I also did some minor wip update to the www/nginx port, adding the ldap auth patch, polished ports for a pair of GIS caching servers i plan to use at work (mapcache, and mapproxy) but that work is still awaiting feedback and review.

As Vadim said, i spent quite a bunch of time proofreading lots of new ports needed for kde4 updates, fixing nits around and commenting on style issues - but since he's now an experienced porter, i didnt have much to add... and finally, i reviewed the work of our GSOC student about systemd-like daemons, to allow us to have equivalent features provided via D-BUS (those are more and more needed by gnome), and the architecture is shaping up quite nicely - we had quite some interesting exchange with him and ajacoutot@. I think that's material for a standalone undeadly issue, i'll let ian talk about it :)

Thanks again to mitja and his crew, again a perfect event in a really nice city!

черновик от матфея

51t — 2014-07-25 20:51:25

51t -> All

Матье "бешеный француз" Херб (matthieu@), поддерживающий Xenocara, хочет поделиться своими впечатлениями о g2k14:

Я так и ничего и не сделал по моим остальным проектам (мультитач, DHCPv6), поскольку был отвлечен на твики наборов для X, по просьбе нескольких других участников. After much discussion this only led to the addition of ucpp in base (after a short detour by /usr/xenocara/app/xrdb-cpp) as /usr/libexec/auxcpp.

Причина в том, что xdrb (часть необходимой многим портам xbase) требует препроцессор C для запуска. Но, начиная с gcc4, /usr/bin/cpp находится в наборе comp, потому что это просто часть gcc. Получается, набор xbase требует установленного набора comp.

Есть два типа людей, которых это раздражает: люди с маленькими дисками, и люди с фобией "компилятор на сервере? непостижимо!" (хотя эти люди правы: http://www.welivesecurity.com/2014/03/18/operation-windigo-the-vivisection-of-a-large-linux-server-side-credential-stealing-malware-campaign/)

Поэтому теперь auxcpp стал частю набора base. Прощай, зависимость xbase от comp. The X sets will stay in their current state for 5.6. Otherwise, I've done a few updates on xenocara components. Дерево xenocara практически готово для 5.6.

Но всё равно, мне понравился хакафон. Спасибо Мите и его команде за организацию, и всем благодетелям за пожертвования!

оригинал: http://51t.ru/JCIPNA

Re: ORIG: g2k14: Matthieu Herrb on Bringing X Forward

51t — 2014-07-23 22:12:33

51t -> 51t

http://www.welivesecurity.com/2014/03/18/operation-windigo-the-vivisection-of-a-large-linux-server-side-credential-stealing-malware-campaign/

ORIG: g2k14: Matthieu Herrb on Bringing X Forward

51t — 2014-07-23 22:11:27

51t -> All

Matthieu Herrb (matthieu@), who is the mad Frenchman who maintains Xenocara, writes in to share his g2k14 experience:

My main projects (multitouch, dhcpv6) didn't make any progress as I was distracted into X sets tweaks at the request of a few other hackers.

After much discussion this only led to the addition of ucpp in base (after a short detour by /usr/xenocara/app/xrdb-cpp) as /usr/libexec/auxcpp.

The reason is that xdrb (part of xbase which is required by many ports) needs a C pre-processor to run. But since gcc 4, /usr/bin/cpp is in the comp set because it's just another invocation of the full gcc. So xbase required the comp set to be installed.

This annoys 2 kind of people: those with appliances with small disks and the paranoid ones who don't want to provide a C compiler to attackers (which may be a good idea, when looking at components of the windigo operation).

So auxcpp is now part of the base set, and the depency of xbase on comp is gone. The X sets will stay in their current state for 5.6.

Otherwise, I've done a few updates on xenocara components. The xenocara tree is now mostly ready for 5.6.

I've nevertheless enjoyed the hackathon. Thanks to Mitja and his team for the organisation and to all foundation donors for the funding!

Re: linux.14

vit01 — 2014-07-23 19:15:54

vit01 -> 51t

Фетчится и убрано

Re: linux.14

51t — 2014-07-23 18:47:01

51t -> vit01

fetch http://51t.ru/u/e/gazeta.14
fetch http://51t.ru/u/e/think.aloud.14
fetch http://51t.ru/u/e/od.ii.dev.14

это убрать - у меня нет таких эх

а добавить:

younglinux.info.14
obsd.bug.14
game.rogue.14
music.14
vk-news.14

в последнем, кстати, я уже успел ответить :)

Re: linux.14

vit01 — 2014-07-23 13:04:07

vit01 -> 51t

> о существовании эх?
Когда мы перейдём на новый вариант php ноды, где имеется эхолист, я всё туда запишу, и с описаниями. Андрей обещает протестировать.

> я сейчас граблю компьютерру, allhockey, f1news и юморный сайт-опять-забыл-название...
Юмор с тебя гейтуется, а остальное что-то не хочу =) хотя видел, что есть. Будет нужно мне и/или поинтам - загейтую.
Кстати, у меня есть идея кое-что загейтовать... Тоже для себя пока сделаю.

> я ж не хожу никуда :)
Сейчас что-то меньше опять ходить стал. Всё, что нужно, теперь есть в ii, поэтому теперь ходить мало куда нужно. Но на примете пара мест есть... потом сообщу.

Re: linux.14

51t — 2014-07-23 12:53:03

51t -> vit01

> Такое тоже можно. Но тогда это получается просто тематическая болталка, а не глобальная.

это труба. :) в один конец крикнули, из другого - вылетело :) можно даже разные года поставить на разных сайтах :) но сначала надо сделать просто трубу...

Re: linux.14

vit01 — 2014-07-23 12:52:41

vit01 -> 51t

Про sql думаю, что надо будет оно всё-таки. Когда лимит инодов будет подходить к концу. Просто у меня на хостинге такой лимит есть, и превышать его не разрешается. Из-за этого пару дней назад был no message, если помнишь.

Re: linux.14

51t — 2014-07-23 12:52:05

51t -> vit01

> Кого? Пользователей? У меня даже счётчиков не стоит на сайте =)

о существовании эх?

> То, что есть у меня, ты уже знаешь (ну список эх).

угу... теперь оно всё есть на глобальном хабе http://r.51t.ru, надо будет и свои эхи туда сваливать...

> Конкретно про свою станцию (да и не только) я считаю, что простым юзерам интересно будет почитать younglinux.info.14. Тем более, все статьи из раздела python я туда уже запостил. В эхе vk-news.14 идёт перепост со страницы Реактос в ВК. Но это не надо, наверное.

я сейчас граблю компьютерру, allhockey, f1news и юморный сайт-опять-забыл-название... на хаб буду сливать всё, что плохо лежит :) а уж на своём сайте - надо как-то придумать, что и как подавать юзеру, выбирая из этого списка эх... я даже не знаю, что бы ещё погейтовать контентно-интересного... :) я ж не хожу никуда :)

Re: linux.14

vit01 — 2014-07-23 12:46:58

vit01 -> 51t

> так как вообще узнать об их существовании? :)
Кого? Пользователей? У меня даже счётчиков не стоит на сайте =)

> я и так думаю, как на юзера больше хорошо подаваемой информации сразу выплюнуть, чтобы знал, что тут есть... постоянно кручу перекручиваю... а вы всё попрятали :)
То, что есть у меня, ты уже знаешь (ну список эх). У Андрея, кстати, свои локалки есть, например, spline.bash.rss и spline.creepy. Но это уже у него надо узнавать.

Конкретно про свою станцию (да и не только) я считаю, что простым юзерам интересно будет почитать younglinux.info.14. Тем более, все статьи из раздела python я туда уже запостил. В эхе vk-news.14 идёт перепост со страницы Реактос в ВК. Но это не надо, наверное.

> мне больше pipe.ГОД нравится. типа, попадаешь в трубу, и там или 1380-й, или 2922, и соответствующая стилизация :)
Такое тоже можно. Но тогда это получается просто тематическая болталка, а не глобальная.

Re: linux.14

51t — 2014-07-23 12:36:31

51t -> vit01

> Думал про идею хранения в одном файле нескольких сообщений, но что-то не сложилось

в принципе, если только msg, то я через peewee сделал хранение, там только несколько строчек было добавить, и две - заменить. разве что фетчера нет, но поддержку приделать тоже несложно. самое главное - это оптимизировать это всё по скорости, там в sql столько нюансов, что глубокие параметры таблицы могут менять скорость нужных операций в сотни раз...

например, когда я делал nz на sqlite, и дёргал там опции по одному - у меня страница, где штук 60 записей, открывалась секунд 10 :) приходилось обходить через статик-кеши. в лоб - мгнновенно. :)

Re: linux.14

51t — 2014-07-23 12:33:08

51t -> vit01

> Контент у нас всё-таки есть, какой-никакой =) Только не читает никто. Кроме меня, наверное.

так как вообще узнать об их существовании? :)

я и так думаю, как на юзера больше хорошо подаваемой информации сразу выплюнуть, чтобы знал, что тут есть... постоянно кручу перекручиваю... а вы всё попрятали :)

> im.global.14 Неплохое название, да?

мне больше pipe.ГОД нравится. типа, попадаешь в трубу, и там или 1380-й, или 2922, и соответствующая стилизация :)

Re: linux.14

vit01 — 2014-07-23 12:26:20

vit01 -> 51t

> подписался на все... чего там только нет... даже какие-то янглинаксы, вк-нюсы
Контент у нас всё-таки есть, какой-никакой =) Только не читает никто. Кроме меня, наверное.

> наверное, и game.rogue.14 я загейтую и younglinux и вк-нюс, сделай бекфетчинг...
Ок, сделаю

> и ещё надо какую-нибудь эху сделать, типа pipe.1380, чтобы можно было между двумя сетями сообщения кидать - иной раз хочется что-то в другую сеть написать, а это надо искать клиент, запускать, то, сё... а так пайпнул, и порядок... можно, чтобы не была просто болталка, стилизовать её под что-нибудь, хоть под клуб джентльменов, хоть под хоббитов, хоть под рыцарей, хоть под звёздные войны - просто для забавы, чтобы не просто болталка была :)
im.global.14
Неплохое название, да?

Re: linux.14

vit01 — 2014-07-23 12:26:12

vit01 -> 51t

> они не говорят мне, КАК ЭХА НАЗЫВАЕТСЯ :) мне вот что было интересно :)
vk-news.14. Завёл её исключительно для себя, больше никто не читает. Была ещё niksor-vk.14 (филиал ru.humor), но владелец потерял к ней интерес, да и удалилась эха при чистке =)

> кстати, ещё тыщ 5 сообщений, и надо будет уже пробовать базу данных или хотя бы раздельное хранение по подкаталогам
Думал про идею хранения в одном файле нескольких сообщений, но что-то не сложилось

Re: linux.14

51t — 2014-07-23 12:17:22

51t -> vit01

> Это же гейты. Они в эху постят, чтобы мне лишний раз не заходить...

они не говорят мне, КАК ЭХА НАЗЫВАЕТСЯ :) мне вот что было интересно :)

надо будет у себя на r сделать сортировку по эхам именно в порядке последней активности - всё руки не доходят, хотя уже давно хочу сделать...

в общем, я нашёл в echo/ список, и подписался НА ВСЁ :)

кстати, ещё тыщ 5 сообщений, и надо будет уже пробовать базу данных или хотя бы раздельное хранение по подкаталогам, на r.51t.ru сейчас почти 11000 сообщений, и ещё 501 сообщение, которого нет на r, есть на самом 51t.ru (там суммарно менее 3000 сообщений)

Re: linux.14

51t — 2014-07-23 12:13:32

51t -> vit01

подписался на все... чего там только нет... даже какие-то янглинаксы, вк-нюсы

а я даже не знаю, как главную страницу оформить так, чтобы туда можно было МНОГО информации вылить, причём вместе с текстом, чтобы человек мог не тыкая по ссылкам впечатление о том, куда попал, получить... :) сижу, экспериментирую, а потом выкину на него ВСЕ эхи, которые создают информационный фон...

наверное, и game.rogue.14 я загейтую и younglinux и вк-нюс, сделай бекфетчинг...

и ещё надо какую-нибудь эху сделать, типа pipe.1380, чтобы можно было между двумя сетями сообщения кидать - иной раз хочется что-то в другую сеть написать, а это надо искать клиент, запускать, то, сё... а так пайпнул, и порядок... можно, чтобы не была просто болталка, стилизовать её под что-нибудь, хоть под клуб джентльменов, хоть под хоббитов, хоть под рыцарей, хоть под звёздные войны - просто для забавы, чтобы не просто болталка была :)

Re: linux.14

vit01 — 2014-07-23 12:07:50

vit01 -> 51t

> мне это вообще ничего не говорит... какие-то vk-скрипты...
Это же гейты. Они в эху постят, чтобы мне лишний раз не заходить...

> есть просто список эх, где постоянно сообщения добавляются...
Сообщения добавляются рандомно...

> или дай полный список эх, я все зафетчу
"game.rogue.14",
"obsd.talk.14",
"bone.14",
"ii.dev.14",
"obsd.rss.14",
"ru.humor.14",
"gazeta.14",
"lor-opennet.2014",
"im.100",
"todo.14",
"to.doc.14",
"sysop.14",
"linux.14",
"ii.test.14",
"ii.soft.14",
"ii.echo.vote.14",
"music.14",
"younglinux.info.14"

Это был конфиг spline-fetch.php, свои эхи ты уже знаешь.

Re: linux.14

51t — 2014-07-23 11:59:30

51t -> vit01

мне это вообще ничего не говорит... какие-то vk-скрипты...

есть просто список эх, где постоянно сообщения добавляются...

или дай полный список эх, я все зафетчу, и через ленту на r.51t.ru буду смотреть :) я и так вашу станцию через неё читаю :)

Re: linux.14

vit01 — 2014-07-23 11:58:27

vit01 -> 51t

> я у себя на сайте в шапке записываю id-шники:
Ок, вижу, спасибо.

Re: linux.14

51t — 2014-07-23 11:48:59

51t -> vit01

я у себя на сайте в шапке записываю id-шники:

http://51t.ru/txt.drafts.14

Re: linux.14

vit01 — 2014-07-23 11:47:17

vit01 -> 51t

> какие вообще активные эхи есть?
Какие в фетчере ходят, такие и активные. http://irk38.tk/ii/ содержит все мои скрипты. Фетчеры и боты найдёшь по названию.

Re: linux.14

vit01 — 2014-07-23 11:44:34

vit01 -> 51t

> прокинь обратно с меня linux.14
загейтовал, см. im.100.

> ps. чё с переводами?
Чё-то лень на меня такая напала :( ужас
Буду искоренять. Наверное, лучше тебе будет мне просто todo написать, даже в виде msgid, чтобы я это перевёл. todo дисциплинирует =)

Re: linux.14

51t — 2014-07-23 09:11:32

51t -> 51t

какие вообще активные эхи есть?

linux.14

51t — 2014-07-23 08:49:36

51t -> All

прокинь обратно с меня linux.14

ps. чё с переводами?

ORIG: g2k14: Martin Pieuchot on routing and USB

51t — 2014-07-23 04:37:05

51t -> All

This time around, we get to hear a g2k14 developer report from the one and only Martin Pieuchot (mpi@)

Since I never managed to do what I had planned during a hackathon, I came to g2k14 with a small guitar and an easy plan: play music and drink wine. As expected I didn't respect my plan at all, instead of wine I had beer and instead of playing music I hacked the kernel 8)

I started by fixing one of the two issues from our USB stack that prevent us from enabling xhci(4) in GENERIC (bug apart). This was mostly a plumbing task in order to handle the way xHCI assign device addresses.

Then I looked at the radix tree corruption reported by guenther@ that was caused by the addition of a local route for every configured IPv4 address. It turns out that there is a problem with nodes with a destination of 0.0.0.0, used by the default routes. claudio@ is still hunting in this area, and for the moment I committed a version of the diff ignoring such addresses.

In the meantime I did more plumbing and replaced the last offending shutdown hook, used by softraid(4), by a function called before tearing down the devices. This was a bit more complicated than expected because softraid has its own subtree of devices that do not see the DVACT_POWERDOWN event sent by mainbus at shutdown.

As a result of this work I could unify a bit more of the shutdown sequence with the hibernate one and fix a uhci(4) panic by preventing the thread doing the shutdown to sleep.

The next issues on my list were two HC transfer descriptors allocation problems reported by various users. With the help of kettenis@ I addressed the first one by making sure bus_dmamem_map(9) honors the BUS_DMA_NOWAIT flag, then the second one was fixed by performing a famous spl dance.

I also did some more plumbing in the autoconf(9) framework in order to kill the DVACT_DEACTIVATE event. Then I removed some old network types from our kernel.

Finally I spent my last days trying to find the simplest way to change some tty(4) line disciplines to not be re-entrant in order to make the com(4) interrupt handler MP safe. After various attempts, I found something :)

When I was not strictly hacking I had a lot of interesting chats with various other developers. Among these, I was really happy to discuss with yuo@, pirofti@ and stsp@ about USB because that's an area were I mostly work alone. But the most important discussion of this hackathon was the brain storming we had with claudio@, bluhm@, henning@ and others about the network stack: don't worry, we have a plan.

Thanks a lot to Mitja for this great hackathon!

ORIG: g2k14: Henning Brauer on IPv6, bpf, vlan surgery

51t — 2014-07-23 04:36:24

51t -> All

Our second g2k14 report comes from Henning Brauer (henning@), who writes:

g2k14 has been weird: I, for the most part, wrote IPv6 code. No, that doesn't mean I'd suddenly think inet6 is any good. But let's start from the beginning.

I once again managed to miss arranging travel in time over way too much $work - but luckily found suitable (actually, even close-to-perfect) flights last week. Even affordable.

So I arrived monday evening. First I had a fix to vlan bpf on the radar - with the vlan changes I did in Morocco, the packets showing up via the bpf tap in vlan had the vlan ethernet header instead of the plain ethernet header that most consumers expect. Missed side effect of us prepending the vlan ethernet header right away instead of first preprending a regular ethernet header to only throw it away later and prepending a new vlan ether one. Now of course we don't want to throw away our shiny vlan ether header and again construct a new (real or very embryonic) ether header just to make bpf happy. The solution to that is a custom bpf copy function that just gets rid of the extra 4 bytes the ether vlan header has over the regular ether one. Before actually doing that I ended up cleaning up bpf.c quite a bit and cut a lot of duplicated code. Eventually got bpf_mcopy_stripvlan done without duplicating oh so much code again, it works as expected, the bug is fixed and bpf.c is much nicer than it used to be.

Then I mysteriously got sucked into netinet6. Years ago I added an interface flag, IFXF_NOINET6, to turn off inet6 per interface. Automagically adding an inet6 address just because an interface comes up is ridiculous and actually a security risk, since your machine is suddenly reachable over it (to some extent), which might not even be clear to the person taking the interface up. And it goes further, that automagic inet6 address even causes problems in some setups, e. g. with bridges. So we eventually decided to turn off v6 by default, which is how it should have been from the beginning - actively adding an inet6 address, manually or by running rtsol for autoconfig, turned it on and everything magically worked right. Without the implicit attack vector. So that is actually invisible to almost all that use inet6 - only those just using link-local, without any "real" inet6 address, had to adapt slightly. Pleasantly even the die-hard inet6 lovers in our group agreed with that move.

Did inet6 off by default by setting IFXF_NOINET6 in if_attach(), every interface showing up goes through that. But in a "inet6 only turned on when actually used" world, the NOINET6 semantic is backwards, and all those calls to inet6 attach functions guarded by checking that flag were useless. I wanted to clean that up, get rid of the flag and just not call the inet6 setup stuff (mostly adding the link-local addr) unless really needed. But that left a problem, we really really really want to make sure we don't accept router advertisements unless root clearly indicated he wants to do so. And the v6 autoconf semantics were a little weird to begin with. So here comes a new flag, IFXF_AUTOCONF6, set by doing "ifconfig inet6 autoconf" or - for the moment - running rtsol. Very soon that ifconfig invocation will make the kernel send the router solicitation itself, i. e. no more need for rtsol and rtsold. That was part of the idea from the beginning, florian@ did the implementation, and as usual the entire thing is a big group effort, this time foremost between him, stsp, bluhm, mpi, naddy, benno and, well, me. I then could clean up the NOINET6 flag thing, get rid of it, add explicit IFAFATTACH/DETACH ioctls (which are not limited to inet6, even tho that's the implemented bits for now) and made the section at least nicer than it used to be. The semantics don't change, this is supposed to be user-invisible.

Also spent some time with Wouter reviewing the privilege handling and general early (potentially dangerous) code paths in nsd and unbound. Much to my surprise I didn't find a single real omission or error, but gave him some input how things can be nicer and easier to audit without giving up portability.

Mitja again did an awesome job organizing this hackathon (thank you!), the city of Ljubljana is really really beautiful, the people here are cool and nice. Definitely a recommended destination. Unfortunately didn't really have spare cycles to enjoy it over hacking and a LOT of time in (productive!) discussions.