SSH Stamp

[brainstorm]

Hello @mkj and sunset's community!

I've been VERY lucky to be awarded a grant to develop an application that bridges SSH (over wifi) with UART, mainly targetting Espressif chips, we called it: SSH Stamp.

Previously, SSH Stamp was depending on zssh instead of sunset, but when I was advised to switch to sunset (kudos to @projectgus for that among many other feats), we got it working (as a PoC):

https://github.com/brainstorm/ssh-stamp

Please mind the (big) gaps in security and functionality since we're in the process of signing the official MoU (financial agreement paperwork) with our sponsor, NLNet. The plan described in said MoU roughly mirrors the tasks listed in the project's public GitHub issue tracker and those tasks will be carried on as soon as the formalities are finished (hopefully this Friday the 16th)... that's because tasks finished before signing date cannot be part of the grant 🤷🏻‍♂️

I meant to write you personally, but I think that a community post makes more sense to broadcast the intentions ("ethos"?) with our project:

1. We'd like to contribute SFTP/SCP support TO SUNSET for the purposes of firmware updating the device (instead of "traditional" bootloader-based OTA mechanisms).
2. Since one of NLNet's mandatory participation requirements is getting a proper security audit of the project AND DEPENDENCIES, at least that's my expectation because sunset is central to our project, see my generated SBOM. So we think that us getting the grant will directly benefit your project.
3. SSH Stamp uses sunset as a "core" dependency to carry out its mission and we'd like to keep it that way since forks (friendly or otherwise) are usually not a very efficient (nor nice!) way to carry on good community-based, OSS work, which is what we feel energised to do here.

So, points for discussion:

1. Would you be open to accept/review/merge features such as (partial!) SFTP/SCP support?
2. Would you like to discuss (either here or in private via "brainstorm at nopcode dot org"?) about how you'd like/envision both projects to interoperate?: I'm thinking about, for instance, trimming down experiments (i.e polonium) and separating the demos from the "core" sunset crate to make the job of the security auditors easier (and enhance robustness/security of this crate in the process)?... potentially rethink the design of interfaces/traits if necessary (not at the moment)?

This writeup will most likely be edited/expanded in the next coming days as I think through all this, but I figured this could be a good start? :)

[mkj]

Hi! SSH Stamp looks like a nice project, thanks for getting in touch. I'd be happy to to help with review or other discussion. SFTP would be good to add - I started looking at it a little while ago but didn't get far.

I'm fairly flexible with how discussion happens - I guess it makes sense to have a bit of design discussion on larger features/direction before PRs just to avoid wasted effort, but either as github issues/discussion or emails are fine by me. Chat on matrix/discord/irc would also be fine (nearby timezones!). Moving the demos out makes sense, they're kind of hidden away anyway. I'll have a look at that.

In terms of APIs the current design has ended up as a bit of a Venn diagram intersection of constraints - certainly if you can see a better way to do something I'd be happy to make changes.

The unsafe/polonius bit you mention is an example of that - I was reluctant to relax my forbid(unsafe) policy, but really couldn't see a better way to implement it, and the polonius experiment was part of convincing myself that it was just working around language limitations. Maybe now async closures are stable, we could outsource the unsafe to an async polonius-the-crab!

[brainstorm]

Thanks for your quick response and for taking in @jubeormk1's recent PRs (#8 #9): he's currently tackling SFTP OTA update mechanism, if you have notes/snippets to share from when you started poking at it, let us know! ;)

I'm currently exploring the (flash) "config" side of things via esp_storage and sequential_storage::map and I see that most of the interesting bits I'd reuse are under embassy/demos, instead of inside sunset itself, i.e:

https://github.com/mkj/sunset/blob/main/embassy/demos/common/src/config.rs
https://github.com/mkj/sunset/blob/main/embassy/demos/picow/src/flashconfig.rs

Architecture-wise I'm a bit torn on whether config structs such as your SSHConfig belong to sunset "proper" or "third party" impls/demos like I'm doing now, as in: use cross-target, generic APIs vs just copy & paste and adapt it from demos to SSH Stamp's codebase.

There are interesting NVS wrappers to learn from such as https://github.com/tweedegolf/cfg-noodle, but it's going towards some more complexity and (seemingly) more towards std use cases? /cc @jamesmunns... and Espressif's own NVS "higher level abstraction" seems to be a bit in flux still?: esp-rs/esp-hal#3426 /cc @bjoernQ.

Anyway, I'm thinking out loud as I work through the code to implement what I want/need in brainstorm/ssh-stamp#23, for reference... and also I'm trying to find an "unified way" to have the SSH config infrastructure portable across targets without duplicating much code?

I'm not an expert about the polonius stuff since I've not found myself having those advanced borrow checker problems (:-!) but I'm not sure if it's ready for async yet?: danielhenrymantilla/polonius-the-crab.rs#15

/cc @Autofix

[jamesmunns]

it's going towards some more complexity and (seemingly) more towards std use cases?

for the record, it (what cfg-noodle will become) is std for now for initial testing/dev, but it very much is being written to target no_std. The hope is that the inside is complex, but the outside should be very straightforward to use.

[mkj]

Architecture-wise I'm a bit torn on whether config structs such as your SSHConfig belong to sunset "proper" or "third party" impls/demos like I'm doing now, as in: use cross-target, generic APIs vs just copy & paste and adapt it from demos to SSH Stamp's codebase.

My inclination for the time being would to copy and paste into SSH Stamp. Currently the only field that would be applicable to all Sunset servers would be hostkey. Having passwords is common, but the username->password mapping will vary, and the password hashing will vary depending on the machine capability (picow uses bcrypt which would be suboptimal for bigger machines, you'd use Argon2id or something instead).

Maybe some of the DemoCommon handling could be moved to a published crate if there is a clear good pattern, but at the moment probably easier to copy and paste to see what works.