There's no technical solution to that, really. Do you think Nexus Firewall can pick up every exploit, or even most? How confident of that are you, and what data do you have to back that up? I don't have any myself, but would not be surprised at all if "hackers" can easily work around their scanning.
However, I don't have a better approach than using scanning tools like Nexus, or as the author proposes, use a curated library repository like Debian is doing (which hopefully gets enough eyeballs to remain secure) or the https://github.com/crev-dev/cargo-crev project (manually reviewed code) also mentioned. It's interesting that they mention C/C++ just rely on distros providing dynamic libs instead which means you don't even control your dependencies versions, some distro does (how reliable is the distro?)... I wonder if that could work for other languages or if it's just as painful as it looks in the C world.
1. Git clone https://git.savannah.gnu.org/git/guix.git
2. Nicolò Balzarotti already has a work in progress patchset adding Dart itself--see https://issues.guix.gnu.org/44926 . Patch your guix checkout with the files you can download on that page via the downarrow buttons on the right.
3. Create a file guix/build-system/dart.scm (I'd copy it from guix/build-system/dub.scm and then s/dub/dart/g and s/ldc/dartcc/g) or whatever it is. This file is the "front end" and is support for dart for the guix package manager script.
4. Create a file guix/build/dart-build-system.scm (I'd copy it from guix/build/dub-build-system.scm and then s/dub/dart/g). This file is the "back end" and is responsible for the build of your package inside a new container.
5. Add references to your new files to gnu/local.mk
6. In your user package script (whatever you want to compile in dart), add #:use-module (guix build-system dart) near the top and then add (build-system dart-build-system) to your package.
7. guix environment --pure guix
8. ./bootstrap
9. ./configure --localstatedir=/var
10. make -j5
11. exit
12. ./pre-inst-env guix build -f yourpackage.scm or whatever
13. Fiddle with the "invoke" parts in guix/build/dart-build-system.scm until your user package works.
14. Submit your results to [email protected] or [email protected] (no need to be subscribed).
As you can see, adding a new programming environment is quite some work. Because every programming environment has its own idiosyncracies, I don't think it can be avoided even in principle.
I mean the working copy (the local directory) created by git clone.
>Looks like it's a huge effort.
Probably.
I've never used Dart in my life, so I don't have so much Dart-specific information, sorry.
> That Pull Request is adding Dart 2.8 while the current version is 3.1.5 (and it's released often, at least once a month). Most pub packages don't even work on Dart 2.x anymore.
Then as a next step you (or someone) would probably add another dart package for version 3, building it with Dart version 2 (is that how the dart build works? Probably).
>as I am using Guix OS (in a VM) and as far as I know there's no sources in it?
Just do the git clone. The guix package manager is a regular program (with source on git) like any other.
I always use a git clone of the guix master branch (for like 6 years now) and it was never a problem. But if you instead want to use the version used by your OS, do guix build -S guix . It will unpack the source of the current guix and tell you where it is. I wouldn't bother doing the latter though.
Also, basically there's a guix daemon that does the build container management (think of it as something like dockerd) and then there's the guix frontend. I'd never do "make install" in the guix working copy--so the guix daemon will not be fucked with. The ./pre-inst-env allows you to run the local directory guix frontend without installing it.
This is NOT standard practice in the JS/Python/PHP/whatever world because these products do not exist or are not widely available, everyone "drinks" directly from the open internet source.
Yes, again, solutions exist, technically, but how many companies do you know, especially smaller ones, that do this?
For Java almost every company bigger than 5 devs tends to set up their own Maven repo at some point, many do it on day 1 because at least 1 dev is familiar with this practice from their former BigCo and it's easy to set up Nexus/Artifactory.
The average Java dev will try to reach for Artifactory/Nexus much sooner than the average Python/Ruby/PHP/Javascript/... dev, in my experience.
Devs might do whatever they feel locally, however if those files are going through CI/CD their dependencies better be in Nexus.
There is. Theoretically speaking, you could confine libraries to their own sandbox.
But Rust can't do that yet.
There is at least one language that tries to do that (someone posted it here in a comment some time ago, but I can't find it).
Unfortunately it is deprecated and scheduled for removal because too much security is annoying and not enough people care to use it.
Mirroring all of crates.io takes about a terabyte of storage, not much bandwidth and is really easy to set up, but judging by the download numbers of obscure packages there are only about 20 places in the world doing that. Maybe people haven't bothered because crates.io is so stable, maybe everyone goes the vendoring route instead.
Of course if your development is already set up in a way that prevents you from easily adding, experimenting with or updating dependencies, maybe because of how the vetting process works, that might not be an issue for you. And many places are completely fine with just being able to build
It's unlikely that I'll need a new dependency at the exact moment that the source is down, but fairly likely that if the source is down then I'll want to build something. For personal projects I'll have stuff cached locally, and I don't mind so much if I need to wait for CI. For work stuff I need to be able to fetch my dependencies in CI.
Also, hammering upstream with requests for every single build is both slow and also sort of rude.
I had no idea \o/ Thanks!
Products can only do best effort scanning for known patterns of vulnerabilites. Those are only added after someone (or something) discovers it and verifies that it's not a false alarm. In between the time gap, scanners are ineffective and anything in your infrastructure can run the malicious code and get hacked. (Google supply chain incidents on npm or pypi.)
In general, there is always a way to bypass it, since the language is turing complete and unsandboxed. Anything going beyond that is a lie, or simply impractical. Systems with latest software and antivirus get hacked all the time. Nothing can really stop them. Why?
- https://web.archive.org/web/20160424133617/http://www.pcworl...
- https://security.stackexchange.com/questions/201992/has-it-b...
- https://en.wikipedia.org/wiki/Rice%27s_theorem
> and either block them from entering the network or fail CI pipelines.
Also, relying solely on an endpoint security product for protection is dangerous since antiviruses themselves get hacked all the time. Sonatype for an example:
- https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...
My approach is basically: train a model on a large obfuscated dataset seeded with "known" examples. While you can't say with certainty what an unknown sample contains, you can determine how similar it is to a known sample, so you can spend more of your time analyzing the really weird stuff.
The hardest part in my opinion is generating the training data. You need a good source code obfuscator for your language. I've seen a lot of papers that use obfuscator-llvm[1] to obfuscate the IR during compilation. I use Tigress[2] to obfuscate the source code because it provides more diversity, but it only supports C.
[1]: https://github.com/obfuscator-llvm/obfuscator/wiki/Installat...
[2]: https://tigress.wtf/
One question: how do you detect when a binary is intentionally made to statically look similar to one binary, while its behavior actually mimics another?
In my work I'm not looking for intentional spoofing, but the obfuscations I do use [3,4,5,6,7] end up building very similar control flow structures for different functions. Maybe that fits the spirit of your question... Let me know if not.
So far I'm doing purely static analysis and control flow, but the broader field of reverse engineering includes dynamic/symbolic analysis where you track values through a running/simulated program. Great results but very costly to run.
I've been focusing on making cheap/static analysis better, so I haven't explored the dynamic/symbolic side at all yet.
[1]: https://tigress.wtf/virtualize.html
[2]: https://tigress.wtf/jitter.html
[3]: https://tigress.wtf/flatten.html
[4]: https://tigress.wtf/split.html
[5]: https://tigress.wtf/merge.html
Once they're known. I suppose nexus firewall let log4j pass.
1. https://github.com/ossillate-inc/packj 2. https://github.com/ossillate-inc/packj-github-action
Isn't that how life works? Unknown unknowns? :-)
> I suppose nexus firewall let log4j pass.
It should be reasonable to assume that a product dedicated to something will, on average, do this job better/faster than a random developer, though. Since that's their job.
So Nexus Firewall presumably blocks these vulnerabilities faster than the average app/system developer notices them. There's value in reducing the delta between the vulnerability exploit day and an entire ecosystem being patched/fixed.
Once log4shell was discovered it was trivial to eliminate it from the organisation. We knew exactly what projects were using it and updated them accordingly. Access logs showed us that it was no longer used and we delete it.
> Builds don't access the internet directly. You host a proxy on-premise (Nexus/Artifactory/etc) and access that. If the internet location is down, you continue as normal.
Right now I'm using Sonatype Nexus (the free version) for my personal needs: https://www.sonatype.com/products/sonatype-nexus-repository
And I do mean most things: apt packages, Docker images, Helm charts, as well as packages for Go, Java, .NET, Node, Python and Ruby, maybe even more in the future. I'm very glad that it is possible to do something like that, but honestly it's hard to do and I can easily see why most wouldn't bother: even though the configuration UI is okay and you can create users with appropriate permissions, you'll still need to have plenty of storage, manage updates and backups, setup automated cleanup tasks (especially for Docker images), in addition to the whole process on the developer's side sometimes being a nuisance.
With npm you get --registry which is one of the simpler approaches, Ruby Gems needed some CLI commands along the lines of "bundle config mirror" and other stuff, Maven needs an XML file with the configuration, in addition to publishing your own packages to those also needing more configuration. Sadly, it seems like this fragmentation of approaches is unavoidable and complexity increases with the amount of languages you use.
On the bright side, I keep control over my data, as well as have really good download/upload speeds, even on a cheap VPS. Plus you learn some vaguely useful things the more you explore if you want to go further, like how I also start with Debian/Ubuntu base container images and provision whatever tools or runtimes I need for more specialized images (e.g. my own JDK, .NET, Node etc. images).
There are actually multiple different kinds of blob store backends: https://help.sonatype.com/repomanager3/nexus-repository-admi... though so far I've only used the File one, because my servers have incremental backups that can be restored in a few clicks (that I've sometimes done in the past).
I agree with the pain that some languages/package managers add as well. Its a shame package managers aren't necessarily designed to easily support writing your own mirror or switching repository.
Fair play for running your own Nexus for personal use!
Does anyone have a proxy for Rust? I'd love to run it. Please. Someone... help
edit: just learned Panamax exists for this... will try it
As someone who has worked in a big corporate their entire career this statement is bizarre. This has been solved for Java for over a decade.
Builds don't access the internet directly. You host a proxy on-premise (Nexus/Artifactory/etc) and access that. If the internet location is down, you continue as normal.
> You need only one author in your maybe-hundreds-of-dependencies tree to be hacked, coerced or in a malicious mood for you to have a really bad day.
There are products (Nexus Firewall) that can check dependencies for vulnerabilities and either block them from entering the network or fail CI pipelines.