Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancing portability and error handling in wolfSSH #558

Open
falemagn opened this issue Jul 21, 2023 · 1 comment
Open

Enhancing portability and error handling in wolfSSH #558

falemagn opened this issue Jul 21, 2023 · 1 comment
Assignees

Comments

@falemagn
Copy link
Contributor

Hi,

While integrating wolfSSH within FileZilla Professional Enterprise Server, which exposes its own filesystem abstraction, I found the need to modify some functions in wolfsftp.c. Specifically, I aimed to return to the client a more meaningful error status than WOLFSSH_FTP_FAILURE, where appropriate.

To achieve this without substantial refactoring, I've added new WS_ErrorCodes enums, which are then mapped onto the appropriate WS_SFTPStatus enums, alongside the existing WS_ErrorCodes.

However, I acknowledge that this solution is suboptimal for a couple of reasons. First, it requires extending WS_ErrorCodes with values that are exclusively used for translation into SFTP-specific ones. Second, the existing WS_ErrorCodes don't always match with the WS_SFTPStatus enums.

As noted in some of the comments in wolfsftp.c, it would be more effective to directly translate the specific underlying framework error tied to the failed operation onto the corresponding WS_SFTPStatus (and error message). But such an implementation would involve significantly more changes to the codebase, impacting parts I can't test directly due to lack of access to all platforms where wolfSSH is being used.

Thus, I've implemented changes that are specific to the FileZilla Server integration, and while they address the immediate need, I don't believe the patch is in a state that can be readily merged into the upstream. A more coordinated effort seems necessary to make wolfSSH more platform agnostic. This could involve less dependence on macros and structuring a more defined middleware API.

With this issue, I aim to open a discussion on these possibilities. If such changes are welcome, we can then agree on a roadmap moving forward.

@ejohnstown
Copy link
Contributor

I have started a branch where I am converting the file system function macro wrappers into functions of their own. I'm starting with your PR #556 and making sure everything is covered. The branch is in my repo at https://github.com/ejohnstown/wolfssh/tree/wolf-file
Is this similar to what you are talking about? (The error codes are definitely another issue.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants