Мы рады представить новую версию Rust 1.10. Rust — это системный язык программирования, нацеленный на безопасную работу с памятью, скорость и параллельное выполнение кода.
Как обычно, вы можете установить Rust 1.10 с соответствующей страницы официального сайта, а также ознакомиться с подробным списком изменений в этой версии на GitHub. В этот релиз вошло 1276 патчей.
Что вошло в стабильную версию 1.10
В Rust 1.10 стала доступна одна из наиболее желаемых сообществом возможностей: прерывание работы (abort) при панике вместо размотки стека. Это поведение управляется флагом -C panic=abort или настройкой в Cargo.toml. Зачем это нужно? Как вы помните, паника означает непридвиденную проблему, и для многих приложений abort — разумный выбор. При использовании panic=abort генерируется меньше кода, что означает меньшие по объёму исполняемые файлы и чуть меньшее время компиляции. Очень приблизительная оценка говорит об уменьшении на 10% и размера файла, и времени компиляции. Эта возможность была определена в RFC 1513.
Вторая большая возможность в 1.10 — новый тип контейнера — cdylib. Существующий формат динамических библиотек dylib отныне используется только для динамических библиотек, используемых в проектах на Rust, а cdylib будет использоваться при компиляции кода на Rust для встраивания в другие языки. В выпуске 1.10 cdylib поддерживается компилятором, но пока не поддерживается Cargo. Этот формат был определён в RFC 1510.
Также в ряде случаев была улучшена производительность компилятора, использовать документацию и сам rustdoc стало удобнее, а сообщения об ошибках стали читабельнее.
Наконец, произошло большое изменение в процессе разработки Rust. Оно не влияет на пользователей непосредственно, но сильно поможет тем, кто занимается распространением Rust. Компилятор Rust написан на Rust, что означает использование Rust для сборки Rust. Этот процесс называется "бутстрепинг" (англ. "bootstrapping"). Исторически, мы делали это с помощью снэпшотов компилятора определённой версии, из которых всегда и бутстрапились; при этом снэпшот периодически обновлялся, при необходимости. Более того, т.к. компилятор Rust использует нестабильные возможности Rust, чтобы собрать компилятор, нужна была конкретная версия nightly. Это хорошо работало годами, но мы переросли такой процесс. Его главный недостаток состоит в том, что он требует загрузки снэпшота в бинарном виде, что плохо подходит для дистрибутивов Linux. В частности, мейнтейнеры дистрибутивов хотели бы собирать последние версии Rust, используя только версии, доступные в предыдущих версиях пакетов, а не недоверенные бинарники. По сути, мы изменили нашу систему сборки так, что Rust 1.10 собирается компилятором Rust 1.9. В будущем, этот способ будет использоваться дальше — Rust 1.11 будет собран с помощью Rust 1.10. Более того, теперь компилятор можно собрать стабильным компилятором. Это упрощает весь процесс бутстрепинга, и значительно помогает мейнтейнерам дистрибутивов, т.к. им больше не нужно два отдельных пакета. Подробнее можно прочитать в комментариях к pull request.
Подробнее о изменениях в языке в целом можно прочитать в замечаниях к выпуску.
Стабилизация библиотек
Было стабилизировано примерно 70 интерфейсов:
- Специфичные для Windows файловые операции
std::os::windows::fs::OpenOptionsExt. - Возможность зарегистрировать и разрегистрировать хуки на панику с помощью
std::panic::{set,take}_hook. CStr::from_bytes_with_nul, чтобы создаватьCStrиз среза байт (и непроверяемый (unchecked) вариант).- Небольшие улучшения в
std::fs::Metadata. compare_exchangeдля различных атомарных типов.- Множество специфичных для UNIX сетевых возможностей в
std::os::unix::net::{UnixStream, UnixListener, UnixDatagram, SocketAddr}.
В дополнение, для &CStr, CString, UnsafeCell, fmt::Error, Condvar, Mutex, и RwLock теперь реализован Default.
Наконец, на Linux, если HashMap не может быть инициализирован с помощью getrandom, он временно откатится на использование /dev/urandom, чтобы не блокироваться рано в процессе загрузки.
Подробнее смотрите замечания к выпуску.
Возможности Cargo
В этом выпуске Cargo получил несколько небольших улучшений.
- Вышупомянутая настройка
profile.*.panicуправляет тем, как должна выполняться паника. - Теперь Cargo сообщает статус в стандартный поток ошибок, а не в стандартный поток вывода.
- Ключевые слова Rust теперь нельзя использовать в качестве названий контейнеров.
- В
cargo installпоявился флаг--force. cargo testтеперь принимает флаг--doc, с которым выполняются только тесты в документации.- Добавлен
cargo --explain, который отражает флагrustc --explain.
Подробнее смотрите замечания к выпуску.
Разработчики версии 1.10
В выпуске версии 1.10 участвовало 139 человек. Большое вам спасибо!
- Adolfo Ochagavia
- Alan Somers
- Alec S
- Alex Burka
- Alex Crichton
- Alex Ozdemir
- Amanieu d'Antras
- Andrea Canciani
- Andrew Paseltiner
- Andrey Tonkih
- Andy Russell
- Anton Blanchard
- Ariel Ben-Yehuda
- Barosl Lee
- benaryorg
- billyevans
- Bjorn Steinbrink
- bnewbold
- bors
- Brandon Edens
- Brayden Winterton
- Brian Anderson
- Brian Campbell
- Brian Green
- c4rlo
- Christopher Serr
- Corey Farwell
- Cristian Oliveira
- Cyryl Plotnicki-Chudyk
- Dan Fockler
- Daniel Campoverde [alx741]
- Dave Huseby
- David Hewitt
- David Tolnay
- Deepak Kannan
- Demetri Obenour
- Doug Goldstein
- Eduard Burtescu
- Eduard-Mihai Burtescu
- Ergenekon Yigit
- Fabrice Desre
- Felix S. Klock II
- Florian Berger
- Garrett Squire
- Geordon Worley
- Georg Brandl
- ggomez
- Gigih Aji Ibrahim
- Guillaume Bonnet
- Guillaume Gomez
- Haiko Schol
- Jake Goulding
- James Miller
- jbranchaud
- Jeffrey Seyfried
- jethrogb
- jocki84
- Johannes Oertel
- Jonas Schievink
- jonathandturner
- Jonathan S
- Jonathan Turner
- JP Sugarbroad
- Kaiyin Zhong
- Kamal Marhubi
- Kevin Butler
- Le?o Testard
- Luca Bruno
- Lukas Kalbertodt
- Lukas Pustina
- Luqman Aden
- Manish Goregaokar
- Marcus Klaas
- mark-summerfield
- Masood Malekghassemi
- Matt Brubeck
- Matt Kraai
- Maxim Samburskiy
- Michael Howell
- Michael Tiller
- Michael Woerister
- mitaa
- mrmiywj
- Ms2ger
- Murarth
- Nerijus Arlauskas
- Nick Cameron
- Nick Fitzgerald
- Nick Hamann
- Nick Platt
- Niko Matsakis
- Oliver 'ker' Schneider
- Oliver Middleton
- Oliver Schneider
- Patrick Walton
- Pavel Sountsov
- Philipp Matthias Schaefer
- Philipp Oppermann
- pierzchalski
- Postmodern
- pravic
- Pyry Kontio
- Raph Levien
- Re?my Rakic
- rkjnsn
- Robert Habermeier
- Robin Kruppe
- Sander Maijers
- Scott Olson
- Sean Gillespie
- Sebastien Marie
- Seo Sanghyeon
- silvo38
- Simonas Kazlauskas
- Simon Wollwage
- Stefan Schindler
- Stephen Mather
- Steve Klabnik
- Steven Burns
- Steven Fackler
- Szabolcs Berecz
- Tamir Duberstein
- Tang Chenglong
- Taylor Cramer
- Ticki
- Timon Van Overveldt
- Timothy McRoy
- Tobias Bucher
- Tobias Mu?ller
- Tomas Hubelbauer
- Tomoki Aonuma
- Tshepang Lekhonkhobe
- Ulrik Sverdrup
- User
- Vadim Chugunov
- Vadim Petrochenkov
- Val Vanderschaegen
- Wang Xuerui
- York Xiang
Комментарии (16)
rekavoda
12.07.2016 23:39Когда добавят инкрементальную компиляцию? Видел пост Нико Матсакиса, что вот вот, но это было пару месяцев назад.
ozkriff
13.07.2016 10:26Я не припомню (и не могу нагуглить) утверждений про "вот вот", но в текущей ночной сборке вижу опцию "-Z incremental=val — enable incremental compilation (experimental)".
И вроде даже получилось несколько проектов собрать при помощи вызова "cargo rustc — -Z incremental=tmpdir", но пару раз оно грохнулось с ошибкой внутри rustc — видимо, еще достаточно сырое.
khim
По поводу «если HashMap не может быть инициализирован с помощью getrandom, он временно откатится на использование /dev/urandom, чтобы не блокироваться рано в процессе загрузки» — было бы неплохо иметь возможность управлять этим.
Для тех, кто не понял — о чём это всё. В Linux имеется такой файл /dev/urandom, который выдаёт криптографически стойкие случайные числа. Он, правда, имеет проблему: он их генерирует в любых количествах с использованием криптографически стойкого хеша. Всё бы хорошо — но эта схема требует-таки исходного криптойскойкого «зерна»! Если вы в криптохеш засунете в качестве зерна число 1, скажем, то всё что вы потом нагенерируете — будет весьма предсказуемо, никакой «волшебный» хеш не поможет! Новый системный вызов
getrandomэту проблему решает: он действует почти как/dev/urandom— но при этом при начальной загрузке системы ждёт пока откуда-нибудь возьмётся энтропия (от дребезга клавиватуры или из файла «прикопанного» перед перезагрузкой — неважно).Но оказалось, что в некоторых системах (виртуальные машины, в основном) энтропии в должном количестве просто нет! И там
getrandomможет очень долго ждать «у моря погоды». Чтобы решить эту и проблему использщуется/dev/urandomдля инициализации хеша. Это — хорошо для всяких локальных скриптов, которые никто не планирует атаковать, но для каких-нибудь web-серверов — это уже не так здорово. Можно, конечно, завести утилиту, которая будет эту проблему «разруливать»…ozkriff
https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.with_hasher — это не оно?
khim
Я не хочу руками для каждого хеша указывать хешер! Вариант через
getrandom— меня вполне устраивает! Но не через/dev/urandom— который работает почти так же, но о проблемах в котором вы сможете узнать только когда вас взломают.Как я сказал: тут как бы хорошего ответа нет. Для 99.99% пользователей
getrandom— лучший выбор. Но 0.01% «пострадавших» вопит так, что «крыша поднимается». Ok, уважили вы их. Но нельзя ли сделать так, чтобы большинство, которым эта, с позволения сказать, «оптимизация» нафиг не нужна могли хотя бы ключик задать? Почитайте комментарии в баге.grossws
В коде до этого было:
что аналогично вызову
Как нам рассказывает
man 2 getrandom:Т. е. при использовании одного и того же пула энтропии
/dev/urandomчтение из/dev/urandomне блокируется (т. е. используется PRNG), аgetrandom— блокируется? Не могли бы вы рассказать подробнее почему так?khim
Потому что когда делали
/dev/urandom, то считалось что для «настоящей» криптухи люди будут использовать/dev/random— но потом выяснилось что это просто не работает: ну нет столько энтропии в компьютере, чтобы для сессионных ключей новую энтропию откуда-то находить! Соответственно все используют/dev/urandom, которого достаточно для всех случаев, кроме того, когда «начальной энтропии» ещё не накоплено достаточно — а чтобы этого случая избежать все дистрибутивы начинают загрузку переливая некоторое количество бит из сохранённого на диске пула (или из/dev/random) в/dev/urandom— но это костыль. Аgetrandom— современная замена. Или вы не нашли в описании соответствующих слов?grossws
Пропустил, да. Ман просматривал по диагонали.
Т. е. в случае выше блокировалось, когда пул ещё вообще не инициализирован, т. к.
GRND_RANDOMдля использования пула/dev/randomне передавался среди флаговgetrandom().khim
Именно так. И мне кажется — что это разумное поведение. Лучше Virtio RNG настроить, чем подобные «подводные камни» закладывать…
h31
Ну, HashMap — это всё-таки не криптография. В рамках данной задачи (создание хэшей для HashMap), даже если генератор случайных чисел будет некачественным, единственное, чем это может грозить — это потеря производительности. Да, можно организовать DoS-атаку, но это опять же, нужно очень постараться.
С одной стороны да, было бы неплохо, чтобы был флаг для управления источником рандома. С другой стороны, если так беспокоитесь о безопасности, можно и самому наполнить пул энтропии. Хотя в любом случае должен быть какой-нибудь warning, если берется заведомо некачественный генератор, банально чтобы обратить внимание админов и разработчиков к этой проблеме.
khim
vintage
Рандом не только в криптографии используется. Во многих случаях достаточно и псевдорандома. А для HashMap и вообще константа сойдёт, да. :-)