[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #200 from Jock Tanner <tanner.of.kha at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #197)
>
> yesyes i know i said "no extra software" then suggested installing pyro.  if
> i'm installing vim and editing inside the chroot, you can sneak pyro in :)

Well, if “no extra software” is the main concern, then I guess my initial idea
of installing Pycharm locally in chroot will do just fine. It's completely
self-contained and requires no modification to the system, with the exception
of:

- setup folder (can be installed in home folder, no root required),
- global settings folder (also in home folder),
- project settings folder (can be put in '.git/info/exclude' or '.gitignore',
which I usually do).

Delete that 3 objects, and you'll never remember that you used it.

Actually, I've tried it already, and all went well with one exception: I can't
get binary extensions indexed. Yes, I'd like to walk through Hurricane
attributes in editor. =) I think it's worth a little investigation.

(In reply to Luke Kenneth Casson Leighton from comment #198)
> absolutely and critically dependent on the website - pypi.org - for its
> security.  do you GPG sign packages before uploading them? what happens if
> pypi - the website - is hacked?

Yes, it depends on pypi.org to store and transfer packages. And on SSL chain of
trust to know if pypi.org is authentic. If pypi.org or chain of trust are
hacked, we're all hacked.

On the other hand, the processing of signatures is significantly increasing an
attack surface by inclusion of the corresponding tools in the process, on both
client and server sides. And, if a process is more complex, people are tend to
make more mistakes.

The model of trust is also important here. Should I trust the owner of a
certain site? The issuer of a certain PGP signature? The ISP?

Thankfully, all components, involved in the process: twine, cheeseshop, pip and
setuptools − are quite versatile, and the process can be easily tailored to
your model of trust. You can use the VCS of your choice on a trusted host to
store packages, or set up your own PyPI.

You can also place your signature somewhere in your PyPI package, and then
modify setuptools to verify the signature along with the package hash before
running setup.py. I think it should be fairly easy to implement.

> a solution is to *pre-install* debian python dependency packages *before*
> running "python setup.py develop".  this *stops* pip going out and
> arbitrarily and blithely downloading random crap that's completely unsigned
> and you have absolutely no idea if it's been vetted.

Package pinning in pip is out there since I don't remember when. I think there
were some difficulties in pinning pip itself, but I suppose they are gone now.
pip should be ready for reproducible builds.

The problem of malicious packages in PyPI can be also mitigated by package
pinning, although this is more a social problem, than a technical one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.