On-Premise package server mirror
-
I'm trying to convice my higher-ups that we need an on-premise package server mirror for npm/nuget and the like (I have ProGet in mind, but feel free to suggest others).
The problem I have is that I cannot come up with a good risk/damage assessment. The damage it might do to us when one of our builds is not working anymore can be calculated rather easily, but what is the risk of that happening?
From the top of my head I know of two instances in the recent past where npm fucked up which would have impeded us. How do I calculate a "good-enough" risk factor from this?
Also: What are actual disadvantages of storing everything in the repo? Besides the evangelical "it's not part of the source, so it shouldn't be in there" which a manager will never care about.
-
@ApoY2k said in On-Premise package server mirror:
The damage it might do to us when one of our builds is not working anymore can be calculated rather easily, but what is the risk of that happening?
@ApoY2k said in On-Premise package server mirror:
From the top of my head I know of two instances in the recent past
There you go. Risk: Happens about twice in $period.
See first google result:
Essentially, you'll come up with a statement that basically boils down to "There's a X percent probability $Fuckup will happen, when it does, it will cost $Damages" Simple as that.
You can also represent it as time lost based on inverse percentage of that probability:
I.e. If there's a 3 percent chance of this happening once only in the whole year, that means you lose almost eleven full days (not work days) of productivity for everyone that needs that thing, and that multiplies for each occurance.
@ApoY2k said in On-Premise package server mirror:
Also: What are actual disadvantages of storing everything in the repo? Besides the evangelical "it's not part of the source, so it shouldn't be in there" which a manager will never care about.
Personally, the only thing I think of is space savings. In many source control systems, once something is checked in, it's checked in forever unless you use special commands to obliterate history. When storing lots of binary blobs (
packagesfolder, for example) and keeping it up to date, that means that older packages that may not be useful anymore just add dead weight (and, depending on the system, may be required to download).On the plus side, that means (in theory) you're completely independent of the upstream package repo and can always and forever build prior versions (if that's a thing you may want to do).
-
One risk that often will tip the balance for management I the "License Hostage" issue. I have encountered it directly with 2 different packages that clients were using (fortunately both escaped the trap - others have not been so lucky).
-
@TheCPUWizard said in On-Premise package server mirror:
"License Hostage"
I think I know what you mean, but I'm not too sure. Can you elaborate?
-
@TheCPUWizard said in On-Premise package server mirror:
License Hostage
If you mean "someone adds a package that is incompatible with our product's license to our product", ProGet has a way of shutting that whole thing down.
--
In any case, you can get a free edition license for ProGet as part of the installer, and changing the license key doesn't require reinstalling, so I suggest setting up an example instance on your workstation or a VM to show your higher-ups what it looks like.
-
@ben_lubar said in On-Premise package server mirror:
I suggest setting up an example instance on your workstation or a VM to show your higher-ups what it looks like.
No one cares what it looks like. They care that it costs X and helps prevent $Y damage hat happens with Z% risk.
All I'm working on right now is figuring out Y and Z.
-
@ApoY2k said in On-Premise package server mirror:
@ben_lubar said in On-Premise package server mirror:
I suggest setting up an example instance on your workstation or a VM to show your higher-ups what it looks like.
No one cares what it looks like. They care that it costs X and helps prevent $Y damage hat happens with Z% risk.
All I'm working on right now is figuring out Y and Z.
Just make some shit up. I am fairly certain it is what real
statusticiansstatistician do most of the time.Need coffee, and kids that don't wake up at 6am.
-
Yeah, make it up or at least get a genuine risk and make it sound worse than it is.
-
@Polygeekery said in On-Premise package server mirror:
kids that don't wake up at 6am.
Got you beat. 5:30 today
@loopback0 said in On-Premise package server mirror:
get a genuine risk and make it sound worse than it is.
I guess I'll go about this route then... now I only gotta find some more examples where package managers decided to fuck up...
-
@ApoY2k said in On-Premise package server mirror:
now I only gotta find some more examples where package managers decided to fuck up...
Don't just focus on the ones that would have fucked you up, but the frequency it happens in general.
-
Maybe an easier sell would be:
- dependable build (showcase the leftpad case)
- deployment and versioning mechanism for internal modules
When we had a private NPM, those were the primary benefits. Security improvement is mostly theoretical IMO.
-
@ben_lubar am I the only one getting connection refused?
-
-
@ApoY2k said in On-Premise package server mirror:
@TheCPUWizard said in On-Premise package server mirror:
"License Hostage"
I think I know what you mean, but I'm not too sure. Can you elaborate?
Nearly every package is convered by a License (either explicitly or implicitly). So a software company writes a license that says "if you use this you must give us access to all your software" [or some such]. They also bury in "phone home code"....
Developers never read the licenses [nor are they usually lawyers]….
Time passes and the company gets a legal demand letter [one actually filed with a court] and the option to settle for some amount of money. The cost of a legal defense is likely to be more that then amount for a settlement, so the company merely pays.
This is wrong/immoral/evil/et. al. but multiple courts have judged it to be perfectly valid from a legal point of view [most cases are being appealed].
-
@TheCPUWizard said in On-Premise package server mirror:
Developers never read the license
I read the licenses and also put them on anything I make, but I am a giant bee.
-
@swayde said in On-Premise package server mirror:
@ben_lubar am I the only one getting connection refused?
No inedo.com outages today as far as I can tell:
-
@TheCPUWizard said in On-Premise package server mirror:
Developers never read the licenses
[citation needed]
Missing Software License · Issue #44 · BenLubar/df-ai
If you want other people to be allowed to copy, modify, and redistribute their own versions of this project you need a permissive license. Without it, normal copyright applies. I would recommend th...
-
@TheCPUWizard said in On-Premise package server mirror:
Nearly every package is convered by a License
Without a license, you'd not be allowed to use the package at all. Though absence of an explicit license for published software will probably be interpreted as presence of some implicit license, I have no idea what the terms of the implicit license would be.
-
@ApoY2k It's been less than a month since NPM let an infected ESlint package steal everyone's passwords, so...
-
@ben_lubar said in On-Premise package server mirror:
@swayde said in On-Premise package server mirror:
@ben_lubar am I the only one getting connection refused?
No inedo.com outages today as far as I can tell:
My forum went down today for unknown reasons. Had to restart the service.
-
@ben_lubar said in On-Premise package server mirror:
@swayde said in On-Premise package server mirror:
@ben_lubar am I the only one getting connection refused?
No inedo.com outages today as far as I can tell:
Hmm, I still get connection refused.
I'd post a screenshot but doing that on Android is work
-
@Magus said in On-Premise package server mirror:
@ApoY2k It's been less than a month since NPM let an infected ESlint package steal everyone's passwords, so...
True, but would an on-premise mirror really help with that?
-
@ApoY2k Normally the idea is that you limit when people get updates, so things like that and leftpad don't happen.
-
@Magus There is that thing were people feel safe because opensource but nobody read the codes. I could bet nobody is minuciously checking the packages in our mirror. I wonder if mavencentral and bintray/jcentral are any safer than npm?
-
@sockpuppet7 Probably not, tbh, though the possibility could exist if someone is paid money to care.
High availability - Wikipedia
