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.
On 3/20/21 1:39 PM, 'Joel Dueck' via Racket Users wrote:
> Racket’s existing package system doesn’t pose any felt problems for me, but I
> still find this project very interesting.
>
> 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? 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? (Maybe if I were more familiar with Guix I
> would already know the answer to this)
>
> On Friday, March 19, 2021 at 3:56:18 PM UTC-5 Sage Gerard wrote:
>
>> 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 bytesfrom 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
