[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 #198 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jock Tanner from comment #194)
> (In reply to Luke Kenneth Casson Leighton from comment #192)
> > ahh hang on. that will need discussion under a separate bugreport (jock csn
> > you raise one, 4am here at thr moment).
> 
> Sorry I didn't mean to wake you up (or kept you awake, whatever).

my choice :)

> >  pip is seriously compromised (zero
> > security and zero replicability).
> 
> Yikes! As a maintainer of a PyPI package, I have great difficulties even
> imagining pip has such a serious flaw. Honestly.

it's set up in a similar way to nodejs.  not quite as bad as this but nearly.

https://www.eweek.com/security/node.js-event-stream-hack-exposes-supply-chain-security-risks

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?

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.

but (A) those packages have to exist and (B) you have to do a careful analysis
of the requirements.txt and the setup.py *before* running setup.py

therefore off it goes, wandering blithely through an *UNVETTED* web site
installing *ARBITRARY* software.

https://www.zdnet.com/article/twelve-malicious-python-libraries-found-and-removed-from-pypi/
https://www.bleepingcomputer.com/news/security/ten-malicious-libraries-found-on-pypi-python-package-index/
https://www.reddit.com/r/linux/comments/709a4t/pypi_compromised_by_fake_software_packages/
https://developers.slashdot.org/story/19/12/04/1430223/two-malicious-python-libraries-caught-stealing-ssh-and-gpg-keys

that last one was only 3 months ago.

hence the bugreport.

> > oh, it is not for coriolis2, it's for sfpy.
> 
> Yes, it's for sfpy. I did not bring a new dependency, I only mentioned it
> explicitly. Does it really deserves a bug report?

mm... yeah.  we need to make sure that what we're doing is properly replicable:
that "arbitrary installs and upgrades" don't screw things up.

it's bad enough that nmigen's dependencies aren't packaged for debian, so we
*have* to rely on pip.

that means that when it comes to replicable builds, we will have to *manually*
install nmigen's dependencies - giving specific versions of them - in order to
*stop* pip going out and arbitrarily grabbing "The Latest And Greatest
Whatever".

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