Enable publication at crates.io

[chrysn]

For exploring this crate, it would be helpful if it were uploaded to crates.io.

I've started adding a few version numbers in dependencies to make that work, but there are some showstoppers along the way which I'd like to track here:

• [ ] https://github.com/thvdveld/cc2538-hal/pull/2

• [ ] The published version of psa-crypto has no baremetal feature:

  error: failed to verify package tarball
  
  Caused by:
    failed to select a version for `psa-crypto`.
        ... required by package `edhoc-crypto-psa v0.1.0 (/home/chrysn/.cache/cargo-target/package/edhoc-crypto-psa-0.1.0)`
    versions that meet the requirements `^0.9.2` are: 0.9.2
  
    the package `edhoc-crypto-psa` depends on `psa-crypto`, with features: `baremetal` but `psa-crypto` does not have these features.
  
    failed to select a version for `psa-crypto` which could resolve this conflict

  (My guess is that that is a check that only happens when the feature is selected, and it didn't get selected during builds?)

This PR should contain valid changes with our without fixes to the above; once all of those are in, I'd appreciate if the maintainers would consider publication, as it helps with visibility and makes the documentation accessible more easily. (It'd also help dependent projects in their own publication, but I'm not at the point yet where I have something there).

[malishav]

This would be absolutely great but I am afraid there are several showstoppers ATM. Some comments:

• To have PSA build working we had to make some patches to the repository and we are using a fork. The patches have not been proposed upstream. @kaspar030 worked on this so could complement me.
• hacspec implementation of AES-CCM is also in a fork that has not been merged upstream.
• Unless you have a compelling reason not to, we plan to abandon support for CC2538, so this should tick one of your boxes.

[chrysn]

Hm ... it's certainly inconvenient when optional dependencies are not published, as crates.io doesn't allow them to be second-class.

A workflow I've been using in riot-wrappers a lot was to have a release mode where I'd commit a change that comments out all the optional stuff that's not published yet, then bump the version, publish, and revert the commenting-out commit right away. It's not pretty, but it works as soon as there is one back-end that is published. (And if it's not cc2538, I figure that Rust software implementations of crypto would sooner or later be on the menu, as they'd enable using this efficiently on x86 and WASM).

On the long run, is there a plan for how the backends could become decoupled? A model that has worked well for libOSCORE, albeit on the C side but with a very Rust mindset, was that the published library just depends on the platform to provide an implementation of the backend interface, and then some back-ends could be available via crates.io, while others wait for upstreams to be publishable.

[geonnave]

Just leaving a thought here, me and @malishav discussed over lunch today and we see the following possible paths to enable publication at crates.io:

• Try to upstream all changes relating to the psa crypto backend
• Find a set of pure Rust libraries that are no_std (and preferably stack-only), essentially creating a new "pure-rust" crypto backend and deprecating psa

[chrysn]

Is the #103 approach not viable? That would allow easily keeping backends around that are not fully on crates (PSA is surely nice to have).

[malishav]

Is the #103 approach not viable? That would allow easily keeping backends around that are not fully on crates (PSA is surely nice to have).

I am missing how #103 enables publication. Won't we still need a patched dependency to these crates (hacspec, PSA)? Could you elaborate?

[chrysn]

On Sun, Oct 08, 2023 at 04:00:06AM -0700, Mališa Vučinić wrote:

I am missing how #103 enables publication. Won't we still need a patched dependency to these crates (hacspec, PSA)?

If 103 is complete, the library crate itself won't have a dependency on any crypto implementation any more -- only applications will pull in that dependency. edhoc-rs will only depend on edhoc-consts and edhoc-crypto-trait (and the various -ead- crates, but I'd suggest doing the same game there).

Then the only dependency lib would have would be a dev dependency that's needed for the tests (on a remaining edhoc-crypto or directly on the selected edhoc-crypto-*), and that could either be commented out for releases (admittedly gaining little in complexity) or preferably moved into a tests crate, together with whatever is the entry point for hax.

[geonnave]

I had the same question as Malisa's, now I understand better. The changes on #103 are looking good and also #115 puts us a little bit closer to achieving this.

[chrysn]

This will need a complete redo with the latest main branch, but after https://github.com/openwsn-berkeley/edhoc-rs/pull/139, all dependencies should be shippable.

We may want to not hurry this, because I think that a few refactorings might bring the number of published crates down (so by not going to crates.io right away we avoid having some linger forever in 0.4): if we follow up on the hackathon plan based on Marco's designs, I think we won't need the 3 EAD crates in the dependency tree any more, and the consts can go into the main library.

[chrysn]

Closing as obsolete with the publications around 0.4.0.