3 ms·
> Also as a word of caution, don't use ungoogled-chromium binaries Unless you’re reading every line of code yourself before compiling it, I’d say you’re no saf
by djrogers 8y ago
> Also as a word of caution, don't use ungoogled-chromium binaries
Unless you’re reading every line of code yourself before compiling it, I’d say you’re no safer going you’re route than downloading the binaries offered from the same source.
- vemv 8y agoGenerally as a software developer I can assess which projects' source to trust, else I wouldn't be running thousands of transitive dependencies in my machine. Binaries which are unofficial to even ungoogled-chromium itself surpass my threshold of trust. But yes, one could take a further step and extract the interesting bits from this project and apply them to the official Chromium trunk.
- User23 8y agoHow do you assess the trustworthiness of thousands of transitive dependencies with a far greater number of code contributors in a way that scales? This is a serious question, and it would be great if you shared the solution you found. Thanks.
- vemv 8y agoI should admit that my procedures are only marginally better than an average developer's. Sadly I have no arbitrarily deep audit in place. I just try to pick solid projects, and assume / quickly check that their dependencies don't suck. Also I'm particularly cautious with npm (as opposed to rubygems or clojars). I should be looking into either (or both of): - setting up a multi-user macOS ('me' + 'admin' + 'dev'. I normally operate under 'me'. sudo is only ever executed under 'admin'. Developer tooling is installed for 'dev', an account which cannot access the rest of the filesystem) - using Docker and/or a VM for all dev activity, as a sandbox.
- Proven 8y agoThanks Sherlock! Shouldn't we all. Yet no one does it and it's unlikely to happen anytime soon.
- Phylter 8y agoIn spirit I'm with you but somebodies bound to do it and that alone makes it safer to compile from publicly provided source.