build(deps): bump ini from 1.3.5 to 1.3.8

[dependabot[bot]]

Bumps ini from 1.3.5 to 1.3.8.

Commits

• a2c5da8 1.3.8
• af5c6bb Do not use Object.create(null)
• 8b648a1 don't test where our devdeps don't even work
• c74c8af 1.3.7
• 024b8b5 update deps, add linting
• 032fbaf Use Object.create(null) to avoid default object property hazards
• 2da9039 1.3.6
• cfea636 better git push script, before publish instead of after
• 56d2805 do not allow invalid hazardous string as section name
• See full diff in compare view

Maintainer changes

This version was pushed to npm by isaacs, a new releaser for ini since your current version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/jquery/codeorigin.jquery.com/network/alerts).

[dependabot[bot]]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

[mgol]

@Krinkle why not merge it?

[Krinkle]

I didn't see how it improves anything relevant to this project. It just seems noise. I normally turn this off in repos I administer as it tends to be a time sink for well-meaning people that could spend their time on better things besides enslavement to boosting engagement metrics. I don't feel strongly either way if it seems useful to others that's fine, no opposition.

[mgol]

@Krinkle this is a security update, why would applying them be just noise?

[Krinkle]

If a package was malicious or compromised, it would have been removed from the npm registry. They don't issue patch releases for that. These are just security patches for rejecting bad user input, which afaik are only relevant for projects that actually take user input or allow adding of user-supplied code. E.g. if you run a Node.js web server that is open to the public, or if you ship modules out to end-users to run inside the browser.

For developer tooling (like a Gruntfile) I have never found these to be relevant, not even in theory. I'd love to see otherwise though, perhaps I've missed something or got lucky to not have had the right (or wrong) combination of tools where it becomes relevant. As I understand it, these are only interacted with from other JS code that we explicitly write in the repo, and only from our own CLI or Jenkins. I don't see where they have a runtime presence that accepts external input in some way?

[mgol]

@Krinkle

These are just security patches for rejecting bad user input, which afaik are only relevant for projects that actually take user input or allow adding of user-supplied code. E.g. if you run a Node.js web server that is open to the public, or if you ship modules out to end-users to run inside the browser.

I don't think this is the only place where they're relevant. For example, webpack-dev-server doesn't run on real servers and yet it had security issues reported that allowed external parties to access some files on machines of developers that had such a dev server running. So there's some real risk.

Granted, the majority of these reports don't touch such aspects. But just ignoring all security reports creates a danger of not patching a real vulnerability like the webpack-dev-server one and if the number of reports is not huge, it's easier to just apply them. Especially on a repository like this one. From what I remember, we didn't have many such reports on this repository.