Design: Предложение: Импортировать синтаксис разрешения для нативных хостов wasm.

что, если вместо определенного синтаксиса мы просто рекомендуем, чтобы реализации wasi применяли правила возможностей стиля libpreload для разрешения импорта? если у вас есть a.wasm и b.wasm , вы можете объявить . или ./b.wasm в своем манифесте васи, чтобы вы могли импортировать его из a.wasm

это сделало бы wasi более совместимым с другими случайными системами, к которым он может быть присоединен, такими как браузеры и node.

Мне нравится общее направление этого предложения. Предотвращение произвольного захвата импорта библиотеками кажется важным. Мне также нравится, что это предложение довольно легкое. Однако пара мыслей.

• Ваше описание карт импорта немного неполное. Является ли идея, что запись карты a: b/c позволит импортировать b/c под именем $a ? Если это так, я не уверен, как это позволяет изменять или переназначать библиотеки, поскольку модуль импорта должен знать, что имя (пере)сопоставляется. Зачем нужен префикс $ ?

• Было бы хорошо рассматривать каталоги в более модульной манере, где каждый каталог также может ограничивать файлы, которые он «экспортирует» наружу , в окружение. Такие «карты экспорта» будут добавлены к картам импорта, которые определяют среды, обращенные внутрь . Если указана карта экспорта, доступ из модулей или карт импорта/экспорта в окружающих или одноуровневых каталогах возможен только к перечисленным в ней файлам/путям.

• Я полностью согласен с использованием стандартных ссылок URI в качестве механизма именования. Тем не менее, префиксы @ или $ немного злоупотребляют понятием относительной ссылки ( @a/b является относительной ссылкой в ​​терминах URI, тогда как семантика, которую она присваивает здесь, очень абсолютная форма ссылки).

• Bikeshedding: много ли пользы от использования JSON для импорта карт? Как вы их описываете, они просто состоят из списка пар путей, поэтому сложный и запутанный формат, такой как JSON, может быть излишним для этого.

Если это так, я не уверен, как это позволяет изменять или переназначать библиотеки.

Я думал о внедрении зависимостей, когда (например) два модуля должны использовать один и тот же экземпляр реакции, могут импортировать $react и полагаться на корень проекта для обеспечения сопоставления.

Хотя, если подумать, возникает вопрос, что делать, когда два файла/модуля импортируют один и тот же файл/модуль. Должны ли они создавать два отдельных экземпляра или один общий экземпляр? Оба ответа имеют свои варианты использования.

Я также думал, что может быть механизм для нескольких файлов wasm_import_map для отладки, выпуска, модульных тестов и т. д., но это кажется преждевременным расширением возможностей. Wasm не обязательно должен становиться Cmake.

Зачем нужен префикс $?

Это позволяет более четко отображать сообщения об ошибках и быстрее диагностировать проблемы.

Cannot find host module "@foobar"

против

Cannot find file "some/path/foobar.wasm"

против

Key "$foobar" not found in imports maps:
- "some/path/wasm_import_map.json"
- "some/wasm_import_map.json"

Отсутствие префиксов означает, что вы либо получаете длинные сообщения об ошибках, перечисляющие все возможные варианты, либо, что более вероятно, вы получаете такие же расплывчатые ошибки импорта, как и компиляторы C, которые говорят «Не удается разрешить foobar» и оставляют вас гадать, почему.

Было бы хорошо рассматривать каталоги в более модульной манере, где каждый каталог также может ограничивать файлы, которые он «экспортирует» наружу, в окружение.

Я не думаю, что экспортные карты были бы так полезны. Модуль, который хочет экспортировать, скажем, подмодуль «привязки» и «сетевой» подмодуль, может просто иметь файлы bindings.wasm и network.wasm в корне.

Механизм ограничения импорта из родительских каталогов необходим для безопасности файловой системы, но вам не нужно (и практически невозможно) ограничивать импорт из дочерних каталогов.

Много ли пользы от использования JSON для импорта карт?

Не совсем. Я тоже думал о протобаффе, но на самом деле подойдет любой формат. Просто должен быть один или два формата по умолчанию.

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

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

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

Я не думаю, что экспортные карты были бы так полезны. Модуль, который хочет экспортировать, скажем, подмодуль «bindings» и «network», может просто иметь файлы bindings.wasm и network.wasm в корне.

Помешает ли это кому-либо переопределить намерение путем сопоставления модулей импорта во вложенных каталогах?

Сообщения об ошибках кажутся решаемой проблемой.

Ну да, они тоже стоят #include , и все же устранение неполадок с неудачным включением библиотеки может быть на удивление сложным.

В любом случае, я думаю, что есть неотъемлемая ценность в том, чтобы заставить пользователя указать свое намерение. Это создает яму успеха для разработчиков инструментов, которые недвусмысленно знают, чего хочет пользователь; и это позволяет пользователям легче понять, как работает набор инструментов.

Я думаю, что для шимминга вам понадобится возможность переназначать произвольные модули, включая системные (т. е. имена, начинающиеся с @ в том, что вы описываете).

Что касается произвольных модулей, я специально написал предложение, чтобы этого избежать. Если вы сделаете возможным маскировку любого импорта так, как это позволяют карты импорта WICG, вы сделаете базовый дизайн менее надежным, менее KISS, и вы откроете для себя множество ошибок / эксплойтов скрытия имен.

(это не критика карт импорта WICG; как я уже сказал, они предназначены для разных вариантов использования)

Я думаю, что параметризации внедрения зависимостей достаточно для большинства случаев использования шимминга, а для более навязчивого шимминга вы всегда можете использовать инструмент «вручную» для замены одних файлов другими.

Что касается системных модулей, я думал, что их шиммирование будет выполняться на уровне API WebAssembly.instantiate , поскольку наиболее распространенным вариантом использования будут модульные тесты.

Синтаксис всегда можно объединить с $ , но опять же, есть ценность в выражении намерения.

(также, в худшем случае, мы отказываемся от @ и $ и делаем их необязательным соглашением об именах; противоположная прогрессия нарушает совместимость)

Помешает ли это кому-либо переопределить намерение путем сопоставления модулей импорта во вложенных каталогах?

Нет, но я не уверен, что это проблема.

Что касается переопределения намерения автора модуля, то это прерогатива пользователя модуля. Если они хотят закопать внутренности модуля, они делают это на свой страх и риск, и в любом случае они могут сделать это, разветвив модуль.

Что касается безопасности песочницы, я думаю, может возникнуть проблема, если вредоносный модуль импортирует какой-то внешний модуль, совместно используемый другими программами, таким образом, что нарушается инвариант (например, вместо импорта /usr/bin/game_engine/save_progress вредоносный код импортирует /usr/bin/game_engine/save_progress/unsafe_filesystem_functions ).

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

Но я предполагаю, что если я стремлюсь к подходу «яма успеха» и «безопасная песочница», что является своего рода точкой зрения ocap и WASI, их тоже нужно учитывать.

имя можно найти только в любом из родительских каталогов или на карте в нем.

Карта там да, никаких родительских директорий нет.

Доступ к файлам в родительских каталогах нарушает песочницу и не разрешен.

Файл .wasm может получить доступ только к:

• .wasm файлы в своем каталоге
• .wasm файлы в подкаталогах
• wasm_import_map.json файлов в родительских каталогах, вплоть до корня импорта

Сами карты импорта подчиняются тем же правилам и могут получать доступ к файлам wasm только в подкаталогах и импортировать карты в родительские папки.

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

Я полностью согласен, но в этом случае кажется, что это преждевременно блокирует допустимые варианты использования, связанные с другим намерением.

Что касается переопределения намерения автора модуля, то это прерогатива пользователя модуля. Если они хотят закопать внутренности модуля, они делают это на свой страх и риск.

Ага... Я уже слышал этот аргумент ;). К сожалению, на практике теория игр работает иначе. Если нет возможности явно выразить и (в какой-то степени) обеспечить выполнение такого намерения, то кто- то отменит его, потому что его ничто не остановит. И для этого достаточно одного популярного клиента, и вдруг автор модуля понимает, что вся нагрузка лежит на них, чтобы сохранить неофициальный API или получить весь огонь от переходных клиентов за то, что ее/его обновление нарушило их код. Был там, сделал это; это ситуация, которую хорошо спроектированная система должна помочь избежать.

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

Доступ к файлам в родительских каталогах нарушает песочницу и не разрешен.

Верно, я имел в виду карты импорта только в родительских каталогах, "или" было небрежной формулировкой.

Был там, сделал это; это ситуация, которую хорошо спроектированная система должна помочь избежать.

Справедливо.

Я полностью согласен, но в этом случае кажется, что это преждевременно блокирует допустимые варианты использования, связанные с другим намерением.

Чтобы было ясно, ваша основная оговорка в отношении типизированных префиксов:

• Что они предотвращают конкретные варианты использования, которые позволила бы более общая система?
• Или что они представляют собой конструктивное ограничение и, следовательно, могут препятствовать будущим вариантам использования, которых мы не ожидали?

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

Если первое, есть ли у вас конкретные примеры, чтобы я мог скорректировать свое предложение? Очевидно, что экосистемы пакетов wasm, для которой мы хотим разработать дизайн, еще не существует, но даже расплывчатый вариант использования «у нас есть X внутри каталога Y, мы хотим скрыть Z» мог бы мне помочь.

Чтобы было ясно, мои причины для включения префиксов:

• Недвусмысленно сообщайте о намерениях пользователя.
• Избегайте проблем с теневым копированием, например разрыва пакета из-за того, что он импортирует файл с именем streams.wasm , а пакет с именем stream был добавлен в корневой проект.
• Имейте зарезервированный синтаксис для системных библиотек, не беспокоясь о существующих именах пакетов .

Мне любопытно, должны ли WASM/WASI вообще охватывать какое-либо поведение модулей. Моя первая мысль заключается в том, что они не должны, так что их можно использовать во многих местах независимо от модульной системы. То, как wasmtime загружает и связывает модули WASM, сильно отличается от того, как что-то вроде node загружает и связывает модули WASM, но в идеале они оба должны «просто работать».

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

Например, для поверхностных деталей: хотя я выступал за @namespace/modulename , сеть, кажется, движется к namespace:modulename для встроенных модулей, что мне кажется хорошим, и, похоже, это должно работать для также не-веб-оболочки.

В более широком смысле предложение по интеграции Wasm/ESM действительно использует JS-связку, но оно делает это для кодирования некоторых вещей, которые одинаково хорошо имеют смысл вне JS, например, что у вас не может быть нескольких модулей Wasm, которые циклически импортируют экспорты функций друг друга ( с ошибкой во время инстанцирования). Интересно, могли бы мы поработать над тем, чтобы сформулировать спецификацию интеграции ESM, чтобы сделать эту межсредовую семантику более понятной.

Способ, которым wasmtime загружает и связывает модули WASM

Я почти уверен, что wasmtime в настоящее время вообще не связывает модули WASM. Это не задокументированная функция, эмпирически она не работает в моих тестах, и, глядя на источник, интерфейс Resolver реализован только с Namespace (что соответствует wasi_unstable и другие жестко заданные имена) и NullResolver .

Моя первая мысль заключается в том, что они не должны, так что их можно использовать во многих местах независимо от модульной системы.

Но это не совсем то, как это работает на практике. Высказывание «У нас должны быть очень общие стандарты, чтобы каждый мог делать то, что лучше всего соответствует его потребностям» часто превращается в «Существует дюжина конкурирующих конвенций/неформальных стандартов, ни один из них правильно не адресован проблемному пространству, и большинство инструментов понимают только 2 или 3 из них». их".

Хотя я выступал за использование @namespace/modulename, Интернет, похоже, движется к namespace:modulename для встроенных модулей,

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

В более широком смысле предложение по интеграции Wasm/ESM действительно использует JS-связку, но оно делает это для кодирования некоторых вещей, которые одинаково хорошо имеют смысл вне JS, например, что у вас не может быть нескольких модулей Wasm, которые циклически импортируют экспорты функций друг друга ( с ошибкой во время инстанцирования).

Да, я думаю, что это та область, где этого предложения больше всего не хватает. Мне нужно лучше определить семантику связывания и создать проблему в репозитории esm-integration, чтобы обсудить дублирование.

я имел в виду, что нам следует избегать указания конкретных вещей, таких как синтаксис импорта и разрешение (хотя наличие правил ocap и тому подобного — это круто). система, желающая интегрировать wasm, может уже использовать определенный синтаксис и систему разрешения, которые могут конфликтовать с нашими. он может даже не иметь представления о путях и файлах.

У меня нет простого варианта использования. Однако концептуально существует только два типа ссылок на модули: определенные, которые относятся к фиксированному известному модулю, обычно являющемуся частью того же компонента, и неопределенные, которые фактически являются параметрами и разрешаются клиентом модуля. (Интересно, что сам Васм имеет только последнее.)

С этой точки зрения мне не совсем понятно, что добавляет третий вид. Я вижу, как было бы полезно иметь настраиваемый механизм наложения, который может эмулировать оба других типа. Но это имеет смысл только в том случае, если оно может принимать обе синтаксические формы. OTOH, если он не может накладываться на другие, то чем он семантически отличается от импорта пакета, т. е. в чем более глубокая разница между @ и $ , и почему выгодно жестко запрограммировать это разница?

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

Хорошо, я думаю, что теперь я лучше понимаю ваш вопрос.

в чем более глубокая разница между @ и $ и почему выгодно зафиксировать эту разницу?

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

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

Варианты использования, о которых я думал, были в основном шиммированием и альтернативными сборками (модульные тесты, отладка или выпуск), но на самом деле их не нужно запекать в системе пакетов.

Я по-прежнему думаю, что если мы добавим стандартные карты импорта, то нам нужно добавить их таким образом, чтобы случайно не создать проблемы с затенением, но я не уверен, что карты импорта больше полезны при разрешении импорта в автономном режиме.

В любом случае, если мы откажемся от синтаксиса $ и импортируем карты, как вы думаете, стоит ли стандартизировать остальную часть предложения?

Измененное предложение будет следующим:

• Добавьте необязательный корневой объект файловой системы в API создания экземпляров ( WebAssembly.instantiate , wasm_instance_new , wasm::Instance::make )

• В соглашениях инструментов добавьте спецификацию для анализа строк импорта как URI с правилами песочницы, описанными выше.

  • Выработайте синтаксис ( @foo/bar или foo:bar или любой другой, на котором остановился W3C) для импорта хоста.

Потенциальные механизмы импорта/экспорта/схемы шимминга могут быть добавлены позже.

Я тоже чувствовал потребность в чем-то подобном. Тем не менее, я чувствую, что мы еще не готовы указать что-либо без введения какой-либо принципиально новой, топологически «большой» концепции (которая содержит несколько модулей), такой как «пакет» (единица кода в менеджере пакетов, таком как npm) или «контейнер». " (единица кода, которая может выполняться средой выполнения контейнера), потому что, как указано выше, мы не можем предположить, что существует какая-то внешняя файловая система, о путях которой мы можем говорить. Если у вас есть концепция «пакета» или «контейнера» (и то, и другое, по моему мнению, имеет смысл для разных фаз развертывания), вам будет гораздо проще конкретизировать, как работает разрешение.

Я также разделяю цель @littledan : все, что определено, должно иметь одинаковую интерпретацию внутри и вне среды JS/ESM. Таким образом, у вас может быть один пакет модулей wasm, который можно использовать как в Node, так и вне его.

Я разделяю сильное чувство, что нам необходимо начать координировать и согласовывать эти предложения, предвосхищая потребность в целостной концепции упаковки или контейнера друг с другом. Мы не должны исключать сеть, но мы также должны сохранить module sandbox нетронутыми. Это предложение связано с предложением WebIDL от @lukewagner и @jgravelle-google, предложением по интеграции ESM от @littledan и @linclark и стандартом WASI @sunfishcode @tschneidereit.

Я вижу ключевой потенциал связывания и взаимодействия между модулями Webassembly в возможности:

• связать модули, написанные на разных языках программирования, в одном потоке возможным и сравнительно эффективным способом, который может избежать сериализации или IPC.
• содержат уязвимости безопасности в ненадежных модулях (случайные, такие как переполнение буфера или злонамеренные) с изолированной программной средой модуля с четко определенными (например, приложениями) разрешениями (или, в терминах WASI, объектными возможностями), применяемыми извне модуля с интерфейсом модуля в качестве шлюза безопасности
• позволяют создавать экосистему универсальных модулей, которые можно легко повторно использовать без необходимости компилировать их в один модуль или даже в собственный исполняемый файл, что обеспечивает простоту использования npm install для модулей wasm с приемлемым компромиссом производительности.
• позволяют сократить время загрузки и кэшировать небольшие модули веб-сборки вместо большого монолитного «пакета» (менеджеры пакетов, такие как npm с tink, entropic и yarn, движутся в направлении хеширования/кэширования файлов на основе файлов с глобальным экземпляром singleton вместо отправка целых пакетов с копированием избыточных файлов.Также сборщики, такие как webpack, оценивают возможность отказа от связывания с http2.

Я думаю, что module sandbox Webassembly, который изолирует ненадежный код внутри модуля от внешнего, является чем-то совершенно уникальным и имеет потенциал для введения шлюзов безопасности при использовании стороннего кода с уязвимостями безопасности, такими как переполнение буфера или вредоносные модули, которые имеют остался незамеченным даже в сообществе с некоторыми сильными заявлениями об обратном со стороны профильных экспертов в сообществе.

Меня беспокоит то, что если мы не повысим осведомленность об этой функции песочницы модуля и не скоординируем эти межмодульные предложения, чтобы сохранить ее, мы можем потерять эту функцию еще до того, как она увидит свет, и, по сути, мы вернемся к процессу. песочницы. Я знаю, что существуют атаки по времени по сторонним каналам, которые позволяют считывать память из изолированной программной среды модуля, но, по крайней мере, она доступна только для чтения, и можно ограничить ущерб, если, например, модуль декодера jpg, используемый в тысячах приложений, скомпрометирован, он не может позвонить домой сразу отправить свой пароль, если его интерфейс имеет доступ только к буферам изображений, но не к сетевым API.

Если все сделано правильно, Webassembly может стать началом новой безопасной для детей (r) модульной экосистемы plug-and-play, которая поможет решить или, по крайней мере, сдержать пару эпидемических и серьезных проблем в существующих программных системах, таких как совместимость, безопасность, администрирование. усилия (контейнеры) и короткая продолжительность жизни кода.

Я рассматриваю этот подход, основанный на файловой системе, как прагматичный, который на самом деле может быть довольно близок к тому, что необходимо, поскольку папка с центральным index.js, как в модулях ES, оказалась полезной естественной следующей более крупной единицей модуля над одним файлом. это по-прежнему позволяет эффективно кэшировать файлы, сохраняя при этом файлы в зависимости друг от друга. Однако я считаю, что модуль не должен иметь возможность напрямую импортировать модули за пределы своего собственного каталога, там потребуется глобальная уникальная ссылка, такая как имя пакета npm, которое разрешается, и безопасность проверяется хостом.

Есть мысли по этому поводу?

Сохранение песочницы всего модуля — это хорошо. Однако я бы не стал сосредотачиваться на таких вещах, как происхождение модулей (зависит от реализации) и больше на отношениях между модулями. Например, даже внутри файловых систем (а файловых систем очень много, не все из них даже имеют понятие о файловых деревьях) существуют разногласия по поводу правил этих систем возможностей (восходящий обход, нисходящий обход, одноуровневые файлы, символические ссылки, и т.д). API JS WebAssembly даже не имеет понятия о месте хранения wasm, это просто капли данных, плавающие вокруг виртуальной машины.

@devsnek Полностью согласен, что это должна быть абстракция, не зависящая от реализации файловых систем или даже файловой системы, а более общая и безопасная концепция иерархического включения пакетов.

иерархическое сдерживание

Действительно ли он должен быть иерархическим в смысле дерева непересекающихся узлов? Или вы имели в виду ориентированный граф (т.е. "дерево с петлями")? Бывают ситуации (на самом деле не такие уж и необычные), когда нужна "нециклическая зависимость, замаскированная под циклическую зависимость" - зависимость A модуля M1 от a B модуля M2 и одновременно зависимость C от M2 на D в M1 , тогда как нет (простого/поддерживаемого/встроенного/возможного) способа сделать глубокий запрос в модуль и его данные, чтобы выяснить, действительно ли это цикл или нет. Разрешение таких зависимостей только на уровне модулей (дерево с непересекающимися узлами) сделало бы такие вещи невозможными, что излишне усложнило бы разработку и т. д.

@dumblob Для импорта вне поддерева:

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

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

В данном примере модуль Wasm jpg-decoder зависит от модуля Wasm simd-math . jpg-decoder объявит зависимость с глобальным уникальным идентификатором пакета, например [email protected]/simd-math@^1.3.4 , и запросит доступ к нему у своего родителя. Если родительский модуль имеет доступ к этому модулю, и родительский модуль считает его «безопасным для детей», доступ предоставляется, и импортированный модуль simd-math передается jpg-decoder .

Re: файловая система

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

У вас есть:

• бинарные файлы .wasm,
• API WebAssembly (C/C++/JS),
• Хост WebAssembly (рукописный JS, Webpack, интерпретатор WASI),
• Постоянное хранилище хоста (обычно файловая система),
• менеджер пакетов wasm,
• Центральный репозиторий пакетов,
• Инструменты, предназначенные для загрузки в этот репозиторий.

Так что, строго говоря, двоичные файлы wasm и API-интерфейсы создания экземпляров не обязательно должны учитывать файловую систему. Двоичным файлам нужен только стандартный синтаксис импорта, а API нужен только обратный вызов, которому он может передать проанализированные URI импорта. Например:

WebAssembly.instantiateStreaming(
    fetch('someFile.wasm'),
    {
        // ...
        resolveImport: (parsedURI) => { ... }
    }
);

Если предположить, что мы используем API, аналогичный приведенному выше примеру, то теоретически хосты могут хранить модули так, как они хотят; они могут извлекать данные из хранилища, не относящегося к файловой системе, например, интерпретируя URI как запросы к базе данных SQL.

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

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

В целом, все это возвращается к тому, что сказали @lukewagner и @ttraenkler , что нам нужно целостное определение того, что такое пакет (если не формат файловой системы, который они используют), прежде чем мы сможем выбрать схему импорта.

Действительно ли он должен быть иерархическим в смысле дерева непересекающихся узлов? Или вы имели в виду ориентированный граф (т.е. "дерево с петлями")? Бывают ситуации (на самом деле не такие уж и необычные), когда нужна "нециклическая зависимость, замаскированная под циклическую зависимость" - зависимость A модуля M1 от a B модуля M2 и одновременно зависимость C от M2 на D в M1, тогда как нет (простого/поддерживаемого/встроенного/возможного) способа сделать глубокий запрос в модуль и его данные, чтобы выяснить, действительно ли это цикл или нет. Разрешение таких зависимостей только на уровне модулей (дерево с непересекающимися узлами) сделало бы такие вещи невозможными, что излишне усложнило бы разработку и т. д.

Действительно ли эти полуциклические зависимости распространены, когда вы сжимаете внутримодульные подграфы?

Я ожидаю, что если вы будете рассматривать каждый модуль как отдельный узел, то в 99,9% случаев использования вы получите группу DAG импорта или дерево импорта.

Я думаю, что было бы разумно иметь схему разрешения импорта, которая предполагает, что зависимости могут быть циклическими внутри одного пакета, но в остальном они древовидны (модель npm) с некоторыми нециклическими исключениями (WASI, хост-библиотеки, одноранговые зависимости, и т.д).

Хорошо, после обсуждения этого предложения мне нравится его направление. Тем не менее, я не думаю, что есть необходимость требовать специальных префиксов или каких-либо других механизмов «безопасности». Их должен обрабатывать build-system/pkg-manager, а не интерпретатор. Защищенный pkg-manager должен иметь возможность правильно указать полную иерархию зависимостей и передать ее интерпретатору wasi, который затем интерпретирует то, что ему сказано. Это отношение _может_ выглядеть примерно так (полувалидный json):

[
  {
    "path": "./hash2k3jc/mod/foo.wasi",
    "dependencies": [
      {
        "import": ["mod", "bar"],  # (import "mod" "bar" ...)
        "path": "./hash2k3jc/bar.wasi",
      }
    ]
  },
  {
    "path": "./hash2k3jc/mod/bar.wasi",
    "dependencies": [],
  },
]

Здесь «mod foo» имеет 1 зависимость («mod bar»), которая сама по себе не имеет зависимостей.

Это плоский список файлов васи ( path ) и указывает, как сопоставлять операторы импорта с конкретными файлами васи ( dependencies с import и path ) .

Вы заметили, что эта система сборки предпочитает использовать хэши, чтобы быть на 100% явным и безопасным. Другие системы сборки (т. е. закрытые, внутренние) могут быть менее строгими, чтобы разрешить обновления на месте. Дело в том, что это представление может поддерживать любой подход.

IMO, это наиболее точно отражает https://webassembly.org/docs/dynamic-linking/ - не предъявляет абсолютно никаких требований к файлам wasi или интерпретатору, вместо этого выбирая максимальную гибкость и простоту.

Примечание. Я думаю, что файловая система для интерпретатора wasi уместна.

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

Примечание. Я думаю, что файловая система для интерпретатора wasi уместна.

У меня вообще-то совсем противоположное мнение : wink: . Уже в настоящее время существуют серьезные случаи использования WASM, где файловой системы нет и никогда не будет (например, новые или экспериментальные операционные системы, не имеющие файловых систем, а только программный интерфейс, подобный БД , обеспечивающий самую базовую адресацию постоянного хранилища — в самом простом случае). форме это может быть аппаратное энергонезависимое ОЗУ без какой-либо древовидной структуры, такой как файловая система). Таким образом, файловая система не должна быть обязательным условием для интерпретатора WASI (ИМХО, даже универсальный менеджер пакетов WASI не должен требовать хранилища, подобного файловой системе, а скорее должен работать с линейным постоянным хранилищем, чем с древовидным хранилищем или блочным хранилищем или ключ-значение хранения или чего-то еще).

Возможно, но я также не хочу требовать, чтобы все зависимости находились в одном непрерывном блоке памяти :smile: (например, используя position и size вместо path ). path можно использовать в качестве ключа в программном интерфейсе, подобном БД, не так ли? Может быть, мы должны назвать это как-то иначе, чем path ... может быть, key ?

Я считаю наличие механизма для поиска бинарных BLOB-объектов по ключу довольно важной функцией менеджера пакетов :smile:

в спецификации js мы на самом деле не даем модулям никаких спецификаторов. Мы выполняем разрешение с помощью (referringModuleInstance, importString) , и хост должен самостоятельно решить, следует ли разрешить этот импорт, где он разрешается и т. д. Я думаю, что Wasm в настоящее время еще более расплывчатый, и WASI может накладывать дополнительные ограничения, такие как «если результат разрешения (referringModuleInstance, importString) не должен быть транзитивно доступен для модуля импорта, выйдите с кодом xyz». Для wasmtime «транзитивно доступный», вероятно, включает в себя unix-подобные права доступа к файлам. Для чего-то вроде fastly/cloudflare это, вероятно, означает «часть одного и того же загруженного пользователем архива».