search

parallaxsecond / parsec-book

Parsec documentation
https://parallaxsecond.github.io/parsec-book
Apache License 2.0
12 stars 17 forks source link

Add a Parsec Stability page #108

Closed hug-dev closed 3 years ago

hug-dev commented 3 years ago

This page describes what stability is for the Parsec service and how it is enforced/tested.

This is a work-in-progress page to put the framework in place.

I think the plan would be:

I think the ideal plan would be to have a stable Parsec version at the end of this, 0.X.0 for people/packagers to try out. After a few months of fixing stability problems, if they arise, we should then be confident enough to tag Parsec 1.0.0.

I am still worried about the C-STABLE rule and not sure yet what it means for Parsec, a binary application. I think it would translate to the exact content of the stability document.

Please feel free to review the vocabulary I used and let's discuss it. For example the stability definition, "communication channel", "stability requirement", "stability enforcement", etc... Feel free to indicate if I missed anything.

Fix #83

paulhowardarm commented 3 years ago

One other question I had was on the relationship between version numbers: the Parsec service version number, wire protocol version number, and provider/authenticator version numbers. Do we need to define how these relationships work and how they relate to the whole Stability goal?

I think I would avoid getting into anything like that, because it has the potential to create an entirely unnecessary set of additional constraints on what is already quite a difficult problem. I am comfortable with letting different aspects of versioning drift and evolve at their own pace. I'd be wary of getting into situations where we need to artificially bump numbers or massage them to suit some over-arching schema.

hug-dev commented 3 years ago

One other question I had was on the relationship between version numbers: the Parsec service version number, wire protocol version number, and provider/authenticator version numbers. Do we need to define how these relationships work and how they relate to the whole Stability goal?

I think I would avoid getting into anything like that, because it has the potential to create an entirely unnecessary set of additional constraints on what is already quite a difficult problem. I am comfortable with letting different aspects of versioning drift and evolve at their own pace. I'd be wary of getting into situations where we need to artificially bump numbers or massage them to suit some over-arching schema.

I think this only defines the service version. As everything is linked together it would also be including the providers. Note that the core provider's version is the same as the service currently (the one in the Cargo.toml file). The wire protocol version is used as part of the stability in between the service and clients.

hug-dev commented 3 years ago

Not wanting to inflict scope-creep on this PR, but somewhere along the line I think we need to address the story of how Parsec and Mbed TLS versioning intersect, both in the back-end (Mbed provider) and the front-end (C client using the SE driver).

The stability document I wrote was only focusing on the Parsec service but not the clients. I thought that the semver rules where enough there to describe staiblity. I guess things are a bit more complicated for the SE driver, and we should maybe open a separate issue there. This makes we think that we would also need one on the parsec-tool.

What are our goals here? As soon as there's an Mbed LTSR containing the PSA interfaces, should we expect Parsec to "just work" with whatever is installed in a distro, rather than grabbing specific versions as we do now? For the back-end, it would be nice to not have to link statically to Mbed Crypto, because it creates a maintenance burden within Parsec - we have to update to new versions to get patches for bugs/CVEs.

For the Mbed Crypto provider, Parsec is relying on the psa-crypto crate. Currently, Mbed Crypto is compiled and linked statically during the build of this crate but if it is given the MBEDTLS_LIB_DIR and MBEDTLS_INCLUDE_DIR environment variables it will dynamically link with that instead. Ideally we would like something more robust like for the tss-esapi crate where pkg-config is used to find the Mbed Crypto library location so that no environment variable is needed. Because the ABI of Mbed Crypto is not stable between versions, Parsec will have to be recompiled with the newer version of Mbed Crypto in order to generate the good mappings.

For the front-end, the question is whether a client application could do something similar - just use whatever MBed Crypto is sitting on the target platform, and successfully register the SE driver. I don't think Parsec can solve this problem in isolation. It would have to be a dialogue with Mbed about what stability looks like on their side as well, both for API and ABI. But I can appreciate that this document might not be the place to try to address that question. It needs to be on the overall stability goals radar, however.

That is currently possible for the SE driver, it can be compiled by passing the MBEDTLS_INCLUDE_DIR environment variable poiting to the header of the current Mbed Crypto version used. Because of the similar ABI stability, it would have to be recompiled if the Mbed Crypto version changes.

hug-dev commented 3 years ago

Im creating the 10 specific issues and will make a PR with their link here after.