I created a new project using Sails.js and when I pushed it to github I am getting a security alert:
Upgrade lodash to version 4.17.13 or later
Problem is I can't seem to upgrade the lodash version. Sails is using "#sailshq/lodash": "^3.10.3" I tried yarn install lodash#4.17.13 but the yarn.lock still have the old version.
Anybody knows how to upgrade the lodash version?
Here is the full alert:
CVE-2019-10744
high severity
Vulnerable versions: < 4.17.13
Patched version: 4.17.13
Affected versions of lodash are vulnerable to Prototype Pollution.
The function defaultsDeep could be tricked into adding or modifying properties of Object.prototype using a constructor payload.
Related
My project uses .NET Standard Library version 2.1.0. One of the packages that it references is System.Net.WebSockets.Client version 4.0.2.0. This package in its turn has a dependency on System.Security.Cryptography.X509Certificates version 4.1.0. As a result, when I restore before build, this particular version gets downloaded. The issue is version 4.1.0 of System.Security.Cryptography.X509Certificates has a known vulnerability and should get updated to 4.1.2 which has the vulnerability fixed.
I am not sure how to update the version of a package that is being internally referenced from another package which itself is part of the .NET Standard Library.
I am getting flagged in my build for using the non-compliant version of the X509Cerificates package. Any pointers in this regard would be much appreciated.
Thanks.
Dependencies could not be resolved because root depends on 'googleappmeasurement' 9.0.0.
'googleappmeasurement' 9.0.0 cannot be used because 'googleappmeasurement' 9.0.0 depends on 'nanopb' 2.30908.0..<2.30909.0 and root depends on 'nanopb' 2.30909.0..<2.30910.0.
that is my error message, can anyone help?
I am using SDK version 8.9.1 and everything working fine, If you executed the Resolve Package Versions and still not working. you can try the command Reset Package Caches from Project navigator scroll down right click on Package Dependencies then choose the command. that will clear all caches for all installed packages then re-install them again. if that not working i suggest you to use version 8.9.1 till Firebase fix the issue.
I have discovered the problem has been answered here. It occurs when importing Firebase using Swift Package Manager and setting to track "master" instead of a specific release version.
Got same error and solved, check attached image, this most likely packages usage misconfiguration, as follows:
1-perhaps you are working on a branch with different Xcode version than the other developer who installed the package.
2-Perhaps some package is conflicted being used twice, by so some dependencies are duplicated.
Well to solve this you gotta try either to match the Xcode version used while installing the packages, or to remove the package that makes errors(like Firebase here), and try adding that package again your side.
We have decided to upgrade the Flutter version from 1.22 to 2.0 (migrating to null-safety) in an existing project.
We checkout Flutter v2.0.0 and then run the following command:
dart pub upgrade --null-safety
Flutter nicely resolves all dependency conflicts and sets new versions for packages.
Without changing min environment SDK in pubspec.yaml (staying at ">2.10.0 <3.0.0") we fix all breaking changes in the code.
All errors in vs code disappear so we can compile the code. But, when we do compile we get errors from packages e.g. reorderables, fl_chart, flutter_svg etc. stating some classes are undefined. It seems like packages were compiled with a higher SDK version and they weren't set min SDK version to match the one that they were compiled with.
So the package states it can be compiled with Flutter 2.10.0 but in reality, it fails to compile because in this version of Flutter it is missing some necessary imports.
My question is, is this a problem of packages or a problem in my way of processing with migration?
Is it that packages are lacking properly set min SDK?
My conclusion is that most packages are lacking correctly set SDK version constraints. It seems authors usually compile packages for a certain version and do not check min SDK version required. When running dependency resolver it seems to solve dependencies but in compile time it fails.
Sentry latest version is incompatible with http plugin and if another version of sentry is used then it is also not compatible with rest of the other already used packages in project.
Even without version I tried to get its compatible version but this also not worked.
This is because Sentry uses http: ^0.13.0 because that's the earliest version which is null safe. The user uses a pretty outdated version of http.
Got the reply from GitHub: https://github.com/getsentry/sentry-dart/issues/694
When i try install and i have this error:
# composer require backpack/base
Using version ^0.7.3 for backpack/base
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for backpack/base ^0.7.3 -> satisfiable by backpack/base[0.7.3].
- backpack/base 0.7.3 requires laravel/framework 5.3.* -> satisfiable by laravel/framework[5.3.x-dev, v5.3.0, v5.3.0-RC1, v5.3.1, v5.3.10, v5.3.11, v5.3.12, v5.3.13, v5.3.14, v5.3.15, v5.3.16, v5.3.17, v5.3.18, v5.3.19, v5.3.2, v5.3.3, v5.3.4, v5.3.5, v5.3.6, v5.3.7, v5.3.8, v5.3.9] but these conflict with your requirements or minimum-stability.
Installation failed, reverting ./composer.json to its original content.
How fix that?
You're probably running a Laravel 5.2 app. If so, you have two options:
1) Upgrade from Laravel 5.2 to Laravel 5.3, then try again, it will most definitely work. The Laravel upgrade takes about about 1 hour for a medium-sized project, but you'll have all the benefits of using the latest and greatest (both Laravel and Backpack).
2) Install Backpack for Laravel 5.2, but please be aware you're running an old Backpack version and you won't be receiving any updates or new features.
My recommendation, of course, is option #1. In the end, you'll still need to update Laravel, then update Backpack, so it's best to just do it now.