GitHubMirror/sshyp
1
0
Fork 0
mirror of https://github.com/rwinkhart/sshyp.git synced 2026-08-27 20:36:27 -04:00
Code Issues Packages Projects Releases Wiki Activity

[wiki] Add a postmortem documenting sshyp's flaws

Browse Source
This commit is contained in:
RandyTheSilly
2024-08-08 21:26:15 -04:00
parent 15e54cb25b
commit f774ff63aa
2 changed files with 28 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+1 -1
View File
@@ -5,7 +5,7 @@
pronounced as: 'sheep', 'shēp'
sshyp is a self-hosted, synchronized password manager for UNIX(-like) systems (currently Haiku/FreeBSD/Linux). It has been succeeded by [MUTN](https://github.com/rwinkhart/MUTN).
sshyp is a self-hosted, synchronized password manager for UNIX(-like) systems (currently Haiku/FreeBSD/Linux). It has been succeeded by [MUTN](https://github.com/rwinkhart/MUTN) due to its many [flaws](https://github.com/rwinkhart/sshyp/blob/main/wiki/postmortem.md).
sshyp is compatible with entries created by pass/password-store, as its original goal was to be like pass/password-store, but far more user-friendly to synchronize with a self-hosted server.
wiki/postmortem.md
+27
View File
@@ -0,0 +1,27 @@
## Postmortem
### Reflecting on the Flaws of sshyp
Due to being my introduction to the world of programming, sshyp contains many flaws that have been addressed with the creation of [MUTN](https://github.com/rwinkhart/MUTN).
Many of these flaws are the result of a lack of direction for the project.
In the beginning, sshyp was actually called "rpass" and was meant to be a simple wrapper for pass/password-store with rsync integration for synchronization.
I quickly ran into issues using rsync and pivoted to using sftp, thus necessitating the rebrand to "sshyp".
sshyp grew to become its own standalone password manager with no relation to pass/password-store (except for entry import compatibility).
In terms of technical flaws resulting from a lack of experience, here is a non-exhaustive list:
- Port jobs are unnecessarily complex and difficult to maintain; they made working on the project into a chore
- Extensions are unnecessarily complex and their functionality is better left to third-party clients
- Delegating functionality to extensions meant poor integration with the entry format, help menus, and shell completions
- Due to sshyp being a program with no underlying library, third-party clients are not very feasible
- Not having a library with the goal of change stability led to breaking changes in nearly every release of sshyp
- Python was a poor choice for my personal desire of portability, as dependencies must be independently installed on each system
- This led to me avoiding all non-standard libraries, which meant relying on system binaries for things like GPG and SSH
- This meant taking into account the versions of these binaries shipped by each distribution
- Because of this, sshyp was tied to OpenSSH (no support for other SSH implementations)
- This also meant launching separate SSH processes for each item being synchronized, making sshyp's synchronization _very_ slow
- Dynamically typed languages are a poor choice for beginners, as they allow for poor programming practices that create bugs
- With sshyp, I attempted to "save memory" by re-using variables for multiple purposes
- sshyp also checks variable types, rather than values, as a shortcut for determining a function's exit status
- sshyp combined the client and server into one package, resulting in lots of unreadable spaghetti code (especially with argument parsing)
- sshyp was designed in a way where it would be very difficult to port to non-UNIX-like platforms (it would basically necessitate a complete rewrite)
Developing [the successor to sshyp](https://github.com/rwinkhart/MUTN) forced me to confront these flaws and make a better product. It also allowed me the chance to re-consider each design decision; I found a better way of doing nearly everything.