We tend to avoid using github repos, but go for published packages from the usual sites; Nuget, Pypi, Npm etc, using Repository and Firewall from Sonatype to act as a proxy between us and the package repos. All packages are analyzed and tagged with various metadata by Sonatype. Firewall lets us define policies for what we can use, and will filter out everything else.
This only works for published dependencies, but based on a couple years experience it works really well. No issues with malware (so far), we don't let packages with known vulns into our codebases and we are notified if a vuln is discovered in something we use.
I've referred to that clip in past conversations about future moon missions revisiting relics like the Apollo 11's flag and the first footprints.
People tend to forget every manned moon landing site is also a launch site. Sure, there's no atmosphere to disturb the dust since we left, but the liftoff exhaust didn't care much about that.
A launch that knocked over the flag over eight meters away[1] almost certainly also left a smoothly blown-out depression where most of the first footprints were, no matter how inert the site has been since then.
And beside that, between the two of them there was enough traffic in and out of the module that the first footprints were probably stepped on over and over again.
The LEM separates at launch from the moon. The descent module remains behind. When the ascent engine fires, it blows the gas on top of the descent module below it. The descent module, having a mostly flat top, would direct gas sideways, blowing away the tall flag, but not the footprints.
That’s actually an interesting thought… on earth, such a redirection of the exhaust gas wouldn’t mean much, since the resulting turbulence would cause the surrounding air to get caught up in the wake of the exhaust anyway (making everything around it disturbed), but with no atmosphere? The result would look a lot different. I still think the footprints would be affected because the exhaust deflection is not perfect or complete, but it’s interesting to think about the idea of exhaust traveling thousands of miles per hour just a few feet above the lunar surface while the surface itself remains undisturbed.
Not sure about jfrog, but Sonatype does something similar. They basically hash all components/packages from a bunch of different repositories, and then tag the hash with various metadata you can use to create policies.
I started using this in my org a couple years back, and we've ended up using it to check commercial software as well just to get an overview of known components, vulnerabilities and things to watch out for.
I really wish the big repositories would invest more in useful mechanisms; when we looked into this before making our decision, the only repository with any kind of checking was Maven Central. Nuget had support for author signing and repository signing, and Pypi (at the time) author signing. As far as I remember none of the other repositories had any verification of anything including the git repo, so you couldn't even determine what commit hash the code was based on or who was behind it.
I know but people still need cars and they will buy it even if it costs twice as much. When public transportation is not convenient and reliable there is not really much choice.
people will continue to take cars whenever cars are faster than public transit. Compare your travel route options on Google maps. My partner commutes about 20 miles to work and driving takes 45 min to an hour and 1/4 depending on time of day. even though we live a mile and 1/2 from a major train stop, it would take her an 1 1/2 to 2 1/2 hours to use public transportation to get to work.
until public transit fixes the time inefficiency problem, it's fighting an uphill battle.
First thing I thought of was food commercials, where the goal isn't to replicate the actual looks of the food on offer, but rather what people would like the food to look like. [1] Nice video though, I'm only used to shops having poor plastic imitations or sun-bleeched photos in their windows, if anything at all.
In many markets it is illegal to use fake food in commercials.
But we (I used to work at an agency sometimes doing food commercials) would go to great lengths getting the perfect specimen from the factory, the perfect vegetables, and so on. Multiple professionals would coordinate the cooking and timing of the process. The end result would be the real thing, it might not be edible due to other things at the set (like cheese kept too warm too long), but it would be a true serving of the food.
This is a universal problem in most of package repositories regardless of language. PKI is difficult, and for it to work the users have to do some homework and place trust somewhere.
In a healthier OSS ecosystem, we'd have people counter-signing packages after they've vetted them. If Google approves something through to production, then it's probably okay for you too.
This wouldn't be a bad extension to the GNU license really - requiring reciprocal review.
Yeah, that could work, at least for larger orgs. Not so sure the majority of users would comply with such sn extension, or even have the knowledge to review for eg. security issues. Having a working PKI solution that could work regardless of ecosystem would be awesome. If nothing else, I can research which key eg. Microsoft uses, and then allow anything signed by that key as an initial threshold.
Making it a requirement of using something commercially would add a lot of transparency though. The concept of "software bill of materials" has increased interest now, and this would be a part of it: if you're using something then you sign it and publish the signature which then declares an acknowledgment that it was reviewed in some way.
Absolutely, but I fear such a solution would lead to a lot of people signing just to be compliant, not beacause they did a thourough job reviewing. If we could connect it to a reputation somehow, it might have something going for it
This only works for published dependencies, but based on a couple years experience it works really well. No issues with malware (so far), we don't let packages with known vulns into our codebases and we are notified if a vuln is discovered in something we use.