Skip to content

build(deps): bump @azure/storage-blob from 12.33.0 to 12.34.0 - #404

Merged
saquibrashid merged 2 commits into
mainfrom
dependabot/npm_and_yarn/azure/storage-blob-12.34.0
Oct 8, 2026
Merged

saquibrashid merged 2 commits into
mainfrom
dependabot/npm_and_yarn/azure/storage-blob-12.34.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

Bumps @azure/storage-blob from 12.33.0 to 12.34.0.

Changelog

Sourced from @​azure/storage-blob's changelog.

12.34.0 (2026-09-24)

Features Added

  • Includes all features released in 12.34.0-beta.1.

12.34.0-beta.1 (2026-08-03)

Features Added

  • Added support for service version 2026-10-06.
  • Added accessTier, accessTierInferred, accessTierChangedOn, and smartAccessTier to the blob download response.
  • Added an opt-in Apache Arrow response format for listBlobsFlat and listBlobsByHierarchy (set responseFormat to StorageResponseFormat.Arrow), plus a new endBefore list option. The default remains XML.

Other Changes

  • For service version 2026-10-06 and later, upload operations now return the service-computed CRC64 checksum (xMsContentCrc64) in addition to contentMD5 when a Content-MD5 is provided. This applies to stageBlock, stageBlockFromURL, uploadPages, uploadPagesFromURL, appendBlock, appendBlockFromURL, upload, and syncUploadFromURL.
Commits
  • 018f2ef [storage] updated the spec commit to point it to a commit that is available o...
  • 0eaf6a1 [storage] updated package versions and changelogs for STG 103/104 GA
  • 8c75658 [storage] STG 103/104 (#39451)
  • f7e9279 Fix stale and broken //metadata version mappings (#39243)
  • 18ae6c7 [EngSys] use "workspace:^" version specifier for internal packages (#39200)
  • eb49098 [storage-queue] migrate to typespec-based code generation (#38224)
  • 1d09a0f [EngSys] upgrade dev dependency prettier to v3.9.1 (#39127)
  • 0616d26 Re-export RestError and isRestError in non-management packages (#39007)
  • See full diff in compare view

@dependabot @github

dependabot Bot commented on behalf of github Sep 29, 2026

Copy link
Copy Markdown
Contributor Author

Labels

The following labels could not be found: dependencies. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

@saquibrashid

Copy link
Copy Markdown
Owner

@dependabot rebase

@dependabot @github

dependabot Bot commented on behalf of github Oct 8, 2026

Copy link
Copy Markdown
Contributor Author

Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry!

If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.

@saquibrashid

Copy link
Copy Markdown
Owner

@dependabot recreate

@dependabot @github

dependabot Bot commented on behalf of github Oct 8, 2026

Copy link
Copy Markdown
Contributor Author

Dependabot can't authenticate to a private package registry. Because of this, Dependabot cannot update this pull request.

@saquibrashid

Copy link
Copy Markdown
Owner

@dependabot recreate

@dependabot @github

dependabot Bot commented on behalf of github Oct 8, 2026

Copy link
Copy Markdown
Contributor Author

Dependabot can't authenticate to a private package registry. Because of this, Dependabot cannot update this pull request.

saquibrashid added a commit that referenced this pull request Oct 8, 2026
…ry (#416)

`package-lock.json` carried 442 `resolved` URLs naming
`ms-feed-*.pkgs.visualstudio.com`, the internal Microsoft proxy feed. They
entered through a local `npm install` on a Microsoft-managed machine, which is
exactly the hazard `docs/runbooks/update-dependencies.md` section 6 warns about.

The consequence was NOT cosmetic. Dependabot treats that host as a private
registry it has no credential for, and refuses the whole update:

    Dependabot can't authenticate to a private package registry.
    Because of this, Dependabot cannot update this pull request.

So #403 (openai), #404 (@azure/storage-blob) and #405 (jsdom) could not rebase
or recreate, and every future bump touching those packages would have failed
the same way. CI never showed it: the `1es-public` feed is anonymously
readable, so GitHub runners install from it happily and all 13 jobs stay green.
The only symptom was `Dependabot Updates` workflow runs ending in `failure`.

The change is a host-prefix rewrite and nothing else:

    https://ms-feed-N.pkgs.visualstudio.com/1es-public/_packaging/npm-public/npm/registry/<pkg>/-/<file>.tgz
    -> https://registry.npmjs.org/<pkg>/-/<file>.tgz

No `npm install` was run, so no version moved and no transitive dependency
changed. No `integrity` hash changed either - it is the same tarball at its
public address, so the recorded hash stays valid. The sha1/sha512 populations
are identical before and after (412 / 135), which is the point: regenerating
the lockfile here would have DOWNGRADED sha512 entries to sha1 (section 6), so
this deliberately does not do that.

Verified: every one of the 884 changed lines is a `resolved` line, the file
still parses, and `check:deps` + `check:licences` pass.

Docs: adds runbook section 6a for the lockout and its repair, and corrects the
`sha1-` / `ms-feed-*` correlation in section 6 in place - sha1 hashes and public
URLs now coexist, so that correlation is no longer a valid test.

Unblocks #403, #404, #405.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c372e6ba-4c3f-419a-9f77-b9e23adfc874
@saquibrashid

Copy link
Copy Markdown
Owner

@dependabot recreate

Bumps [@azure/storage-blob](https://github.com/Azure/azure-sdk-for-js/tree/HEAD/sdk/storage/storage-blob) from 12.33.0 to 12.34.0.
- [Release notes](https://github.com/Azure/azure-sdk-for-js/releases)
- [Changelog](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/CHANGELOG.md)
- [Commits](https://github.com/Azure/azure-sdk-for-js/commits/@azure/storage-blob_12.34.0/sdk/storage/storage-blob)

---
updated-dependencies:
- dependency-name: "@azure/storage-blob"
  dependency-version: 12.34.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/npm_and_yarn/azure/storage-blob-12.34.0 branch from 69f69a9 to 33e7aa9 Compare October 8, 2026 13:32
Generated from the updated lockfile by .github/workflows/dependabot-notices.yml. Dependabot changes the installed tree but cannot run the repo script that regenerates this file, so every bump would otherwise fail check:licences and T-LICENSE-001c for a reason unrelated to the dependency being bumped.
@saquibrashid
saquibrashid merged commit cca6377 into main Oct 8, 2026
12 checks passed
@saquibrashid
saquibrashid deleted the dependabot/npm_and_yarn/azure/storage-blob-12.34.0 branch October 8, 2026 14:14
saquibrashid added a commit that referenced this pull request Oct 8, 2026
…-011) (#431)

Closes #417.

main once carried 442 "resolved" URLs naming ms-feed-*.pkgs.visualstudio.com,
written by a local `npm install` on a Microsoft-managed machine. That both
published an internal host from a public repository and SILENTLY DISABLED
dependabot for every affected package -- #403/#404/#405 could neither rebase
nor recreate for nine days -- while all twelve CI jobs stayed green, because
the 1es-public feed is anonymously readable. Repaired in #416; this closes the
three open questions #417 left.

Q1, a CI gate: tools/check-lockfile-registry.mjs + npm run check:lockfile,
asserted by T-CI-011 in tests/infra/lockfileRegistry.spec.ts and run in the
"3 . audit" job. An ALLOW-list of registry.npmjs.org, not an ms-feed-*
denylist: the next proxy to leak in will have a different hostname. It keys on
the URL, never on sha1- -- after #416 the two populations no longer correlate
(~412 sha1- hashes, zero proxy URLs), so a sha1- check would fail the clean
tree, which is why runbook section 6 still declines that one.

Q2, other leaks of the internal host: the same gate fails on any committed
.npmrc, whatever it contains. .npmrc is not gitignored, so one would be a real
and visible risk; machine-specific registry config belongs in ~/.npmrc.

Q3, the local-install story: runbook sections 2 and 4 both instructed a local
`npm install`, which is the action that CAUSES this defect and contradicted
sections 6/6a. Both corrected in place with the superseded text struck through
below (F-001 rule). Section 6a's "No CI gate" conclusion is likewise corrected:
it was sound for sha1- and wrongly extended to the resolved URL.

Verified end-to-end against the real contamination: pointed at the lockfile of
a branch that still carries it, the gate reports 447 entries across four hosts
collapsed to four lines, and exits 1.

WARNING for anyone with in-flight branches: 194 of 198 local branches in this
clone are still contaminated and will now fail CI. Apply the section 6a host
rewrite before pushing; it needs no install, no version change and no
integrity change.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c372e6ba-4c3f-419a-9f77-b9e23adfc874
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant