In go, vendoring dependencies just copies the deps out of the module system into the local tree and it's managed the same as not vendoring. It won't even build of the go.mod has changed without also updating the vendor tree.
Right - a copy is a cache, and you have to manage that; when to update it, when vulnerabilities are discovered in the deps you have copied, it's up to you to change the version in your cache.
for the non technical folks: imagine there was a password that if you guess it, you can impersonate *any website on the internet*
now imagine the password is literally the number 4
As a frequent internal tool writer, I’d say it’s a fact of life but an undesirable one. I’m always trying to avoid pausing for credentials in the middle of a run, either by doing them right at the beginning or by using some sort of durable credentials system like ssh keys.
There’s always two people at every company who refuse to set up auth automation though, so you end up handling it. They are very stubborn. Even when it trips them up in front of observers while executing an urgent task, I’ve only occasionally convinced them to agree to set up trust instead of typing a password every single time.
Which is to say, I have to support password prompts even though they drive me up the wall.
With curl|bash you are literally getting anything that happens to be in that script. These are frequently poorly constructed, so not check hashes or pin dependencies they install.
Even security companies (see trivy supply chain attack) get these badly wrong.
I'm not replying here to say one is better than than the other (npm has obviously had its share of problems) but rather to combat claims that curl|bash is somehow safer, it absolutely is not, in fact it's all the bad stuff about npm without the pretense of being potentially safe.
That's what I thought at first but then discovered:
> universal clipboard is synchronized over internet, it is not done trough cable connection. it uses apple continuity service, what you put into UC is uploaded into apple cloud,..
reply