<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>danShumway</author><text>I strongly disagree that this isn&amp;#x27;t an OS problem.&lt;p&gt;s&amp;#x2F;dependency&amp;#x2F;application&amp;#x2F;g in your comment. Dependencies are just applications that are controlled through code rather than via a mouse&amp;#x2F;keyboard. They&amp;#x27;re not special.&lt;p&gt;I run a minimal Arch setup at home for my development machine, partially for security&amp;#x2F;reliability reasons -- less software means fewer chances for something to go wrong. But this is a band-aide fix. A minimal Arch setup that forgoes modern niceties like a graphical file browser is not a general-purpose solution to software security.&lt;p&gt;When someone comes to me and says that an app is stealing their iOS contacts behind their back, my response isn&amp;#x27;t, &amp;quot;well, its your own fault for installing apps in the first place. Apps are bad.&amp;quot; My response is to say that iOS apps shouldn&amp;#x27;t have access to contacts without explicit permission.&lt;p&gt;The same is true of language dependencies. Both users and developers need the ability to run untrusted code. The emphasis on &amp;quot;try your hardest not to install anything&amp;quot; is (very temporarily) good advice, but it&amp;#x27;s ultimately counterproductive and harmful if it distracts us from solving the root issues.</text><parent_chain><item><author>marcus_holmes</author><text>This is why I don&amp;#x27;t think this is an OS problem. I think it&amp;#x27;s a developer mindset problem.&lt;p&gt;Dependencies are bad.&lt;p&gt;Every single dependency in your code is a liability, a security loophole, a potential legal risk, and a time sink.&lt;p&gt;Every dependency needs to be audited and evaluated, and all the changes on every update reviewed. Otherwise who knows what got injected into your code?&lt;p&gt;Evaluating each dependency for potential risk is important. How much coding time is this saving? Would it, in fact, be quicker to just write that code yourself? Can you vendor it and cut out features you don&amp;#x27;t need? How many other people use this? Is it supported by its original maintainer? Does it have a deep-pocketed maintainer that could be an alternative target for legal claims?&lt;p&gt;Mostly, people don&amp;#x27;t do that and just &amp;quot;import antigravity&amp;quot; without wondering if there&amp;#x27;s a free lunch in there...</text></item><item><author>geofft</author><text>&amp;quot;Solid SELinux policy&amp;quot; is really the hard part there.&lt;p&gt;When I pip install paramiko, I do, in fact, want it to have access to my SSH keys. When I pip install ansible, I want ansible to be able to shell out to OpenSSH to use my keys. If I write custom Python code that calls gpg, I want that custom code to be able to load libraries that I&amp;#x27;ve pip installed without the gpg subprocess being blocked from loading my keys. If I have a backup client in Python, and I tell it to back up my entire home directory, I want it backing up my entire home directory including private keys.&lt;p&gt;If I wanted an OS where I couldn&amp;#x27;t install arbitrary code and have it get to all my files for my own good, I&amp;#x27;d use iOS. (I do, in fact, use iOS on my phone because I sometimes want this. But when I&amp;#x27;m writing Python code, I don&amp;#x27;t.)&lt;p&gt;SELinux has been able to solve the problem of &amp;quot;if a policy says X can&amp;#x27;t get to Y, prevent X from getting to Y&amp;quot; for years. Regular UNIX permissions have been doing the same for decades. (Yes, SELinux and regular UNIX permissions take a different approach &amp;#x2F; let you write the policy differently, but that&amp;#x27;s the problem they&amp;#x27;re fundamentally solving; given a clear description of who to deny access to, deny this access.) Neither SELinux nor UNIX permissions nor anything else has solved the problem of &amp;quot;Actually, in this circumstance I mean for X to get to Y, but in that circumstance I don&amp;#x27;t, and this is obvious to a human but there&amp;#x27;s no clear programmable distinction between the cases.&amp;quot;&lt;p&gt;To be clear - I think there is potentially something of a hybrid approach between the status quo and what newer OSes do. For instance, imagine if each virtualenv were its own sandboxed environment (which could be &amp;quot;SELinux context&amp;quot; or could just be &amp;quot;UNIX user account&amp;quot;) and so if you&amp;#x27;re writing code in one project, things you pip install have access to that code but not your whole user account. I&amp;#x27;m just saying that SELinux hasn&amp;#x27;t magically solved this problem because all it provides is tools you could use to solve it, not a solution itself.</text></item><item><author>XorNot</author><text>This is literally what SELinux does, and has been able to do for years. We don&amp;#x27;t need &amp;quot;default block lists&amp;quot; - we need solid SELinux policy in all distros.</text></item><item><author>greggman2</author><text>I don&amp;#x27;t know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions.&lt;p&gt;Microsoft has started adding short life VMs. No idea if that&amp;#x27;s good. Both MS and Apple offer their App stores with more locked down experiences though I&amp;#x27;m sad they conflate app security and app markets.&lt;p&gt;Basically anytime I run any software, everytime I run &amp;quot;make&amp;quot; or &amp;quot;npm install&amp;quot; or &amp;quot;pip install&amp;quot; or download a game on Steam etc I&amp;#x27;m having to trust 1000s of strangers they aren&amp;#x27;t downloading my keys, my photos, my docs, etc...&lt;p&gt;I think you should be in control of your machine but IMO it&amp;#x27;s time to default to locked down instead of defaulting to open.</text></item></parent_chain></comment><story><title>Two malicious Python libraries caught stealing SSH and GPG keys</title><url>https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>greggman2</author><text>That sounds like a boil the ocean solution. We&amp;#x27;re never going to get all developers to be perfect, and besides there are evil devs as well so the solution has to be elsewhere.</text><parent_chain><item><author>marcus_holmes</author><text>This is why I don&amp;#x27;t think this is an OS problem. I think it&amp;#x27;s a developer mindset problem.&lt;p&gt;Dependencies are bad.&lt;p&gt;Every single dependency in your code is a liability, a security loophole, a potential legal risk, and a time sink.&lt;p&gt;Every dependency needs to be audited and evaluated, and all the changes on every update reviewed. Otherwise who knows what got injected into your code?&lt;p&gt;Evaluating each dependency for potential risk is important. How much coding time is this saving? Would it, in fact, be quicker to just write that code yourself? Can you vendor it and cut out features you don&amp;#x27;t need? How many other people use this? Is it supported by its original maintainer? Does it have a deep-pocketed maintainer that could be an alternative target for legal claims?&lt;p&gt;Mostly, people don&amp;#x27;t do that and just &amp;quot;import antigravity&amp;quot; without wondering if there&amp;#x27;s a free lunch in there...</text></item><item><author>geofft</author><text>&amp;quot;Solid SELinux policy&amp;quot; is really the hard part there.&lt;p&gt;When I pip install paramiko, I do, in fact, want it to have access to my SSH keys. When I pip install ansible, I want ansible to be able to shell out to OpenSSH to use my keys. If I write custom Python code that calls gpg, I want that custom code to be able to load libraries that I&amp;#x27;ve pip installed without the gpg subprocess being blocked from loading my keys. If I have a backup client in Python, and I tell it to back up my entire home directory, I want it backing up my entire home directory including private keys.&lt;p&gt;If I wanted an OS where I couldn&amp;#x27;t install arbitrary code and have it get to all my files for my own good, I&amp;#x27;d use iOS. (I do, in fact, use iOS on my phone because I sometimes want this. But when I&amp;#x27;m writing Python code, I don&amp;#x27;t.)&lt;p&gt;SELinux has been able to solve the problem of &amp;quot;if a policy says X can&amp;#x27;t get to Y, prevent X from getting to Y&amp;quot; for years. Regular UNIX permissions have been doing the same for decades. (Yes, SELinux and regular UNIX permissions take a different approach &amp;#x2F; let you write the policy differently, but that&amp;#x27;s the problem they&amp;#x27;re fundamentally solving; given a clear description of who to deny access to, deny this access.) Neither SELinux nor UNIX permissions nor anything else has solved the problem of &amp;quot;Actually, in this circumstance I mean for X to get to Y, but in that circumstance I don&amp;#x27;t, and this is obvious to a human but there&amp;#x27;s no clear programmable distinction between the cases.&amp;quot;&lt;p&gt;To be clear - I think there is potentially something of a hybrid approach between the status quo and what newer OSes do. For instance, imagine if each virtualenv were its own sandboxed environment (which could be &amp;quot;SELinux context&amp;quot; or could just be &amp;quot;UNIX user account&amp;quot;) and so if you&amp;#x27;re writing code in one project, things you pip install have access to that code but not your whole user account. I&amp;#x27;m just saying that SELinux hasn&amp;#x27;t magically solved this problem because all it provides is tools you could use to solve it, not a solution itself.</text></item><item><author>XorNot</author><text>This is literally what SELinux does, and has been able to do for years. We don&amp;#x27;t need &amp;quot;default block lists&amp;quot; - we need solid SELinux policy in all distros.</text></item><item><author>greggman2</author><text>I don&amp;#x27;t know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions.&lt;p&gt;Microsoft has started adding short life VMs. No idea if that&amp;#x27;s good. Both MS and Apple offer their App stores with more locked down experiences though I&amp;#x27;m sad they conflate app security and app markets.&lt;p&gt;Basically anytime I run any software, everytime I run &amp;quot;make&amp;quot; or &amp;quot;npm install&amp;quot; or &amp;quot;pip install&amp;quot; or download a game on Steam etc I&amp;#x27;m having to trust 1000s of strangers they aren&amp;#x27;t downloading my keys, my photos, my docs, etc...&lt;p&gt;I think you should be in control of your machine but IMO it&amp;#x27;s time to default to locked down instead of defaulting to open.</text></item></parent_chain></comment><story><title>Two malicious Python libraries caught stealing SSH and GPG keys</title><url>https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/</url></story>