[ANNOUNCE] Xiden is now in beta
Sage Gerard
Hi folks,
About a year, 1384 commits, 489 tests, ~10k LOC, and 2" on my
waistline later, Xiden is in beta. An update is pending on the
default catalog.
https://github.com/zyrolasting/xiden
Xiden is a dependency manager I wrote to support use cases that I
could not get working with `raco pkg`.
Dependency management is hard, so Xiden was something I
originally didn't want to make. However, it ended up becoming one
of my most aspirational projects, and I'm proud of how it ended
up. If you could take the time to read a longer email, I'd like to
share a bit about how it might be helpful to you.
***
Like Guix, Xiden supports deterministic and atomic installations. Unlike Guix, Xiden is cross-platform.The Racket programs I write no longer have to assume that code comes in collections (outside of the built-in ones).
You can force dependencies of different versions to resolve to
the same data to avoid issues with non-eq? bindings [multiver].
Dependencies are accessed by symbolic links with names defined by
the dependent. So if two packages are called "uri", you can still
install them both under names that are meaningful to you.
Dependencies are fulfilled the same way, regardless if the
dependent is a human or more software.
Explicit, affirmative consent is fundamental to Xiden's workings. The default configuration is zero-trust (a.k.a. "Deny All"). Trust in cryptographic hash functions and public keys (or any bytes lacking either) must be declared to authenticate bytes from any source (even hard coded!). Not doing so will cause Xiden to reject data, but print an error that helpfully instructs you how to consent to the scenario. For those wanting convenience, there are "blanket" configuration options to consent to every instance of those scenarios. This makes Xiden a way to educate users on the exact shape and nature of the risks they accept with something from the Internet. In this sense, Xiden does not invent anything new with security. It only aims to get ahead of the "Allow Some" arms-race in other dependency managers like NPM.
Customization comes from a plugin module. You can use a plugin to integrate GPG, use a different archive format, or otherwise fill in gaps in Xiden's functionality. Xiden keeps authentication and integrity checking decoupled in this way so that users can transition on their own in the event a smart person finds a collision in a CHF, or cracks a cipher. Similarly, Xiden's data sources are any data type declared with a path to an input port, including queries to a catalog. A neat effect of this is that you can configure your own syntax for data sources in your command lines.
Even though I call Xiden a dependency manager, it is generalized
enough to be useful as a component for a CI system, as a
self-hosted OS development environment, or even as a back-end for
a more specialized dependency manager.
If this is something that interests you, please consider trying
the examples with the guide [ex][guide]. Like all software, Xiden
is not perfect, so I depend on your feedback to make Xiden better
for you, and to decide what interfaces should be declared stable.
[ex]: https://github.com/zyrolasting/xiden/tree/master/examples
[guide]: https://docs.racket-lang.org/xiden-guide@xiden/index.html
[ethos]:
https://groups.google.com/g/racket-users/c/4iI-SanIbzk/m/sGHYijLPAAAJ
[multiver]:
https://github.com/zyrolasting/xiden/tree/master/examples/01-differing-versions
-- ~slg
Joel Dueck
Sage Gerard
Hi Joel,
> On some future day when Xiden is out of beta, what are authors of “normal” Racket packages doing to make their packages available to Xiden users?
Basically cross-posting to zcpkg.com (don't visit, nothing is
there yet). I'd expect the bureaucracy of signing/hashing would be
handled by a specialized client, since I'm trying to keep Xiden
open-ended. The value would be in added safeguards (better
crytographic hash functions + hosting signatures), and additional
options for transporting artifacts (e.g. torrents). There's also
the fact that Xiden handles software in general, not just Racket
packages. So I'd give this answer to the same question in other
mailing lists.
> For example, are we zipping, hashing and signing every “release” and uploading it somewhere (our own web server or a 3rd party catalog)? Or is the typical Xiden user manually creating their own catalogs and packages from others’ code after a thorough vetting?
One can do all of that now. I'm not asking for people to try that
here, but it would be helpful to know what their experience was
like if they tried.
Vetting is a case-by-case problem that deals more with trust than
Guix-specific knowledge. For example, Racket downloads do not
include signatures, and use SHA1 digests. The self-hosting example
in the repository installs a self-contained Racket + Xiden stack,
and the Racket installation script is signed with my private key.
That's why package definitions identify me as a provider (as in
"distributor") and not as an author. That's an entirely different
picture from a vetting perspective, because someone might trust a
Racket distribution simply because it came from racket-lang.org
over HTTPS, but they might not want to trust my public key outside
of the context of that example. But if this were a Python source
release, I'd just paste in the related signature and let the user
affirm trust in a public key belonging to Pablo G. Salgado.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/932af4c4-3713-4305-970b-e608e434a71en%40googlegroups.com.
-- ~slg