Software supply chain looks out-of-control

[ldoolitt]

The concept behind simp_le looks great! I'm a big believer in separation-of-privilege.

Attempting the install (pip install -e .) on a dedicated web server gave me a bunch of chatter, including

Downloading idna-2.7-py2.py3-none-any.whl
Downloading acme-1.29.0-py3-none-any.whl
Downloading cryptography-37.0.4.tar.gz
Downloading josepy-1.13.0-py2.py3-none-any.whl
Downloading mock-4.0.3-py3-none-any.whl
Downloading pyOpenSSL-22.0.0-py2.py3-none-any.whl
Downloading pytz-2022.1-py2.py3-none-any.whl
Downloading six-1.16.0-py2.py3-none-any.whl
Downloading requests_toolbelt-0.9.1-py2.py3-none-any.whl
Downloading pyRFC3339-1.1-py2.py3-none-any.whl
Downloading requests-2.28.1-py3-none-any.whl
Using cached cffi-1.15.1-cp39-cp39-linux_armv7l.whl
Using cached pycparser-2.21-py2.py3-none-any.whl
Downloading charset_normalizer-2.1.0-py3-none-any.whl 
Downloading urllib3-1.26.10-py2.py3-none-any.whl
Downloading certifi-2022.6.15-py3-none-any.whl
Building wheel for cryptography (pyproject.toml) ... error
      error: can't find Rust compiler
      This package requires Rust >=1.41.0.

IME this explains issue #149, at least in the abstract. It also explains why you suggest working in venv or even Docker.

I'm not a Docker person, and venv won't help me with rust. I won't give up, though. I'm comfortable with (s)chroot on a beefy workstation, and can use the sshfs trick shown in the wiki Examples page to run simp_le there instead of the tiny little non-x86 server. Wish me luck.

Minor point: README.rst mentions an examples directory; looks like that went away in June 2019 with commit d6b8403.

[zenhack]

Best of luck!

FWIW, I'm not really "a docker person" either, but at some point other contributors wanted it (and maintained it -- I'm not sure the docker image works anymore).

I'm not sure I agree the supply chain stuff is "out of control," but in any case it seems like the right way forward is to pin down the issue more precisely -- is your reaction just that Rust seems like a disproportionately large dependency? I think it's being pulled in as a dependency of the cryptography package, and yeah I remember there being some drama about that dependency when the maintainers of that package added it, which is probably not hard to learn about by googling. I think their perspective is that the trade-off is worth it for their project given the extra safety they get from doing things in Rust instead of C, and my own stance is they're probably right.

[zenhack]

(btw, thank you for pointing out the README bitrot; I've fixed that and a couple other things I noticed while doing so).

[ldoolitt]

Sure, I came to the same conclusion about the specific failure I ran into: the cryptography package depends on a rust-produced binary. Somehow that binary is ready-made for x86-64 and pulled in automagically by pip. But for my embedded server's architecture, the binary isn't there, and I sure don't have rustc installed there.

I'm reading this as a general issue with "modern" software, and not something you can personally do a lot about. The key word here is "chain". You only specify where to start pulling -- and don't have a lot of control over how many links are attached.

Maybe you can keep problems like #149 from popping up as often if you pin versions tighter. Maybe also document what exact versions have been tested.