How do you decide what externally available packages to store/cache in artifactory?
I’m curious, as I also deal with this tension. What (human and automated) processes do you have for the following scenarios?
1. Application developer wants to test (locally or in a development environment) and then use a net new third party package in their application at runtime.
2. Application developer wants to bump the version used of an existing application dependency.
3. Application developer wants to experiment with a large list of several third party dependencies in their application CI system (e.g. build tools) or a pre-production environment. The experimentation may or may not yield a smaller set of packages that they want to permanently incorporate into the application or CI system.
How, if at all, do you go about giving developers access via jfrog to the packages they need for those scenarios? Is it as simple as “you can pull anything you want, so long as X-ray scans it”, or is there some other process needed to get a package mirrored for developer use?
Where i am, every package repo - docker, pypi, rpm, deb, npm, and more - all go through artifactory and are scanned. Packages are autopulled into artifactory when a user requests the package and scanned by xray. Artifactory has a remote pull through process that downloads once from the remote, and then never again unless you nuke the content. Vulnerable packages must have exceptions made in order to get used. Sadly, we put the burden of allowances on the person requesting the package, but it at least makes them stop and think before they approve it. Granting access to new external repos is easy, and we make requesting them painfree, just making sure that we enable xray. Artifactory also supports local repos so users can upload their packages and pull them down later.
In case it's useful to anyone: another implementation of this idea is Weeve https://shop.weeve.ie I bought one of their books (a study in scarlet) but it wasn't great. Lots of mistranslation, especially later on in the book. The general idea seemed to work well though, with better implementation I think it could really help my french.
I'll give this one a try, being able to add my own books is particularly exciting.
I guess this is mostly relevant for software that runs on shared infra, sends requests to a url provided by an attacker (e.g. webhooks), and uses a SOCKS5 proxy?
The article was too vague for me to really understand, but I think it's suggesting something like Brandur's deeply-integrated idempotency keys design [1] except that the infra is provided by a saas company? Also somehow it supports rollbacks?
Does anyone know of any other more concrete explanation of how these kinds of systems could work?
I want to subscribe, but I never end up reading newsletters if they land in my email inbox.
reply