4 ms·

These days, I would never run publish myself in a corporate environment. A script that is triggered on pushing tags should take of that to precisely avoid such

by sh4dow 8y ago

These days, I would never run publish myself in a corporate environment. A script that is triggered on pushing tags should take of that to precisely avoid such human errors. And of course changes to this script have to be reviewed. Also, a .rc file (package manager chosen by the team) with a private registry that refuses to publish unless done automatically by the pipeline set in the root of every project. The only reason I find it understandable how it could happen at a major bank (these days, they should have a sizeable team that takes care of security measures like I described) is that this was 3 years ago. Publishing to private registries was relatively new back then, so people didn't have proper publishing workflows yet. I mean... I guess mistakes can still happen. But on a scale of 1-10, I would find such a mistake far less excusable today considering the circumstances. Small, inexperienced team, maybe constant deadline pressure - more excusable. Duh...

mstade 8y ago
> These days, I would never run publish myself in a corporate environment. A script that is triggered on pushing tags should take of that to precisely avoid such human errors. And of course changes to this script have to be reviewed. > > Also, a .rc file (package manager chosen by the team) with a private registry that refuses to publish unless done automatically by the pipeline set in the root of every project. This is how we do it. Publishing is locked down to specific service accounts, with credentials set up in a CI environment with locked down build configurations. Publishing to the internal registry is not possible unless you have these credentials, and you don’t. There’s a whole process for retrieving keys. Publishing to the internet isn’t possible due to a firewall just killing those requests dead. You could probably do it via a proxy, but you’d break your contract and probably be fired if not worse. People complain about the locked down build configurations, until they need help at which point standard build configurations mean they actually get support, as opposed to “good luck; have fun!” Source: I work for a major bank. (Presumably not the one this story is all about!)

by sh4dow 8y ago

mstade 8y ago

> These days, I would never run publish myself in a corporate environment. A script that is triggered on pushing tags should take of that to precisely avoid such human errors. And of course changes to this script have to be reviewed. > > Also, a .rc file (package manager chosen by the team) with a private registry that refuses to publish unless done automatically by the pipeline set in the root of every project. This is how we do it. Publishing is locked down to specific service accounts, with credentials set up in a CI environment with locked down build configurations. Publishing to the internal registry is not possible unless you have these credentials, and you don’t. There’s a whole process for retrieving keys. Publishing to the internet isn’t possible due to a firewall just killing those requests dead. You could probably do it via a proxy, but you’d break your contract and probably be fired if not worse. People complain about the locked down build configurations, until they need help at which point standard build configurations mean they actually get support, as opposed to “good luck; have fun!” Source: I work for a major bank. (Presumably not the one this story is all about!)